Commit Graph

126 Commits

Author SHA1 Message Date
Simon Pilgrim b2cd273416 Fix Wdocumentation warning. NFCI. 2020-01-10 10:32:37 +00:00
Jessica Paquette acd2580824 [MachineOutliner][AArch64] Save + restore LR in noreturn functions
Conservatively always save + restore LR in noreturn functions.

These functions do not end in a RET, and so they aren't guaranteed to have an
instruction which uses LR in any way. So, as a result, you can end up in
unfortunate situations where you can't backtrace out of these functions in a
debugger.

Remove the old noreturn test, and add a new one which is more descriptive.

Remove the restriction that we can't outline from noreturn functions as well
since we now do the right thing.
2020-01-07 11:27:25 -08:00
Jessica Paquette d5750770eb [NFC][MachineOutliner] Rewrite setSuffixIndices to be iterative
Having this function be recursive could use up way too much stack space.

Rewrite it as an iterative traversal in the tree instead to prevent this.

Fixes PR44344.
2019-12-20 16:12:37 -08:00
Reid Kleckner 05da2fe521 Sink all InitializePasses.h includes
This file lists every pass in LLVM, and is included by Pass.h, which is
very popular. Every time we add, remove, or rename a pass in LLVM, it
caused lots of recompilation.

I found this fact by looking at this table, which is sorted by the
number of times a file was changed over the last 100,000 git commits
multiplied by the number of object files that depend on it in the
current checkout:
  recompiles    touches affected_files  header
  342380        95      3604    llvm/include/llvm/ADT/STLExtras.h
  314730        234     1345    llvm/include/llvm/InitializePasses.h
  307036        118     2602    llvm/include/llvm/ADT/APInt.h
  213049        59      3611    llvm/include/llvm/Support/MathExtras.h
  170422        47      3626    llvm/include/llvm/Support/Compiler.h
  162225        45      3605    llvm/include/llvm/ADT/Optional.h
  158319        63      2513    llvm/include/llvm/ADT/Triple.h
  140322        39      3598    llvm/include/llvm/ADT/StringRef.h
  137647        59      2333    llvm/include/llvm/Support/Error.h
  131619        73      1803    llvm/include/llvm/Support/FileSystem.h

Before this change, touching InitializePasses.h would cause 1345 files
to recompile. After this change, touching it only causes 550 compiles in
an incremental rebuild.

Reviewers: bkramer, asbirlea, bollu, jdoerfert

Differential Revision: https://reviews.llvm.org/D70211
2019-11-13 16:34:37 -08:00
Simon Pilgrim 117e6dd6cc Remove redundant assignment. NFCI.
Fixes cppcheck warning.
2019-11-05 17:08:08 +00:00
Simon Pilgrim 76166a1ac7 Use iterator prefix increment. NFCI. 2019-11-05 17:08:08 +00:00
Simon Pilgrim 7ad2583613 [MachineOutliner] Reduce scope of variable and stop duplicate getMF() calls. NFCI. 2019-11-05 17:08:08 +00:00
Simon Pilgrim c7f127d93f [MachineOutliner] Fix uninitialized variable warnings. NFCI. 2019-11-05 15:15:14 +00:00
David Tellenbach fbe7f5e972 [NFC][MachineOutliner] Fix typo in comment 2019-10-30 16:28:11 +00:00
Puyan Lotfi 6b7615ae9a [MachineOutliner][NFC] clang-formating the MachineOutliner. 2019-10-28 17:58:27 -04:00
Puyan Lotfi a51fc8ddf8 [MachineOuliner][NFC] Refactoring code to make outline rerunning a cleaner diff.
I want to add the ability to rerun the outliner in certain cases, and I
thought this could be an NFC change that could make a subsequent change
that allows for rerunning the outliner a cleaner diff.

Differential Revision: https://reviews.llvm.org/D69482
2019-10-28 15:13:45 -04:00
Nikola Prica 98603a8153 [DebugInfo][If-Converter] Update call site info during the optimization
During the If-Converter optimization pay attention when copying or
deleting call instructions in order to keep call site information in
valid state.

Reviewers: aprantl, vsk, efriedma

Reviewed By: vsk, efriedma

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

