summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/MachineOutliner.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [MachineOutliner] Inherit target features from parent functionJessica Paquette2018-10-291-0/+8
| | | | | | | | | | | | | | | If a function has target features, it may contain instructions that aren't represented in the default set of instructions. If the outliner pulls out one of these instructions, and the function doesn't have the right attributes attached, we'll run into an LLVM error explaining that the target doesn't support the necessary feature for the instruction. This makes outlined functions inherit target features from their parents. It also updates the machine-outliner.ll test to check that we're properly inheriting target features. llvm-svn: 345535
* [MachineOutliner][NFC] Don't add MBBs with a size < 2 to the search spaceJessica Paquette2018-09-201-1/+5
| | | | | | | | | | | The suffix tree won't ever consider sequences with a length less than 2. Therefore, we really ought to not even consider them in the first place. Also add a FIXME explaining that this should be defined in terms of the size in B of an outlined call versus the size in B of the MBB. llvm-svn: 342688
* [MachineOutliner][NFC] Move debug info emission to createOutlinedFunctionJessica Paquette2018-09-201-35/+23
| | | | | | | | | When you create an outlined function, you know everything you need to know to decide if debug info should be created. If we emit debug info in createOutlinedFunction, then we don't need to keep track of every IR function we create. llvm-svn: 342677
* [MachineOutliner][NFC] Don't map more illegal instrs than you have toJessica Paquette2018-09-171-0/+11
| | | | | | | | | | | | | | | We were mapping an instruction every time we saw something we couldn't map before this. Since each illegal mapping is unique, we only have to do this once. This makes it so that we don't map illegal instructions when the previous mapped instruction was illegal. In CTMark (AArch64), this results in 240 fewer instruction mappings on average over 619 files in total. The largest improvement is 12576 fewer mappings in one file, and the smallest is 0. The median improvement is 101 fewer mappings. llvm-svn: 342405
* [MachineOutliner] Add codegen size remarks to the MachineOutlinerJessica Paquette2018-09-111-1/+103
| | | | | | | | | | | | | | | | Since the outliner is a module pass, it doesn't get codegen size remarks like the other codegen passes do. This adds size remarks *to* the outliner. This is kind of a workaround, so it's peppered with FIXMEs; size remarks really ought to not ever be handled by the pass itself. However, since the outliner is the only "MachineModulePass", this works for now. Since the entire purpose of the MachineOutliner is to produce code size savings, it really ought to be included in codgen size remarks. If we ever go ahead and make a MachineModulePass (say, something similar to MachineFunctionPass), then all of this ought to be moved there. llvm-svn: 342009
* [MachineOutliner][NFC] Factor out instruction mapping into its own functionJessica Paquette2018-09-111-28/+38
| | | | | | | Just some tidy-up. Pull the mapper stuff into `populateMapper`. This makes it a bit easier to read what's going on in `runOnModule`. llvm-svn: 341959
* [MI] Change the array of `MachineMemOperand` pointers to beChandler Carruth2018-08-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a generically extensible collection of extra info attached to a `MachineInstr`. The primary change here is cleaning up the APIs used for setting and manipulating the `MachineMemOperand` pointer arrays so chat we can change how they are allocated. Then we introduce an extra info object that using the trailing object pattern to attach some number of MMOs but also other extra info. The design of this is specifically so that this extra info has a fixed necessary cost (the header tracking what extra info is included) and everything else can be tail allocated. This pattern works especially well with a `BumpPtrAllocator` which we use here. I've also added the basic scaffolding for putting interesting pointers into this, namely pre- and post-instruction symbols. These aren't used anywhere yet, they're just there to ensure I've actually gotten the data structure types correct. I'll flesh out support for these in a subsequent patch (MIR dumping, parsing, the works). Finally, I've included an optimization where we store any single pointer inline in the `MachineInstr` to avoid the allocation overhead. This is expected to be the overwhelmingly most common case and so should avoid any memory usage growth due to slightly less clever / dense allocation when dealing with >1 MMO. This did require several ergonomic improvements to the `PointerSumType` to reasonably support the various usage models. This also has a side effect of freeing up 8 bits within the `MachineInstr` which could be repurposed for something else. The suggested direction here came largely from Hal Finkel. I hope it was worth it. ;] It does hopefully clear a path for subsequent extensions w/o nearly as much leg work. Lots of thanks to Reid and Justin for careful reviews and ideas about how to do all of this. Differential Revision: https://reviews.llvm.org/D50701 llvm-svn: 339940
* [MachineOutliner] Clean up subtarget handling.Eli Friedman2018-08-011-23/+22
| | | | | | | | | | | | | | Call shouldOutlineFromFunctionByDefault, isFunctionSafeToOutlineFrom, getOutliningType, and getMachineOutlinerMBBFlags using the correct TargetInstrInfo. And don't create a MachineFunction for a function declaration. The call to getOutliningCandidateInfo is still a little weird, but at least the weirdness is explicitly called out. Differential Revision: https://reviews.llvm.org/D49880 llvm-svn: 338465
* Remove trailing spaceFangrui Song2018-07-301-1/+1
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338293
* [MachineOutliner] Exit getOutliningCandidateInfo when we erase all candidatesJessica Paquette2018-07-271-1/+7
| | | | | | | | | | There was a missing check for if a candidate list was entirely deleted. This adds that check. This fixes an asan failure caused by running test/CodeGen/AArch64/addsub_ext.ll with the MachineOutliner enabled. llvm-svn: 338148
* [MachineOutliner][NFC] Move outlined function remark into its own functionJessica Paquette2018-07-241-31/+33
| | | | | | | This pulls the OutlinedFunction remark out into its own function to make the code a bit easier to read. llvm-svn: 337849
* [MachineOutliner][NFC] Move target frame info into OutlinedFunctionJessica Paquette2018-07-241-5/+4
| | | | | | | | | | | | | | Just some gardening here. Similar to how we moved call information into Candidates, this moves outlined frame information into OutlinedFunction. This allows us to remove TargetCostInfo entirely. Anywhere where we returned a TargetCostInfo struct, we now return an OutlinedFunction. This establishes OutlinedFunctions as more of a general repeated sequence, and Candidates as occurrences of those repeated sequences. llvm-svn: 337848
* [MachineOutliner][NFC] Make Candidates own their call informationJessica Paquette2018-07-241-1/+1
| | | | | | | | | | | | | Before this, TCI contained all the call information for each Candidate. This moves that information onto the Candidates. As a result, each Candidate can now supply how it ought to be called. Thus, Candidates will be able to, say, call the same function in cheaper ways when possible. This also removes that information from TCI, since it's no longer used there. A follow-up patch for the AArch64 outliner will demonstrate this. llvm-svn: 337840
* [MachineOutliner][NFC] Move missed opt remark into its own functionJessica Paquette2018-07-241-39/+46
| | | | | | | | Having the missed remark code in the middle of `findCandidates` made the function hard to follow. This yanks that out into a new function, `emitNotOutliningCheaperRemark`. llvm-svn: 337839
* [MachineOutliner][NFC] Sink some candidate logic into OutlinedFunctionJessica Paquette2018-07-241-15/+6
| | | | | | | | | | | | | | | | | Just some simple gardening to improve clarity. Before, we had something along the lines of 1) Create a std::vector of Candidates 2) Create an OutlinedFunction 3) Create a std::vector of pointers to Candidates 4) Copy those over to the OutlinedFunction and the Candidate list Now, OutlinedFunctions create the Candidate pointers. They're still copied over to the main list of Candidates, but it makes it a bit clearer what's going on. llvm-svn: 337838
* [MachineOutliner] Check the last instruction from the sequence when updating ↵Francis Visoiu Mistrih2018-07-141-1/+1
| | | | | | | | | | | | | | | | | liveness The MachineOutliner was doing an std::for_each from the call (inserted before the outlined sequence) to the iterator at the end of the sequence. std::for_each needs the iterator past the end, so the last instruction was not taken into account when propagating the liveness information. This fixes the machine verifier issue in machine-outliner-disubprogram.ll. Differential Revision: https://reviews.llvm.org/D49295 llvm-svn: 337090
* [MachineOutliner] Fix typo in getOutliningCandidateInfo function nameYvan Roux2018-07-041-1/+1
| | | | | | | | getOutlininingCandidateInfo -> getOutliningCandidateInfo Differential Revision: https://reviews.llvm.org/D48867 llvm-svn: 336285
* [MachineOutliner] Add support for target-default outlining.Jessica Paquette2018-06-301-2/+27
| | | | | | | | | | | | | | | | | This adds functionality to the outliner that allows targets to specify certain functions that should be outlined from by default. If a target supports default outlining, then it specifies that in its TargetOptions. In the case that it does, and the user hasn't specified that they *never* want to outline, the outliner will be added to the pass pipeline and will run on those default functions. This is a preliminary patch for turning the outliner on by default under -Oz for AArch64. https://reviews.llvm.org/D48776 llvm-svn: 336040
* [MachineOutliner] Define MachineOutliner support in TargetOptionsJessica Paquette2018-06-281-9/+0
| | | | | | | | | | | | | | | Targets should be able to define whether or not they support the outliner without the outliner being added to the pass pipeline. Before this, the outliner pass would be added, and ask the target whether or not it supports the outliner. After this, it's possible to query the target in TargetPassConfig, before the outliner pass is created. This ensures that passing -enable-machine-outliner will not modify the pass pipeline of any target that does not support it. https://reviews.llvm.org/D48683 llvm-svn: 335887
* [MachineOutliner] Don't outline sequences where x16/x17/nzcv are live acrossJessica Paquette2018-06-271-1/+0
| | | | | | | | | | | | | | It isn't safe to outline sequences of instructions where x16/x17/nzcv live across the sequence. This teaches the outliner to check whether or not a specific canidate has x16/x17/nzcv live across it and discard the candidate in the case that that is true. https://bugs.llvm.org/show_bug.cgi?id=37573 https://reviews.llvm.org/D47655 llvm-svn: 335758
* [MachineOutliner] NFC: Remove insertOutlinerPrologue, rename ↵Jessica Paquette2018-06-191-5/+2
| | | | | | | | | | | | insertOutlinerEpilogue insertOutlinerPrologue was not used by any target, and prologue-esque code was beginning to appear in insertOutlinerEpilogue. Refactor that into one function, buildOutlinedFrame. This just removes insertOutlinerPrologue and renames insertOutlinerEpilogue. llvm-svn: 335076
* [MachineOutliner] NFC - Move intermediate data structures to MachineOutliner.hJessica Paquette2018-06-041-191/+48
| | | | | | | | | | | | | | | | | | | | | This is setting up to fix bug 37573 cleanly. This moves data structures that are technically both used in some way by the target and the general-purpose outlining algorithm into MachineOutliner.h. In particular, the `Candidate` class is of importance. Before, the outliner passed the locations of `Candidates` to the target, which would then make some decisions about the prospective outlined function. This change allows us to just pass `Candidates` along to the target. This will allow the target to discard `Candidates` that would be considered unsafe before cost calculation. Thus, we will be able to remove the unsafe candidates described in the bug without resorting to torching the entire prospective function. Also, as a side-effect, it makes the outliner a bit cleaner. https://bugs.llvm.org/show_bug.cgi?id=37573 llvm-svn: 333952
* [MachineOutliner] Add "thunk" outlining for AArch64.Eli Friedman2018-05-221-0/+7
| | | | | | | | | | | | | | | | | | | | | | When we're outlining a sequence that ends in a call, we can save up to three instructions in the outlined function by turning the call into a tail-call. I refer to this as thunk outlining because the resulting outlined function looks like a thunk; suggestions welcome for a better name. In addition to making the outlined function shorter, thunk outlining allows outlining calls which would otherwise be illegal to outline: we don't need to save/restore LR, so we don't need to prove anything about the stack access patterns of the callee. To make this work effectively, I also added MachineOutlinerInstrType::LegalTerminator to the generic MachineOutliner code; this allows treating an arbitrary instruction as a terminator in the suffix tree. Differential Revision: https://reviews.llvm.org/D47173 llvm-svn: 333015
* [MachineOutliner] Count savings from outlining in bytes.Eli Friedman2018-05-181-7/+12
| | | | | | | | | | Counting the number of instructions is both unintuitive and inaccurate. On AArch64, this only affects the generated remarks and certain rare pseudo-instructions, but it will have a bigger impact on other targets. Differential Revision: https://reviews.llvm.org/D46921 llvm-svn: 332685
* [MachineOutliner] Add optsize markings to outlined functions.Eli Friedman2018-05-151-0/+8
| | | | | | | | | It doesn't matter much this late in the pipeline, but one place that does check for it is the function alignment code. Differential Revision: https://reviews.llvm.org/D46373 llvm-svn: 332415
* Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-141-8/+9
| | | | | | | | | | | | | | | | The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-011-23/+23
| | | | | | | | | | | | | | | | We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
* [MachineOutliner] Add defs to calls + don't track liveness on outlined functionsJessica Paquette2018-04-271-4/+34
| | | | | | | | | | | | | This commit makes it so that if you outline a def of some register, then the call instruction created by the outliner actually reflects that the register is defined by the call. It also makes it so that outlined functions don't have the TracksLiveness property. Outlined calls shouldn't break liveness assumptions that someone might make. This also un-XFAILs the noredzone test, and updates the calls test. llvm-svn: 331095
* [MachineOutliner] NFC: Move EnableLinkOnceODROutlining into MachineOutliner.cppJessica Paquette2018-04-191-4/+19
| | | | | | | | | This moves the EnableLinkOnceODROutlining flag from TargetPassConfig.cpp into MachineOutliner.cpp. It also removes OutlineFromLinkOnceODRs from the MachineOutliner constructor. This is now handled by the moved command-line flag. llvm-svn: 330373
* [MachineOutliner] Add `useMachineOutliner` target hookJessica Paquette2018-04-041-1/+9
| | | | | | | | | | | | | The MachineOutliner has a bunch of target hooks that will call llvm_unreachable if the target doesn't implement them. Therefore, if you enable the outliner on such a target, it'll just crash. It'd be much better if it'd just *not* run the outliner at all in this case. This commit adds a hook to TargetInstrInfo that returns false by default. Targets that implement the hook make it return true. The outliner checks the return value of this hook to decide whether or not to continue. llvm-svn: 329220
* [MachineOutliner][NFC] Make outlined functions have internal linkageJessica Paquette2018-04-031-1/+1
| | | | | | | | | | | | The linkage type on outlined functions was private before. This meant that if you set a breakpoint in an outlined function, the debugger wouldn't be able to give a sane name to the outlined function. This commit changes the linkage type to internal and updates any tests that relied on the prefixes on the names of outlined functions. llvm-svn: 329116
* [MachineOutliner][NFC] Refactoring + comments in runOnModuleJessica Paquette2018-03-221-12/+33
| | | | | | | | | | | Split up some of the if/else branches in runOnModule. Elaborate on some comments. Replace a call to getOrCreateMachineFunction with getMachineFunction. This makes it clearer what's happening in runOnModule, and ensures that the outliner doesn't create any MachineFunctions which will never be used by the outliner (or anything else, really). llvm-svn: 328240
* [MachineOutliner] Freeze registers in new functionsGeoff Berry2018-01-311-0/+2
| | | | | | | | | | | | | | | Summary: Call MRI.freezeReservedRegs() on functions created during outlining so that calls to isReserved() by the verifier called after this pass won't assert. Reviewers: MatzeB, qcolombet, paquette Subscribers: mcrosier, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D42749 llvm-svn: 323905
* [NFC] fix trivial typos in comments and documentsHiroshi Inoue2018-01-261-1/+1
| | | | | | "in in" -> "in", "on on" -> "on" etc. llvm-svn: 323508
* Add optional DICompileUnit to DIBuilder + make outliner debug info use itJessica Paquette2018-01-191-39/+68
| | | | | | | | | | | | | | | | | | | | | | Previously, the DIBuilder didn't expose functionality to set its compile unit in any other way than calling createCompileUnit. This meant that the outliner, which creates new functions, had to create a new compile unit for its debug info. This commit adds an optional parameter in the DIBuilder's constructor which lets you set its CU at construction. It also changes the MachineOutliner so that it keeps track of the DISubprograms for each outlined sequence. If debugging information is requested, then it uses one of the outlined sequence's DISubprograms to grab a CU. It then uses that CU to construct the DISubprogram for the new outlined function. The test has also been updated to reflect this change. See https://reviews.llvm.org/D42254 for more information. Also see the e-mail discussion on D42254 in llvm-commits for more context. llvm-svn: 322992
* [MachineOutliner] Add DISubprograms to outlined functions.Jessica Paquette2018-01-181-2/+47
| | | | | | | | | | 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
* [MachineOutliner] Move hasAddressTaken check to MachineOutliner.cppJessica Paquette2018-01-131-2/+2
| | | | | | | | | | | | | *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
* [MachineOutliner] AArch64: Handle instrs that use SP and will never need fixupsJessica Paquette2018-01-091-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove redundant includes from lib/CodeGen.Michael Zolotukhin2017-12-131-3/+0
| | | | llvm-svn: 320619
* [MachineOutliner] NFC: Throw out self-intersections on candidates earlyJessica Paquette2017-12-011-11/+42
| | | | | | | | | | | | | | | 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
* Fix a bunch more layering of CodeGen headers that are in TargetDavid Blaikie2017-11-171-2/+2
| | | | | | | | 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
* Target/TargetInstrInfo.h -> CodeGen/TargetInstrInfo.h to match layeringDavid Blaikie2017-11-081-1/+1
| | | | | | | | 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
* [MachineOutliner] Add optimisation remarks for successful outliningJessica Paquette2017-10-231-36/+75
| | | | | | | | | | | | | | | | | | | 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
* [MachineOutliner] NFC: Rename getters/setters to fit coding styleJessica Paquette2017-10-231-13/+13
| | | | | | | Rename endIdx, startIdx, and length to getEndIdx, getStartIdx, and getLength in Candidate. llvm-svn: 316341
* [MachineOutliner][NFC] Clean up prune logic a bitJessica Paquette2017-10-171-33/+36
| | | | | | | | 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
* [MachineOutliner][NFC] Move decrement logic to OutlinedFunctionJessica Paquette2017-10-171-16/+26
| | | | | | | | | | | 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
* [MachineOutliner][NFC] Move end index calculation into CandidateJessica Paquette2017-10-171-20/+31
| | | | | | | | 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
* [NFC] Convert OptimizationRemarkEmitter old emit() calls to new closureVivek Pandya2017-10-111-22/+25
| | | | | | | | | | | | | | 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
* CodeGen: Minor cleanups to use MachineInstr::getMF. NFCJustin Bogner2017-10-101-2/+1
| | | | | | | 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
* [MachineOutliner] Disable outlining from LinkOnceODRs by defaultJessica Paquette2017-10-071-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud