[MachineOutliner] Add DISubprograms to outlined functions.

Before, it wasn't possible to get backtraces inside outlined functions. This
commit adds DISubprograms to the IR functions created by the o

[MachineOutliner] Add DISubprograms to outlined functions.

Before, it wasn't possible to get backtraces inside outlined functions. This
commit adds DISubprograms to the IR functions created by the outliner which
makes this possible. Also attached a test that ensures that the produced
debug information is correct. This is useful to users that want to debug
outlined code.

llvm-svn: 322789

show more ...

[MachineOutliner] Move hasAddressTaken check to MachineOutliner.cpp

*Mostly* NFC. Still updating the test though just for completeness.

This moves the hasAddressTaken check to MachineOutliner.cpp a

[MachineOutliner] Move hasAddressTaken check to MachineOutliner.cpp

*Mostly* NFC. Still updating the test though just for completeness.

This moves the hasAddressTaken check to MachineOutliner.cpp and replaces it
with a per-basic block test rather than a per-function test. The old test was
too conservative and was preventing functions in C programs from being
outlined even though they were safe to outline.

This was mostly a problem in C sources.

llvm-svn: 322425

show more ...

[MachineOutliner] AArch64: Handle instrs that use SP and will never need fixups

This commit does two things. Firstly, it adds a collection of flags which can
be passed along to the target to encode

[MachineOutliner] AArch64: Handle instrs that use SP and will never need fixups

This commit does two things. Firstly, it adds a collection of flags which can
be passed along to the target to encode information about the MBB that an
instruction lives in to the outliner.

Second, it adds some of those flags to the AArch64 outliner in order to add
more stack instructions to the list of legal instructions that are handled
by the outliner. The two flags added check if

- There are calls in the MachineBasicBlock containing the instruction
- The link register is available in the entire block

If the link register is available and there are no calls, then a stack
instruction can always be outlined without fixups, regardless of what it is,
since in this case, the outliner will never modify the stack to create a
call or outlined frame.

The motivation for doing this was checking which instructions are most often
missed by the outliner. Instructions like, say

%sp<def> = ADDXri %sp, 32, 0; flags: FrameDestroy

are very common, but cannot be outlined in the case that the outliner might
modify the stack. This commit allows us to outline instructions like this.


llvm-svn: 322048

show more ...

Remove redundant includes from lib/CodeGen.

llvm-svn: 320619

[MachineOutliner] NFC: Throw out self-intersections on candidates early

Currently, the outliner considers candidates that intersect with themselves in
the candidate pruning step. That is, candidates

[MachineOutliner] NFC: Throw out self-intersections on candidates early

Currently, the outliner considers candidates that intersect with themselves in
the candidate pruning step. That is, candidates of the form "AA" in ranges like
"AAAAAA". In that range, it looks like there are 5 instances of "AA" that could
possibly be outlined, and that's considered in the benefit calculation.

However, only at most 3 instances of "AA" could ever be outlined in "AAAAAA".
Thus, it's possible to pass through "AA" to the candidate selection step even
though it's *never* the case that "AA" could be outlined. This makes it so that
when we find candidates, we consider only non-overlapping occurrences of that
candidate.

llvm-svn: 319588

show more ...

Fix a bunch more layering of CodeGen headers that are in Target

