[PATCH] D103867: [CHR] Don't run ControlHeightReduction if any BB has address taken

Wenlei He via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jun 11 16:33:55 PDT 2021


wenlei accepted this revision.
wenlei added a comment.

LGTM.

In D103867#2814096 <https://reviews.llvm.org/D103867#2814096>, @hoy wrote:

> In D103867#2806612 <https://reviews.llvm.org/D103867#2806612>, @aeubanks wrote:
>
>> do all passes that clone BBs have to worry about this?
>
> I think so. We've seen a similar case in inlining where an address-taken block was inlined. The inlining should be disabled as well.

Poking around it looks like this should be handled for inlining, not sure why the previous case we ran into wasn't covered by that code below from `CallAnalyzer::analyze()`

  // Disallow inlining a blockaddress with uses other than strictly callbr.
  // A blockaddress only has defined behavior for an indirect branch in the
  // same function, and we do not currently support inlining indirect
  // branches.  But, the inliner may not see an indirect branch that ends up
  // being dead code at a particular call site. If the blockaddress escapes
  // the function, e.g., via a global variable, inlining may lead to an
  // invalid cross-function reference.
  // FIXME: pr/39560: continue relaxing this overt restriction.
  if (BB->hasAddressTaken())
    for (User *U : BlockAddress::get(&*BB)->users())
      if (!isa<CallBrInst>(*U))
        return InlineResult::failure("blockaddress used outside of callbr");

> LGTM, thanks for the fix.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103867



More information about the llvm-commits mailing list