[PATCH] D104950: [OpaquePtr] Support forward references in textual IR

[Duncan P. N. Exon Smith via Phabricator via llvm-commits]

dexonsmith added a comment.

In D104950#2842046 <https://reviews.llvm.org/D104950#2842046>, @dexonsmith wrote:

> In D104950#2841883 <https://reviews.llvm.org/D104950#2841883>, @nikic wrote:
>
>> Out of curiosity, I ran `find . -name '*.ll' -exec echo '{}' \; -exec build/bin/verify-uselistorder {} \; >out 2>&1` without this patch, and hit quite a few failures :/
>
> Not sure how many failures you're seeing. I saw 132 when I ran it. https://reviews.llvm.org/D104959 brings that down to 60. Looking at the rest.

I looked at llvm/test/Transforms/CallSiteSplitting/lpad.ll. This fails because the implicit `i1* null` hung-off operands of the function don't get ordered properly. Here is a minimal repro:

  @personality = external global i8
  define void @f1(i1* %param) personality i8* @personality {
  entry:
    %cmp = icmp eq i1* %param, null
    unreachable
  }

The prefix-data and prologue-data fields are (implicitly) uses of `i1* null` because there's a `personality`. I'm having trouble reasoning about exactly how to fix this one since the bitcode reader handles these strangely... but I hacked verify-uselistorder to ignore mismatches for all `ConstantData` values, and that hides this and gets the failure list from 60 down to 35. (Really, no one should ever walk the use-list of `ConstantData`; it'd be worth guaranteeing that at some point, and then we could skip computing/storing use-list ordering for them...) I can probably whittle this down next week if it's blocking you.

Still curious to hear what the windows failure is.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104950/new/

https://reviews.llvm.org/D104950