[PATCH] D120781: [IRLinker] materialize Functions before moving any

[Nick Desaulniers via Phabricator via llvm-commits]

nickdesaulniers added a comment.

In D120781#3376069 <https://reviews.llvm.org/D120781#3376069>, @dexonsmith wrote:

> Here's what I suggest:
>
> - Add to bitcode a way to say that materializing a function requires materializing another one. Maybe this could be a new record in the `FUNCTION_BLOCK` that's arbitrary size, only emitted if there are non-zero of them, which lists the functions that need to be materialized when this one is.
> - Use this feature to add edges in both directions every time one function has a `blockaddress` to another one. Probably not too hard; during value enumeration of function bodies, create a map of which functions need to be materialized with each other (based on observed `blockaddress`es), then use that to generate the records during bitcode emission.
> - Change the lazy materializer to use this information somehow (maybe this is the hard part).
>
> WDYT?

One potential issue, consider the following case:

  declare void @f(i8*)
  
  define void @x() {
    br label %label
  
  label:
    ret void
  }
  
  define linkonce_odr void @y() {
    br label %label
  
  label:
    call void @f(i8* blockaddress(@x, %label))
    ret void
  }

So `@y` contains a `blockaddress` that refers to `@x`, but because of its linkage AND lack of reference from any function w/ external linkage, `@y` is never emitted (let alone materialized).  I think in this case, if we were to record that `@x` had a "backedge" from `@y`, and thus materialized `@y` as a result of materializing `@x`, we'd wind up "over-materializing" again.  This is because `BitcodeReader` doesn't know about `IRMover::Worklist` and the complex linkage type handling, and lazy additions to the worklist.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120781