UseListOrder: Visit global values

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.

llvm-svn: 214321

1 files changed, 11 insertions, 0 deletions

diff --git a/llvm/test/Bitcode/use-list-order.ll b/llvm/test/Bitcode/use-list-order.ll
index bb71a8586b7..fb18b462da5 100644
--- a/llvm/test/Bitcode/use-list-order.ll
+++ b/llvm/test/Bitcode/use-list-order.ll
@@ -17,6 +17,11 @@
 @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
@@ -94,3 +99,9 @@ first:
   %gotosecond = icmp slt i32 %gh, -9
   br i1 %gotosecond, label %second, label %exit
 }
+
+define i4 @globalAndFunctionFunctionUser() {
+entry:
+  %local = load i4* @globalAndFunction
+  ret i4 %local
+}