llvm-svn: 374068
2019-10-08 15:43:12 +00:00
Jessica Paquette 784892c964 [MachineOutliner] Disable outlining from noreturn functions
Outlining from noreturn functions doesn't do the correct thing right now. The
outliner should respect that the caller is marked noreturn. In the event that
we have a noreturn function, and the outlined code is in tail position, the
outliner will not see that the outlined function should be tail called. As a
result, you end up with a regular call containing a return.

Fixing this requires that we check that all candidates live inside noreturn
functions. So, for the sake of correctness, don't outline from noreturn
functions right now.

Add machine-outliner-noreturn.mir to test this.

llvm-svn: 373791
2019-10-04 21:24:12 +00:00
Yuanfang Chen cc382cf727 [NewPM] Port MachineModuleInfo to the new pass manager.
Existing clients are converted to use MachineModuleInfoWrapperPass. The
new interface is for defining a new pass manager API in CodeGen.

Reviewers: fedor.sergeev, philip.pfaffe, chandlerc, arsenm

Reviewed By: arsenm, fedor.sergeev

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

llvm-svn: 373240
2019-09-30 17:54:50 +00:00
Djordje Todorovic 71d3869f60 [Backend] Keep call site info valid through the backend
Handle call instruction replacements and deletions in order to preserve
valid state of the call site info of the MachineFunction.

NOTE: If the call site info is enabled for a new target, the assertion from
the MachineFunction::DeleteMachineInstr() should help to locate places
where the updateCallSiteInfo() should be called in order to preserve valid
state of the call site info.

([10/13] Introduce the debug entry values.)

Co-authored-by: Ananth Sowda <asowda@cisco.com>
Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com>
Co-authored-by: Ivan Baev <ibaev@cisco.com>

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

llvm-svn: 364536
2019-06-27 13:10:29 +00:00
Fangrui Song efd94c56ba Use llvm::stable_sort
While touching the code, simplify if feasible.

llvm-svn: 358996
2019-04-23 14:51:27 +00:00
Fangrui Song ae6c9403d1 [MachineOutliner] Replace ostringstream based string concatenation with Twine
This makes my libLLVMCodeGen.so.9svn 4936 bytes smaller.

While here, delete unused #include <map>

llvm-svn: 358089
2019-04-10 14:52:37 +00:00
James Y Knight 13680223b9 [opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.

Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.

Then:
- update the CallInst/InvokeInst instruction creation functions to
  take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.

One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.

However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)

Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.

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

llvm-svn: 352827
2019-02-01 02:28:03 +00:00
James Y Knight fadf25068e Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."
This reverts commit f47d6b38c7 (r352791).

Seems to run into compilation failures with GCC (but not clang, where
I tested it). Reverting while I investigate.

llvm-svn: 352800
2019-01-31 21:51:58 +00:00
James Y Knight f47d6b38c7 [opaque pointer types] Add a FunctionCallee wrapper type, and use it.
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.

Then:
- update the CallInst/InvokeInst instruction creation functions to
  take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.

One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.

However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)

Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.

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

llvm-svn: 352791
2019-01-31 20:35:56 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
Simon Pilgrim 845d5a0aa8 Fix Wdocumentation warning. NFCI.
llvm-svn: 348517
2018-12-06 19:17:28 +00:00
Jessica Paquette 3cd70b385d [MachineOutliner][NFC] Move yet another std::vector out of a loop
Once again, following the wisdom of the LLVM Programmer's Manual.

I think that's enough refactoring for today. :)

llvm-svn: 348439
2018-12-06 00:26:21 +00:00
Jessica Paquette d4e7d0749b [MachineOutliner][NFC] Move std::vector out of loop
See http://llvm.org/docs/ProgrammersManual.html#vector

llvm-svn: 348433
2018-12-06 00:04:03 +00:00
Jessica Paquette ca3ed964f1 [MachineOutliner][NFC] Remove IntegerInstructionMap from InstructionMapper
Refactoring.

This map was only used when we used a string of integers to output the outlined
sequence. Since it's no longer used for anything, there's no reason to keep it
around.

llvm-svn: 348432
2018-12-06 00:01:51 +00:00
Jessica Paquette ce3a2dcf70 [MachineOutliner][NFC] Remove buildCandidateList and replace with findCandidates
More refactoring.