All these headers already depend on CodeGen headers so moving them into
CodeGen fixes the layering (since CodeGen depends on Target, n

Fix a bunch more layering of CodeGen headers that are in Target

All these headers already depend on CodeGen headers so moving them into
CodeGen fixes the layering (since CodeGen depends on Target, not the
other way around).

llvm-svn: 318490

show more ...

Target/TargetInstrInfo.h -> CodeGen/TargetInstrInfo.h to match layering

This header includes CodeGen headers, and is not, itself, included by
any Target headers, so move it into CodeGen to match the

Target/TargetInstrInfo.h -> CodeGen/TargetInstrInfo.h to match layering

This header includes CodeGen headers, and is not, itself, included by
any Target headers, so move it into CodeGen to match the layering of its
implementation.

llvm-svn: 317647

show more ...

[MachineOutliner] Add optimisation remarks for successful outlining

This commit adds optimisation remarks for outlining which fire when a function
is successfully outlined.

To do this, OutlinedFunc

[MachineOutliner] Add optimisation remarks for successful outlining

This commit adds optimisation remarks for outlining which fire when a function
is successfully outlined.

To do this, OutlinedFunctions must now contain references to their Candidates.
Since the Candidates must still be sorted and worked on separately, this is
done by working on everything in terms of shared_ptrs to Candidates. This is
good; it means that we can easily move everything to outlining in terms of
the OutlinedFunctions rather than the individual Candidates. This is far more
intuitive than what's currently there!

(Remarks are output when a function is created for some group of Candidates.
In a later commit, all of the outlining logic should be rewritten so that we
loop over OutlinedFunctions rather than over Candidates.)


llvm-svn: 316396

show more ...

[MachineOutliner] NFC: Rename getters/setters to fit coding style

Rename endIdx, startIdx, and length to getEndIdx, getStartIdx, and getLength
in Candidate.

llvm-svn: 316341

[MachineOutliner][NFC] Clean up prune logic a bit

Move the prune logic in pruneOverlaps to a new function, prune. This lets us
reuse the prune functionality. Makes the code a bit more readable. It'l

[MachineOutliner][NFC] Clean up prune logic a bit

Move the prune logic in pruneOverlaps to a new function, prune. This lets us
reuse the prune functionality. Makes the code a bit more readable. It'll also
make it easier to emit remarks/debug statements for pruned functions.

llvm-svn: 316031

show more ...

[MachineOutliner][NFC] Move decrement logic to OutlinedFunction

This commit moves the decrement logic for outlined functions into the class,
and makes OccurrenceCount private. It can now be accessed

[MachineOutliner][NFC] Move decrement logic to OutlinedFunction

This commit moves the decrement logic for outlined functions into the class,
and makes OccurrenceCount private. It can now be accessed via
getOccurrenceCount().

This makes it more difficult to accidentally introduce bugs by incorrectly
decrementing the occurrence count on OutlinedFunctions.

llvm-svn: 316020

show more ...

[MachineOutliner][NFC] Move end index calculation into Candidate

Cleanup to Candidate that moves all end index calculations into
Candidate.endIdx(). For the sake of consistency, StartIdx and Len are

[MachineOutliner][NFC] Move end index calculation into Candidate

Cleanup to Candidate that moves all end index calculations into
Candidate.endIdx(). For the sake of consistency, StartIdx and Len are now
private members, and can be accessed with length() and startIdx() respectively.

llvm-svn: 316019

show more ...

[NFC] Convert OptimizationRemarkEmitter old emit() calls to new closure
parameterized emit() calls

Summary: This is not functional change to adopt new emit() API added in r313691.

Reviewed By: anem

[NFC] Convert OptimizationRemarkEmitter old emit() calls to new closure
parameterized emit() calls

Summary: This is not functional change to adopt new emit() API added in r313691.

Reviewed By: anemet

Subscribers: llvm-commits

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

llvm-svn: 315476

show more ...

CodeGen: Minor cleanups to use MachineInstr::getMF. NFC

Since r315388 we have a shorter way to say this, so we'll replace
MI->getParent()->getParent() with MI->getMF() in a few places.

llvm-svn: 31

CodeGen: Minor cleanups to use MachineInstr::getMF. NFC

Since r315388 we have a shorter way to say this, so we'll replace
MI->getParent()->getParent() with MI->getMF() in a few places.

llvm-svn: 315390

show more ...

[MachineOutliner] Disable outlining from LinkOnceODRs by default

Say you have two identical linkonceodr functions, one in M1 and one in M2.
Say that the outliner outlines A,B,C from one function, an

[MachineOutliner] Disable outlining from LinkOnceODRs by default

Say you have two identical linkonceodr functions, one in M1 and one in M2.
Say that the outliner outlines A,B,C from one function, and D,E,F from another
function (where letters are instructions). Now those functions are not
identical, and cannot be deduped. Locally to M1 and M2, these outlining
choices would be good-- to the whole program, however, this might not be true!

To mitigate this, this commit makes it so that the outliner sees linkonceodr
functions as unsafe to outline from. It also adds a flag,
-enable-linkonceodr-outlining, which allows the user to specify that they
want to outline from such functions when they know what they're doing.

Changing this handles most code size regressions in the test suite caused by
competing with linker dedupe. It also doesn't have a huge impact on the code
size improvements from the outliner. There are 6 tests that regress > 5% from
outlining WITH linkonceodrs to outlining WITHOUT linkonceodrs. Overall, most
tests either improve or are not impacted.

Not outlined vs outlined without linkonceodrs:
https://hastebin.com/raw/qeguxavuda

Not outlined vs outlined with linkonceodrs:
https://hastebin.com/raw/edepoqoqic

Outlined with linkonceodrs vs outlined without linkonceodrs:
https://hastebin.com/raw/awiqifiheb

Numbers generated using compare.py with -m size.__text. Tests run for AArch64
with -Oz -mllvm -enable-machine-outliner -mno-red-zone.

llvm-svn: 315136

show more ...

[MachineOutliner] Fix off-by-one in cost model

This commit does two things. Firstly, it cleans up some of the benefit
calculation wrt outlined functions and candidates. Secondly, it fixes an
off-by-

[MachineOutliner] Fix off-by-one in cost model

This commit does two things. Firstly, it cleans up some of the benefit
calculation wrt outlined functions and candidates. Secondly, it fixes an
off-by-one bug in the cost model which was caused by the benefit value of
an OutlinedFunction and Candidate differing by 1. It updates the remarks test
to reflect this change.

llvm-svn: 314836

show more ...

[MachineOutliner][NFC] Simplify logic in pruneCandidates

This commit yanks out the repeated sections of code in pruneCandidates into
two lambdas: ShouldSkipCandidate and Prune. This simplifies the l

[MachineOutliner][NFC] Simplify logic in pruneCandidates

This commit yanks out the repeated sections of code in pruneCandidates into
two lambdas: ShouldSkipCandidate and Prune. This simplifies the logic in
pruneCandidates significantly, and reduces the chance of introducing bugs by
folding all of the shared logic into one place.

llvm-svn: 314475

show more ...

[MachineOutliner] AArch64: Avoid saving + restoring LR if possible

This commit allows the outliner to avoid saving and restoring the link register
on AArch64 when it is dead within an entire class o

[MachineOutliner] AArch64: Avoid saving + restoring LR if possible

This commit allows the outliner to avoid saving and restoring the link register
on AArch64 when it is dead within an entire class of candidates.

This introduces changes to the way the outliner interfaces with the target.
For example, the target now interfaces with the outliner using a
MachineOutlinerInfo struct rather than by using getOutliningCallOverhead and
getOutliningFrameOverhead.

This also improves several comments on the outliner's cost model.

https://reviews.llvm.org/D36721

llvm-svn: 314341

show more ...

[MachineOutliner] Recommit r312194, missed optimization remarks

Before, this commit caused a buildbot failure:

http://bb.pgr.jp/builders/test-llvm-i686-linux-RA/builds/6026/steps/test_llvm/logs/LLV

[MachineOutliner] Recommit r312194, missed optimization remarks

Before, this commit caused a buildbot failure:

http://bb.pgr.jp/builders/test-llvm-i686-linux-RA/builds/6026/steps/test_llvm/logs/LLVM%20%3A%3A%20CodeGen__AArch64__machine-outliner-remarks.ll

This was caused by the Key value in DiagnosticInfoOptimizationBase being
deallocated before emitting the remarks defined in MachineOutliner.cpp. As of
r312277 this should no longer be an issue.


llvm-svn: 312280

show more ...

Revert r312194: "[MachineOutliner] Add missed optimization remarks for the outliner."

Breaks on buildbot:
http://bb.pgr.jp/builders/test-llvm-i686-linux-RA/builds/6026/steps/test_llvm/logs/LLVM%20%3

Revert r312194: "[MachineOutliner] Add missed optimization remarks for the outliner."

Breaks on buildbot:
http://bb.pgr.jp/builders/test-llvm-i686-linux-RA/builds/6026/steps/test_llvm/logs/LLVM%20%3A%3A%20CodeGen__AArch64__machine-outliner-remarks.ll

llvm-svn: 312219

show more ...

[MachineOutliner] Add missed optimization remarks for the outliner.

This adds missed optimization remarks which report viable candidates that
were not outlined because they would increase code size.

[MachineOutliner] Add missed optimization remarks for the outliner.

This adds missed optimization remarks which report viable candidates that
were not outlined because they would increase code size.

Other remarks will come in separate commits.

This will help to diagnose code size regressions and changes in outliner
behaviour in projects using the outliner.

https://reviews.llvm.org/D37085

llvm-svn: 312194

show more ...

[MachineOutliner] Only outline candidates of length >= 2

Since we don't factor in instruction lengths into outlining calculations
right now, it's never the case that a candidate could have length <

[MachineOutliner] Only outline candidates of length >= 2

Since we don't factor in instruction lengths into outlining calculations
right now, it's never the case that a candidate could have length < 2.

Thus, we should quit early when we see such candidates.

llvm-svn: 310894

show more ...

[MachineOutliner] NFC: Change IsTailCall to a call class + frame class

This commit

- Removes IsTailCall and replaces it with a target-defined unsigned
- Refactors getOutliningCallOverhead and getOu

[MachineOutliner] NFC: Change IsTailCall to a call class + frame class

This commit

- Removes IsTailCall and replaces it with a target-defined unsigned
- Refactors getOutliningCallOverhead and getOutliningFrameOverhead so that they don't use IsTailCall
- Adds a call class + frame class classification to OutlinedFunction and Candidate respectively

This accomplishes a couple things.

Firstly, we don't need the notion of *tail call* in the general outlining algorithm.

Secondly, we now can have different "outlining classes" for each candidate within a set of candidates.
This will make it easy to add new ways to outline sequences for certain targets and dynamically choose
an appropriate cost model for a sequence depending on the context that that sequence lives in.

Ultimately, this should get us closer to being able to do something like, say avoid saving the link
register when outlining AArch64 instructions.

llvm-svn: 309475

show more ...

[MachineOutliner] NFC: Comment tidying

The comment on describing the suffix tree had some pruning
stuff that was out of date in it.

Also fixed some typos.

llvm-svn: 309365

[MachineOutliner] NFC: Split up getOutliningBenefit

This is some more cleanup in preparation for some actual
functional changes. This splits getOutliningBenefit into
two cost functions: getOutlining

[MachineOutliner] NFC: Split up getOutliningBenefit

This is some more cleanup in preparation for some actual
functional changes. This splits getOutliningBenefit into
two cost functions: getOutliningCallOverhead and
getOutliningFrameOverhead. These functions return the
number of instructions that would be required to call
a specific function and the number of instructions
that would be required to construct a frame for a
specific funtion. The actual outlining benefit logic
is moved into the outliner, which calls these functions.

The goal of refactoring getOutliningBenefit is to:

- Get us closer to getting rid of the IsTailCall flag

- Further split up "target-specific" things and
"general algorithm" things

llvm-svn: 309356

show more ...