summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: 8dc3e30)
raw | patch | inline | side by side (parent: 8dc3e30)
author | Duncan P. N. Exon Smith <dexonsmith@apple.com> | |
Wed, 30 Jul 2014 17:51:09 +0000 (17:51 +0000) | ||
committer | Duncan P. N. Exon Smith <dexonsmith@apple.com> | |
Wed, 30 Jul 2014 17:51:09 +0000 (17:51 +0000) |
When predicting use-list order, we visit functions in reverse order
followed by `GlobalValue`s and write out use-lists at the first
opportunity. In the reader, this will translate to *after* the last use
has been added.
For this to work, we actually need to descend into `GlobalValue`s.
Added a targeted test in `use-list-order.ll` and `RUN` lines to the
newly passing tests in `test/Bitcode`.
There are two remaining failures in `test/Bitcode`:
- blockaddress.ll: I haven't thought through how to model the way
block addresses change the order of use-lists (or how to work around
it).
- metadata-2.ll: There's an old-style `@llvm.used` global array here
that I suspect the .ll parser isn't upgrading properly. When it
round-trips through bitcode, the .bc reader *does* upgrade it, so
the extra variable (`i8* null`) has an extra use, and the shuffle
vector doesn't match.
I think the fix is to upgrade old-style global arrays (or reject
them?) in the .ll parser.
This is part of PR5680.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214321 91177308-0d34-0410-b5e6-96231b3b80d8
followed by `GlobalValue`s and write out use-lists at the first
opportunity. In the reader, this will translate to *after* the last use
has been added.
For this to work, we actually need to descend into `GlobalValue`s.
Added a targeted test in `use-list-order.ll` and `RUN` lines to the
newly passing tests in `test/Bitcode`.
There are two remaining failures in `test/Bitcode`:
- blockaddress.ll: I haven't thought through how to model the way
block addresses change the order of use-lists (or how to work around
it).
- metadata-2.ll: There's an old-style `@llvm.used` global array here
that I suspect the .ll parser isn't upgrading properly. When it
round-trips through bitcode, the .bc reader *does* upgrade it, so
the extra variable (`i8* null`) has an extra use, and the shuffle
vector doesn't match.
I think the fix is to upgrade old-style global arrays (or reject
them?) in the .ll parser.
This is part of PR5680.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214321 91177308-0d34-0410-b5e6-96231b3b80d8
index c05d6ae0d2171936ad78f6b0773c8b64617ce430..fa1c8b3c57d6be6e7a32823300c416a0d65d4c4e 100644 (file)
// Recursive descent into constants.
if (const Constant *C = dyn_cast<Constant>(V))
- if (C->getNumOperands() && !isa<GlobalValue>(C))
+ if (C->getNumOperands()) // Visit GlobalValues.
for (const Value *Op : C->operands())
- if (isa<Constant>(Op) && !isa<GlobalValue>(Op))
+ if (isa<Constant>(Op)) // Visit GlobalValues.
predictValueUseListOrder(Op, F, OM, Stack);
}
for (const BasicBlock &BB : F)
for (const Instruction &I : BB)
for (const Value *Op : I.operands())
- if ((isa<Constant>(*Op) && !isa<GlobalValue>(*Op)) ||
- isa<InlineAsm>(*Op))
+ if (isa<Constant>(*Op) || isa<InlineAsm>(*Op)) // Visit GlobalValues.
predictValueUseListOrder(Op, &F, OM, Stack);
for (const BasicBlock &BB : F)
for (const Instruction &I : BB)
index 2b44fc6599e603f5fbd85e0ea0a6b2d301d1549d..ccef8dff67c66f65970cdc915880e1aaa57d2047 100644 (file)
; RUN: llvm-dis < %s.bc| FileCheck %s
+; RUN: verify-uselistorder < %s.bc -preserve-bc-use-list-order -num-shuffles=5
; miscInstructions.3.2.ll.bc was generated by passing this file to llvm-as-3.2.
; The test checks that LLVM does not misread miscellaneous instructions of
index 90b4394a8b46ef4152157b90c11eb4368f75bac5..4a612ec546dcc2c706bfb60060b77f61a1012a61 100644 (file)
; RUN: opt < %s -S | FileCheck %s
+; RUN: verify-uselistorder < %s -preserve-bc-use-list-order -num-shuffles=5
; CHECK-NOT: {@llvm\\.palign}
define <4 x i32> @align1(<4 x i32> %a, <4 x i32> %b) nounwind readnone ssp {
index bb71a8586b73efec2d04df3a101c29f1bb73e94e..fb18b462da51fe959a3c6e028ee79c4b0dbe596e 100644 (file)
@var2 = global i3* @target
@var3 = global i3* @target
+; Check use-list order for a global when used both by a global and in a
+; function.
+@globalAndFunction = global i4 4
+@globalAndFunctionGlobalUser = global i4* @globalAndFunction
+
define i64 @f(i64 %f) {
entry:
%sum = add i64 %f, 0
%gotosecond = icmp slt i32 %gh, -9
br i1 %gotosecond, label %second, label %exit
}
+
+define i4 @globalAndFunctionFunctionUser() {
+entry:
+ %local = load i4* @globalAndFunction
+ ret i4 %local
+}
diff --git a/test/Bitcode/variableArgumentIntrinsic.3.2.ll b/test/Bitcode/variableArgumentIntrinsic.3.2.ll
index 199fbbdbdb59eef113082d43379c0e81f9419a3c..14914b78b422eee27ec06503fd58ba69cdb187eb 100644 (file)
; RUN: llvm-dis < %s.bc| FileCheck %s
+; RUN: verify-uselistorder < %s.bc -preserve-bc-use-list-order -num-shuffles=5
; vaArgIntrinsic.3.2.ll.bc was generated by passing this file to llvm-as-3.2.
; The test checks that LLVM does not misread variable argument intrinsic instructions