Since the pruning logic has changed, and the candidate list is gone,
everything can be sunk into findCandidates.

We no longer need to keep track of the length of the longest substring, so we
can drop all of that logic as well.

After this, we just find all of the candidates and move to outlining.

llvm-svn: 348428
2018-12-05 23:39:07 +00:00
Jessica Paquette e18d6ff036 [MachineOutliner][NFC] Candidates don't need to be shared_ptrs anymore
More refactoring.

After the changes to the pruning logic, and removing CandidateList, there's
no reason for Candiates to be shared_ptrs (or pointers at all).

std::shared_ptr<Candidate> -> Candidate.

llvm-svn: 348427
2018-12-05 23:24:22 +00:00
Jessica Paquette 4ae3b71df0 [MachineOutliner][NFC] Remove CandidateList, since it's now unused.
After removing the pruning logic, there's no reason to populate a list of
Candidates. Remove CandidateList and update comments.

llvm-svn: 348422
2018-12-05 22:50:26 +00:00
Jessica Paquette d9d9309bd4 Fix buildbot capture warning
A bot didn't like my lambda. This ought to fix it.

Example:

http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/30139/steps/build%20lld/logs/stdio

error C3493: 'AlreadyRemoved' cannot be implicitly captured because no default
capture mode has been specified

llvm-svn: 348421
2018-12-05 22:47:25 +00:00
Jessica Paquette 235d877eea [MachineOutliner][NFC] Simplify and unify pruning/outlining logic
Since we're now performing outlining per OutlinedFunction rather than per
Candidate, we can simply outline each candidate as it shows up.

Instead of having a pruning phase, instead, we'll outline entire functions.
Then we'll update the UnsignedVec we mapped to reflect the deletion. If any
candidate is in a space that's marked dirty, then we'll drop it.

This lets us remove the pruning logic entirely, and greatly simplifies the
code.

llvm-svn: 348420
2018-12-05 22:27:38 +00:00
Jessica Paquette 962b3ae659 [MachineOutliner] Outline functions by order of benefit
Mostly NFC, only change is the order of outlined function names.

Loop over the outlined functions instead of walking the candidate list.

This is a bit easier to understand. It's far more natural to create a function,
then replace all of its occurrences with calls than the other way around.

The functions outlined after this do not change, but their names will be
decided by their benefit. E.g, OUTLINED_FUNCTION_0 will now always be the
most beneficial function, rather than the first one seen.

This makes it easier to enforce an ordering on the outlined functions. So,
this also adds a test to make sure that the ordering works as expected.

llvm-svn: 348414
2018-12-05 21:36:04 +00:00
Jessica Paquette 34b618bf7e [MachineOutliner][NFC] Don't create outlined sequence from integer mapping
Some gardening/refactoring.

It's cleaner to copy the instructions into the MachineFunction using the first
candidate instead of going to the mapper.

Also, by doing this we can remove the Seq member from OutlinedFunction entirely.

llvm-svn: 348390
2018-12-05 17:57:33 +00:00
Simon Pilgrim 01f4c4be90 Fix Wdocumentation warning. NFCI.
llvm-svn: 347253
2018-11-19 19:18:33 +00:00
Paul Robinson cda5421016 [DebugInfo] DISubprogram flags get their own flags word. NFC.
This will hold flags specific to subprograms. In the future
we could potentially free up scarce bits in DIFlags by moving
subprogram-specific flags from there to the new flags word.

This patch does not change IR/bitcode formats, that will be
done in a follow-up.

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

llvm-svn: 347239
2018-11-19 18:29:28 +00:00
Jessica Paquette ddb039a199 [MachineOutliner][NFC] Check if CandidatesForRepeatedSeq < 2
There's no reason to call getOutliningCandidateInfo with a single candidate.

llvm-svn: 346913
2018-11-15 00:02:24 +00:00
Jessica Paquette cad864d49e [MachineOutliner][NFC] Use MBB flags to avoid call checks in getOutliningInfo
We already determine a bunch of information about an MBB in
getMachineOutlinerMBBFlags. We can reuse that information to avoid calculating
things that must be false/true.

