[INLINER] allow inlining of blockaddresses if sole uses are callbrs

Authored by nickdesaulniers on May 20 2019, 9:48 AM.


[INLINER] allow inlining of blockaddresses if sole uses are callbrs

It was supposed that Ref LazyCallGraph::Edge's were being inserted by
inlining, but that doesn't seem to be the case. Instead, it seems that
there was no test for a blockaddress Constant in an instruction that
referenced the function that contained the instruction. Ex:

define void @f() {
  %1 = alloca i8*, align 8
  store i8* blockaddress(@f, %2), i8** %1, align 8
  ret void

When iterating blockaddresses, do not add the function they refer to
back to the worklist if the blockaddress is referring to the contained
function (as opposed to an external function).

Because blockaddress has sligtly different semantics than GNU C's
address of labels, there are 3 cases that can occur with blockaddress,
where only 1 can happen in GNU C due to C's scoping rules:

  • blockaddress is within the function it refers to (possible in GNU C).
  • blockaddress is within a different function than the one it refers to

(not possible in GNU C).

  • blockaddress is used in to declare a global (not possible in GNU C).

The second case is tested in:

$ ./llvm/build/unittests/Analysis/AnalysisTests \

This patch adjusts the iteration of blockaddresses in
LazyCallGraph::visitReferences to not revisit the blockaddresses
function in the first case.

The Linux kernel contains code that's not semantically valid at -O0;
specifically code passed to asm goto. It requires that asm goto be
inline-able. This patch conservatively does not attempt to handle the
more general case of inlining blockaddresses that have non-callbr users


Reviewers: jyknight, eli.friedman, chandlerc

Reviewed By: chandlerc

Subscribers: george.burgess.iv, nathanchance, mgorny, craig.topper, mengxu.gatech, void, mehdi_amini, E5ten, chandlerc, efriedma, eraman, hiraditya, haicheng, pirama, llvm-commits, srhines

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D58260

llvm-svn: 361173