summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [AArch64] Refactor cheap cost modelEvandro Menezes2018-10-011-12/+23
| | | | | | | Refactor the order in `TII::isAsCheapAsAMove()` to ease future development and maintenance. Practically NFC. llvm-svn: 343489
* [AArch64] Split zero cycle feature more granularlyEvandro Menezes2018-09-281-4/+4
| | | | | | | | | | Split the `zcz` feature into specific ones got GP and FP registers, `zcz-gp` and `zcz-fp`, respectively, while retaining the original feature option to mean both. Differential revision: https://reviews.llvm.org/D52621 llvm-svn: 343354
* [MinGW] [AArch64] Add stubs for potential automatic dllimported variablesMartin Storsjo2018-09-041-1/+2
| | | | | | | | | | | The runtime pseudo relocations can't handle the AArch64 format PC relative addressing in adrp+add/ldr pairs. By using stubs, the potentially dllimported addresses can be touched up by the runtime pseudo relocation framework. Differential Revision: https://reviews.llvm.org/D51452 llvm-svn: 341401
* [AArch64] Hook up the missed machine operand flag name for MO_DLLIMPORTMartin Storsjo2018-08-311-1/+2
| | | | llvm-svn: 341178
* [AArch64] Add Tiny Code Model for AArch64David Green2018-08-221-0/+3
| | | | | | | | | | | | | | This adds the plumbing for the Tiny code model for the AArch64 backend. This, instead of loading addresses through the normal ADRP;ADD pair used in the Small model, uses a single ADR. The 21 bit range of an ADR means that the code and its statically defined symbols need to be within 1MB of each other. This makes it mostly interesting for embedded applications where we want to fit as much as we can in as small a space as possible. Differential Revision: https://reviews.llvm.org/D49673 llvm-svn: 340397
* Remove trailing spaceFangrui Song2018-07-301-3/+3
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338293
* [MachineOutliner][AArch64] Add support for saving LR to a registerJessica Paquette2018-07-301-84/+159
| | | | | | | | | | | | | | | | | | | | | | This teaches the outliner to save LR to a register rather than the stack when possible. This allows us to avoid bumping the stack in outlined functions in some cases. By doing this, in a later patch, we can teach the outliner to do something like this: f1: ... bl OUTLINED_FUNCTION ... f2: ... move LR's contents to a register bl OUTLINED_FUNCTION move the register's contents back instead of falling back to saving LR in both cases. llvm-svn: 338278
* Recommit "Enable MachineOutliner by default under -Oz for AArch64"Jessica Paquette2018-07-271-0/+5
| | | | | | | | | | | | | | | | | | Fixed the ASAN failure from before in r338148, so recommiting. This patch enables the MachineOutliner by default in AArch64 under -Oz. The MachineOutliner offers around a 4.5% improvement on the current -Oz code size improvements. We have done work into improving the debuggability of outlined code, so that users of -Oz won't be surprised by the optimization. We have also been executing the LLVM test suite and common external tests such as the SPEC suites continuously with no issue. The outliner has a low compile-time overhead of roughly 1%. At this point, the outliner would be a really good addition to the -Oz pass pipeline! llvm-svn: 338160
* [MachineOutliner] Exit getOutliningCandidateInfo when we erase all candidatesJessica Paquette2018-07-271-0/+4
| | | | | | | | | | 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
* Revert "Enable MachineOutliner by default under -Oz for AArch64"Jessica Paquette2018-07-271-5/+0
| | | | | | | | | | It failed an Asan test on a bot: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/21543/steps/check-llvm%20asan/logs/stdio Fixing that before recommitting. llvm-svn: 338136
* Enable MachineOutliner by default under -Oz for AArch64Jessica Paquette2018-07-271-0/+5
| | | | | | | | | | | | | | | | This patch enables the MachineOutliner by default in AArch64 under -Oz. The MachineOutliner offers around a 4.5% improvement on the current -Oz code size improvements. We have done work into improving the debuggability of outlined code, so that users of -Oz won't be surprised by the optimization. We have also been executing the LLVM test suite and common external tests such as the SPEC suites continuously with no issue. The outliner has a low compile-time overhead of roughly 1%. At this point, the outliner would be a really good addition to the -Oz pass pipeline! llvm-svn: 338133
* [MachineOutliner][NFC] Move target frame info into OutlinedFunctionJessica Paquette2018-07-241-10/+11
| | | | | | | | | | | | | | 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-16/+25
| | | | | | | | | | | | | 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] Assert that Liveness tracking is accurate (NFC)Yvan Roux2018-07-071-0/+2
| | | | | | | | | | The checking is done deeper inside MachineBasicBlock, but this will hopefully help to find issues when porting the machine outliner to a target where Liveness tracking is broken (like ARM). Differential Revision: https://reviews.llvm.org/D49023 llvm-svn: 336481
* [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] Don't outline sequences where x16/x17/nzcv are live acrossJessica Paquette2018-06-271-24/+41
| | | | | | | | | | | | | | 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/+1
| | | | | | | | | | | | 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-48/+47
| | | | | | | | | | | | | | | | | | | | | 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
* Delete unused variable from r333015.Eli Friedman2018-05-221-3/+0
| | | | | | | (The assertion suppressed the unused variable warning on Release+Asserts builds, so I didn't notice.) llvm-svn: 333018
* [MachineOutliner] Add "thunk" outlining for AArch64.Eli Friedman2018-05-221-18/+83
| | | | | | | | | | | | | | | | | | | | | | 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-11/+15
| | | | | | | | | | 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] Don't outline instructions that modify SP.Eli Friedman2018-05-161-0/+8
| | | | | | | | | | | | | This breaks the code which saves and restores LR, so we can't outline without doing something more complicated for stack adjustment. Found by inspection; we get lucky in most cases because getMemOpInfo only handles STRWpost, not any other pre/post-increment forms. But it hits a couple of artificial testcases in the tree. Differential Revision: https://reviews.llvm.org/D46920 llvm-svn: 332529
* [MachineOutliner] Don't save/restore LR for tail calls.Eli Friedman2018-05-161-3/+4
| | | | | | | | | The cost computation assumes we do this correctly, but the actual lowering was wrong. Differential Revision: https://reviews.llvm.org/D46923 llvm-svn: 332514
* [DebugInfo] Examine all uses of isDebugValue() for debug instructions.Shiva Chen2018-05-091-1/+1
| | | | | | | | | | | | | | | | | | Because we create a new kind of debug instruction, DBG_LABEL, we need to check all passes which use isDebugValue() to check MachineInstr is debug instruction or not. When expelling debug instructions, we should expel both DBG_VALUE and DBG_LABEL. So, I create a new function, isDebugInstr(), in MachineInstr to check whether the MachineInstr is debug instruction or not. This patch has no new test case. I have run regression test and there is no difference in regression test. Differential Revision: https://reviews.llvm.org/D45342 Patch by Hsiangkai Wang. llvm-svn: 331844
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-011-2/+2
| | | | | | | | | | | | | | | | 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-2/+5
| | | | | | | | | | | | | 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] Don't outline from functions with a section marking.Eli Friedman2018-04-271-0/+7
| | | | | | | | | | | | | | The program might have unusual expectations for functions; for example, the Linux kernel's build system warns if it finds references from .text to .init.data. I'm not sure this is something we actually want to make any guarantees about (there isn't any explicit rule that would disallow outlining in this case), but we might want to be conservative anyway. Differential Revision: https://reviews.llvm.org/D46091 llvm-svn: 331007
* [MachineOutliner] Check for explicit uses of LR/W30 in MI operandsJessica Paquette2018-04-241-0/+5
| | | | | | | | | | Before, the outliner would grab ADRPs that used LR/W30. This patch fixes that by checking for explicit uses of those registers before the special-casing for ADRPs. This also adds a test that ensures that those sorts of ADRPs won't be outlined. llvm-svn: 330783
* [MachineOutliner] Change B instruction for tail calls to TCRETURNdiJessica Paquette2018-04-201-2/+3
| | | | | | | | | | First off, this is more correct than having the B. Second off, this was making a bot upset. This fixes that. Update the test to include -verify-machineinstrs as well to prevent stuff like this slipping by non debug/assert builds in the future. llvm-svn: 330459
* [MachineOutliner] Keep track of fns that use a redzone in AArch64FunctionInfoJessica Paquette2018-04-031-5/+8
| | | | | | | | | | | | This patch adds a hasRedZone() function to AArch64MachineFunctionInfo. It returns true if the function is known to use a redzone, false if it is known to not use a redzone, and no value otherwise. This removes the requirement to pass -mno-red-zone when outlining for AArch64. https://reviews.llvm.org/D45189 llvm-svn: 329120
* [MachineOutliner] Simplify call outlining + require valid callee save info ↵Jessica Paquette2018-03-281-31/+18
| | | | | | | | | | for call outlining This commit simplifies the call outlining logic by removing references to the Function associated with the callee. To do this, it requires that valid callee save info is available to the outliner. llvm-svn: 328719
* [MachineOutliner] AArch64: Don't outline ADRPs with un-outlinable operandsJessica Paquette2018-03-271-11/+7
| | | | | | | | | If an ADRP appears with, say, a CPI operand, we shouldn't outline it. This moves the check for unsafe operands so that it occurs before the special-case for ADRPs. Also add a test for outlining ADRPs. llvm-svn: 328674
* [MachineOutliner] AArch64: Emit CFI instructions when outlining callsJessica Paquette2018-03-191-0/+19
| | | | | | | | | | | When outlining calls, the outliner needs to update CFI to ensure that, say, exception handling works. This commit adds that functionality and adds a test just for call outlining. Call outlining stuff in machine-outliner.mir should be moved into machine-outliner-calls.mir in a later commit. llvm-svn: 327917
* [MachineOutliner] Make KILLs invisibleJessica Paquette2018-03-161-0/+5
| | | | | | | | | At the point the outliner runs, KILLs don't impact anything, but they're still considered unique instructions. This commit makes them invisible like DebugValues so that they can still be outlined without impacting outlining decisions. llvm-svn: 327760
* [AArch64] Adjust the cost model for Exynos M3Evandro Menezes2018-03-151-10/+52
| | | | | | Increase the number of cheap as move cases of register reset. llvm-svn: 327661
* [AArch64] Refactor stand alone methods (NFC)Evandro Menezes2018-02-091-12/+128
| | | | | | Make stand alone methods in AArch64InstrInfo static. llvm-svn: 324745
* [AArch64] Add new target feature to handle cheap as move for ExynosEvandro Menezes2018-01-301-2/+1
| | | | | | | | | This feature enables special handling of cheap as move in the existing custom handling specifically for Exynos processors. Differential revision: https://reviews.llvm.org/D42387 llvm-svn: 323774
* [AArch64] Add pipeline model for Exynos M3Evandro Menezes2018-01-301-3/+37
| | | | | | | | Add the scheduling and cost model for Exynos M3. Differential revision: https://reviews.llvm.org/D42387 llvm-svn: 323773
* [AArch64] Generate the CASP instruction for 128-bit cmpxchgOliver Stannard2018-01-291-0/+20
| | | | | | | | | | | | | | | | The Large System Extension added an atomic compare-and-swap instruction that operates on a pair of 64-bit registers, which we can use to implement a 128-bit cmpxchg. Because i128 is not a legal type for AArch64 we have to do all of the instruction selection in C++, and the instruction requires even/odd register pairs, so we have to wrap it in REG_SEQUENCE and EXTRACT_SUBREG nodes. This is very similar to what we do for 64-bit cmpxchg in the ARM backend. Differential revision: https://reviews.llvm.org/D42104 llvm-svn: 323634
* [MachineOutliner] Move hasAddressTaken check to MachineOutliner.cppJessica Paquette2018-01-131-4/+0
| | | | | | | | | | | | | *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] Outline ADRPsJessica Paquette2018-01-101-0/+6
| | | | | | | | | ADRP instructions weren't being outlined because they're PC-relative and thus fail the LR checks. This patch adds a special case for ADRPs to getOutliningType to make sure that ADRPs can be outlined and updates the MIR test. llvm-svn: 322207
* [MachineOutliner] AArch64: Handle instrs that use SP and will never need fixupsJessica Paquette2018-01-091-11/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [AArch64] Change order of candidate FMLS patternsMatthew Simpson2017-12-271-22/+22
| | | | | | | | | | | | | | | | | | | | | r319980 added new patterns to the machine combiner for transforming (fsub (fmul x y) z) into (fmla (fneg z) x y). That is, fsub's where the first source operand is an fmul are transformed. We previously only matched the case where the second source operand of an fsub was an fmul, transforming (fsub z (fmul x y)) into (fmls z x y). Now, if we have an fsub where both source operands are fmuls, both of the above patterns are applicable. However, the order in which we add the patterns to the list of candidates determines the transformation that takes place, since only the first pattern that matches will be used. This patch changes the order these two patterns are added to the list of candidates such that we prefer the case where the second source operand is an fmul (the fmls case), rather than the other one (the fmla/fneg case). When both source operands are fmuls, this ordering results in fewer instructions. Differential Revision: https://reviews.llvm.org/D41587 llvm-svn: 321491
* [MachineOutliner][NFC] Gardening: use std::any_of instead of bool + loopJessica Paquette2017-12-181-10/+3
| | | | | | | River Riddle suggested to use std::any_of instead of the bool + loop thing on r320229. This commit does that. llvm-svn: 321028
* [MachineOutliner] Recommit r320229Jessica Paquette2017-12-181-60/+174
| | | | | | | LR was undefined entering outlined functions that contain calls. This made the machine verifier unhappy when expensive checks were enabled. This fixes that. llvm-svn: 321014
* MachineFunction: Return reference from getFunction(); NFCMatthias Braun2017-12-151-5/+5
| | | | | | The Function can never be nullptr so we can return a reference. llvm-svn: 320884
* [CodeGen] Print stack object references as %(fixed-)stack.0 in both MIR and ↵Francis Visoiu Mistrih2017-12-151-3/+3
| | | | | | | | | | | | | | debug output Work towards the unification of MIR and debug output by printing `%stack.0` instead of `<fi#0>`, and `%fixed-stack.0` instead of `<fi#-4>` (supposing there are 4 fixed stack objects). Only debug syntax is affected. Differential Revision: https://reviews.llvm.org/D41027 llvm-svn: 320827
* Reverted r320229. It broke tests on builder ↵Galina Kistanova2017-12-131-118/+4
| | | | | | llvm-clang-x86_64-expensive-checks-win. llvm-svn: 320588
* [MachineOutliner] Outline callsJessica Paquette2017-12-091-4/+118
| | | | | | | | | | | | | The outliner previously would never outline calls. Calls are pretty common in files, so it makes sense to outline them. In fact, in the LLVM test suite, if you count the number of instructions that the outliner misses when you outline calls vs when you don't, it turns out that, on average, around 6% of the instructions encountered are calls. So, if we outline calls, we can find more candidates, and thus save some more space. This commit adds that functionality and updates the mir test to reflect that. llvm-svn: 320229
* [MachineOutliner] Fix offset overflow checkJessica Paquette2017-12-071-4/+6
| | | | | | | | | | | | The offset overflow check before was incorrect. It would always give the correct result, but it was comparing the SCALED potential fixed-up offset against an UNSCALED minimum/maximum. As a result, the outliner was missing a bunch of frame setup/destroy instructions that ought to have been safe to outline. This fixes that, and adds an instruction to the .mir test that failed the old test. llvm-svn: 320090
OpenPOWER on IntegriCloud