The first thing we can easily check is if an outlined sequence could ever
contain calls. There's no reason to walk over the outlined range, checking for
calls, if we already know that there are no calls in the block containing the
sequence.

llvm-svn: 346809
2018-11-13 23:01:34 +00:00
Jessica Paquette b2d53c5d7d [MachineOutliner][NFC] Exit getOutliningType if there are < 2 candidates
Since we never outline anything with fewer than 2 occurrences, there's no
reason to compute cost model information if there's less than that.

llvm-svn: 346803
2018-11-13 22:16:27 +00:00
Alexander Kornienko 3635c89070 Fix uninitialized variable.
Flags variable was not initialized and later used (both isMBBSafeToOutlineFrom
implementations assume it's initialized), which breaks
test/CodeGen/AArch64/machine-outliner.mir. under memory sanitizer:
MemorySanitizer: use-of-uninitialized-value
    #0  in llvm::AArch64InstrInfo::getOutliningType(llvm::MachineInstrBundleIterator<llvm::MachineInstr, false>&, unsigned int) const llvm/lib/Target/AArch64/AArch64InstrInfo.cpp:5494:9
    #1  in (anonymous namespace)::InstructionMapper::convertToUnsignedVec(llvm::MachineBasicBlock&, llvm::TargetInstrInfo const&) llvm/lib/CodeGen/MachineOutliner.cpp:772:19
    #2  in (anonymous namespace)::MachineOutliner::populateMapper((anonymous namespace)::InstructionMapper&, llvm::Module&, llvm::MachineModuleInfo&) llvm/lib/CodeGen/MachineOutliner.cpp:1543:14
    #3  in (anonymous namespace)::MachineOutliner::runOnModule(llvm::Module&) llvm/lib/CodeGen/MachineOutliner.cpp:1645:3
    #4  in (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) llvm/lib/IR/LegacyPassManager.cpp:1744:27
    #5  in llvm::legacy::PassManagerImpl::run(llvm::Module&) llvm/lib/IR/LegacyPassManager.cpp:1857:44
    #6  in compileModule(char**, llvm::LLVMContext&) llvm/tools/llc/llc.cpp:597:8

llvm-svn: 346761
2018-11-13 16:41:05 +00:00
Jessica Paquette 82d9c0a3fa [MachineOutliner][NFC] Change getMachineOutlinerMBBFlags to isMBBSafeToOutlineFrom
Instead of returning Flags, return true if the MBB is safe to outline from.

This lets us check for unsafe situations, like say, in AArch64, X17 is live
across a MBB without being defined in that MBB. In that case, there's no point
in performing an instruction mapping.

llvm-svn: 346718
2018-11-12 23:51:32 +00:00
Jessica Paquette 9702144341 [MachineOutliner][NFC] Early exit pruning when candidates don't share an MBB
There's no way they can overlap in this case.

This can save a few iterations when the candidate is close to the beginning
of a MachineBasicBlock. It's particularly useful when the average length of
a MachineBasicBlock in the program is small.

llvm-svn: 346682
2018-11-12 17:50:56 +00:00
Jessica Paquette 3954272ac1 [MachineOutliner][NFC] Put suffix tree in buildCandidateList
It's only used there, so it doesn't make much sense to have it in runOnModule.

llvm-svn: 346681
2018-11-12 17:50:55 +00:00
Jessica Paquette c4cf775ae0 [MachineOutliner][NFC] Only map blocks which have adjacent legal instructions
If a block doesn't have any ranges of adjacent legal instructions, then it
can't have outlining candidates. There's no point in mapping legal isntructions
in situations like this.

I noticed this reduces the size of the suffix tree in sqlite3 for AArch64 at
-Oz by about 3%.

llvm-svn: 346379
2018-11-08 00:33:38 +00:00
Jessica Paquette 267d266c29 [MachineOutliner][NFC] Don't map MBBs that don't contain legal instructions
I noticed that there are lots of basic blocks that don't have enough legal
instructions in them to warrant outlining. We can skip mapping these entirely.

In sqlite3, compiled for AArch64 at -Oz, this results in a 10% reduction of
the total nodes in the suffix tree. These nodes can never be part of a
repeated substring, and so they don't impact the result at all.

Before this, there were 62128 nodes in the tree for sqlite3. After this, there
are 56457 nodes.

llvm-svn: 346373
2018-11-08 00:02:11 +00:00
Jessica Paquette df5b09b8ce [MachineOutliner][NFC] Remove Parent field from SuffixTreeNode
This is only used for calculating ConcatLen. This isn't necessary,
since it's easily derived from the traversal setting suffix indices.

Remove that. Rename CurrIdx to CurrNodeLen to better describe what's
going on.

llvm-svn: 346349
2018-11-07 19:56:13 +00:00
Jessica Paquette a409cc959b [MachineOutliner][NFC] Traverse suffix tree using a RepeatedSubstring iterator
This takes the traversal methods introduced in r346269 and adapts them
into an iterator. This allows the outliner to iterate over repeated substrings
within the suffix tree directly without having to initially find all of the
substrings and then iterate over them after you've found them.

llvm-svn: 346345
2018-11-07 19:20:55 +00:00
Jessica Paquette a3eb0fac3b [MachineOutliner] Don't store outlined function numberings on OutlinedFunction
NFC-ish. This doesn't change the behaviour of the outliner, but does make sure
that you won't end up with say

OUTLINED_FUNCTION_2:
...
ret

OUTLINED_FUNCTION_248:
...
ret

as the only outlined functions in your module. Those should really be

OUTLINED_FUNCTION_0:
...
ret

OUTLINED_FUNCTION_1:
...
ret

If we produce outlined functions, they probably should have sequential numbers
attached to them. This makes it a bit easier+stable to write outliner tests.

The point of this is to move towards a bit more stability in outlined function
names. By doing this, we at least don't rely on the traversal order of the
suffix tree. Instead, we rely on the order of the candidate list, which is
*far* more consistent. The candidate list is ordered by the end indices of
candidates, so we're more likely to get a stable ordering. This is still
susceptible to changes in the cost model though (like, if we suddenly find new
candidates, for example).

llvm-svn: 346340
2018-11-07 18:36:43 +00:00
Jessica Paquette 935d373db9 [MachineOutliner][NFC] Remove OccurrenceCount from SuffixTreeNode
After changing the way we find candidates in r346269, this is no longer used.

llvm-svn: 346275
2018-11-06 22:23:13 +00:00
Jessica Paquette 979cf1e566 [MachineOutliner][NFC] Remove IsInTree from SuffixTreeNode
After changing the way we find repeated substrings in r346269, this
field is no longer used by anything, so it can be removed.

llvm-svn: 346274
2018-11-06 22:21:11 +00:00
Jessica Paquette 4e54ef8883 [MachineOutliner][NFC] Add findRepeatedSubstrings to SuffixTree, kill LeafVector
Instead of iterating over the leaves to find repeated substrings, and walking
collecting leaf children when we don't necessarily need them, let's just
calculate what we need and iterate over that.

By doing this, we don't have to save every leaf. It's easier to read the code
too and understand what's going on.

The goal here, at the end of the day, is to set up to allow us to do something
like

for (RepeatedSubstring &RS : ST) {
 ... do stuff with RS ...
}

Which would let us perform the cost model stuff and the repeated substring
query at the same time.

llvm-svn: 346269
2018-11-06 21:46:41 +00:00
Jessica Paquette c991cf3687 [MachineOutliner][NFC] Remember when you map something illegal across MBBs
Instruction mapping in the outliner uses "illegal numbers" to signify that
something can't ever be part of an outlining candidate. This means that the
number is unique and can't be part of any repeated substring.

Because each of these is unique, we can use a single unique number to represent
a range of things we can't outline.

The outliner tries to leverage this using a flag which is set in an MBB when
the previous instruction we tried to map was "illegal". This patch improves
that logic to work across MBBs. As a bonus, this also simplifies the mapping
logic somewhat.

This also updates the machine-outliner-remarks test, which was impacted by the
order of Candidates on an OutlinedFunction changing. This order isn't
guaranteed, so I added a FIXME to fix that in a follow-up. The order of
Candidates on an OutlinedFunction isn't important, so this still is NFC.

llvm-svn: 345906
2018-11-01 23:09:06 +00:00