summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/X86/X86FrameLowering.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [WinEH] Add codegen support for cleanuppad and cleanupretReid Kleckner2015-09-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | All of the complexity is in cleanupret, and it mostly follows the same codepaths as catchret, except it doesn't take a return value in RAX. This small example now compiles and executes successfully on win32: extern "C" int printf(const char *, ...) noexcept; struct Dtor { ~Dtor() { printf("~Dtor\n"); } }; void has_cleanup() { Dtor o; throw 42; } int main() { try { has_cleanup(); } catch (int) { printf("caught it\n"); } } Don't try to put the cleanup in the same function as the catch, or Bad Things will happen. llvm-svn: 247219
* Save LaneMask with livein registersMatthias Braun2015-09-091-2/+2
| | | | | | | | | | | | | | | | | With subregister liveness enabled we can detect the case where only parts of a register are live in, this is expressed as a 32bit lanemask. The current code only keeps registers in the live-in list and therefore enumerated all subregisters affected by the lanemask. This turned out to be too conservative as the subregister may also cover additional parts of the lanemask which are not live. Expressing a given lanemask by enumerating a minimum set of subregisters is computationally expensive so the best solution is to simply change the live-in list to store the lanemasks as well. This will reduce memory usage for targets using subregister liveness and slightly increase it for other targets Differential Revision: http://reviews.llvm.org/D12442 llvm-svn: 247171
* [WinEH] Emit prologues and epilogues for funcletsReid Kleckner2015-09-081-8/+136
| | | | | | | | | | | | | | | | | | | | | | | | Summary: 32-bit funclets have short prologues that allocate enough stack for the largest call in the whole function. The runtime saves CSRs for the funclet. It doesn't restore CSRs after we finally transfer control back to the parent funciton via a CATCHRET, but that's a separate issue. 32-bit funclets also have to adjust the incoming EBP value, which is what llvm.x86.seh.recoverframe does in the old model. 64-bit funclets need to spill CSRs as normal. For simplicity, this just spills the same set of CSRs as the parent function, rather than trying to compute different CSR sets for the parent function and each funclet. 64-bit funclets also allocate enough stack space for the largest outgoing call frame, like 32-bit. Reviewers: majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12546 llvm-svn: 247092
* MachineBasicBlock: Add liveins() method returning an iterator_rangeMatthias Braun2015-08-241-10/+6
| | | | llvm-svn: 245895
* Remove redundant TargetFrameLowering::getFrameIndexOffset virtualJames Y Knight2015-08-151-29/+29
| | | | | | | | | | | function. This was the same as getFrameIndexReference, but without the FrameReg output. Differential Revision: http://reviews.llvm.org/D12042 llvm-svn: 245148
* [X86] When optimizing for minsize, use POP for small post-call stack clean-upMichael Kuperstein2015-08-111-1/+68
| | | | | | | | | | | | | | | | When optimizing for size, replace "addl $4, %esp" and "addl $8, %esp" following a call by one or two pops, respectively. We don't try to do it in general, but only when the stack adjustment immediately follows a call - which is the most common case. That allows taking a short-cut when trying to find a free register to pop into, instead of a full-blown liveness check. If the adjustment immediately follows a call, then every register the call clobbers but doesn't define should be dead at that point, and can be used. Differential Revision: http://reviews.llvm.org/D11749 llvm-svn: 244578
* [X86] Remove mergeSPUpdatesUp()Michael Kuperstein2015-07-281-25/+1
| | | | | | | | | | | X86FrameLowering has both a mergeSPUpdates() that accepts a direction, and an mergeSPUpdatesUp(), which seem to do the same thing, except for a slightly different interface. Removed the less general function. NFC. Differential Revision: http://reviews.llvm.org/D11510 llvm-svn: 243396
* Targets: commonize some stack realignment codeJF Bastien2015-07-201-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch does the following: * Fix FIXME on `needsStackRealignment`: it is now shared between multiple targets, implemented in `TargetRegisterInfo`, and isn't `virtual` anymore. This will break out-of-tree targets, silently if they used `virtual` and with a build error if they used `override`. * Factor out `canRealignStack` as a `virtual` function on `TargetRegisterInfo`, by default only looks for the `no-realign-stack` function attribute. Multiple targets duplicated the same `needsStackRealignment` code: - Aarch64. - ARM. - Mips almost: had extra `DEBUG` diagnostic, which the default implementation now has. - PowerPC. - WebAssembly. - x86 almost: has an extra `-force-align-stack` option, which the default implementation now has. The default implementation of `needsStackRealignment` used to just return `false`. My current patch changes the behavior by simply using the above shared behavior. This affects: - AMDGPU - BPF - CppBackend - MSP430 - NVPTX - Sparc - SystemZ - XCore - Out-of-tree targets This is a breaking change! `make check` passes. The only implementation of the `virtual` function (besides the slight different in x86) was Hexagon (which did `MF.getFrameInfo()->getMaxAlignment() > 8`), and potentially some out-of-tree targets. Hexagon now uses the default implementation. `needsStackRealignment` was being overwritten in `<Target>GenRegisterInfo.inc`, to return `false` as the default also did. That was odd and is now gone. Reviewers: sunfish Subscribers: aemerson, llvm-commits, jfb Differential Revision: http://reviews.llvm.org/D11160 llvm-svn: 242727
* [X86] Fix emitPrologue() to make less assumptions about pushesMichael Kuperstein2015-07-161-0/+1
| | | | | | | | | | | | | | | When X86FrameLowering::emitPrologue() looks for where to insert the %esp subtraction to allocate stack space for local allocations, it assumes that any sequence of push instructions that starts at function entry consists purely of spills of callee-save registers. This may be false, since from some point forward, the pushes may pushing arguments to a subsequent function call. This caused a miscompile that was exposed by r240257, and is not easily testable since r240257 was reverted. A test will be committed separately after r240257 is reapplied. llvm-svn: 242395
* MachineRegisterInfo: Remove UsedPhysReg infrastructureMatthias Braun2015-07-141-2/+0
| | | | | | | | | | | | | We have a detailed def/use lists for every physical register in MachineRegisterInfo anyway, so there is little use in maintaining an additional bitset of which ones are used. Removing it frees us from extra book keeping. This simplifies VirtRegMap. Differential Revision: http://reviews.llvm.org/D10911 llvm-svn: 242173
* PrologEpilogInserter: Rewrite API to determine callee save regsiters.Matthias Braun2015-07-141-4/+6
| | | | | | | | | | | | | | | | This changes TargetFrameLowering::processFunctionBeforeCalleeSavedScan(): - Rename the function to determineCalleeSaves() - Pass a bitset of callee saved registers by reference, thus avoiding the function-global PhysRegUsed bitset in MachineRegisterInfo. - Without PhysRegUsed the implementation is fine tuned to not save physcial registers which are only read but never modified. Related to rdar://21539507 Differential Revision: http://reviews.llvm.org/D10909 llvm-svn: 242165
* [WinEH] Make llvm.x86.seh.restoreframe work for stack realignment prologuesReid Kleckner2015-07-071-2/+15
| | | | | | | | | | The incoming EBP value points to the end of a local stack allocation, so we can use that to restore ESI, the base pointer. Once we do that, we can use local stack allocations. If we know we need stack realignment, spill the original frame pointer in the prologue and reload it after restoring ESI. llvm-svn: 241648
* [X86] Rename RegInfo to TRI as suggested by EricReid Kleckner2015-06-181-38/+38
| | | | llvm-svn: 240047
* [X86] Refactor stack adjustments into X86FrameLowering::BuildStackAdjustmentReid Kleckner2015-06-181-99/+83
| | | | | | | | Deduplicates some code and lets us use LEA on atom when adjusting the stack around callee-cleanup calls. This is the only intended functionality change. llvm-svn: 240044
* [X86] Remove unneeded parameters and deduplicate stack alignment codeReid Kleckner2015-06-181-64/+51
| | | | | | NFC llvm-svn: 240033
* Re-land "[X86] Cache variables that only depend on the subtarget"Reid Kleckner2015-06-171-69/+24
| | | | | | Re-instates r239949 without accidentally flipping the sense of UseLEA. llvm-svn: 239950
* Revert "[X86] Cache variables that only depend on the subtarget"Reid Kleckner2015-06-171-24/+69
| | | | | | This reverts commit r239948, tests seem to be failing. llvm-svn: 239949
* [X86] Cache variables that only depend on the subtargetReid Kleckner2015-06-171-69/+24
| | | | | | | | | | | | | | There is a one-to-one relationship between X86Subtarget and X86FrameLowering, but every frame lowering method would previously pull the subtarget off the MachineFunction and query some subtarget properties. Over time, these locals began to grow in complexity and it became important to keep their names and meaning in sync across all of the frame lowering methods, leading to duplication. We can eliminate that duplication by computing them once in the constructor. llvm-svn: 239948
* [X86] Rename some frame lowering variablesReid Kleckner2015-06-161-26/+28
| | | | | | | | | | | | | | | | Old names, new names, and what they really mean: - IsWin64 -> IsWin64CC: This is true on non-Windows x86_64 platforms when the ms_abi calling convention is used. - IsWinEH -> IsWin64Prologue: True when the target is Win64, regardless of calling convention. Changes the prologue to obey the constraints of the Win64 unwinder. - NeedsWinEH -> NeedsWinCFI: We're using the win64 prologue *and* the we want .xdata unwind tables. Analogous to NeedsDwarfCFI. NFC llvm-svn: 239836
* [X86] Try to shorten dwarf CFI emissionReid Kleckner2015-06-151-28/+23
| | | | llvm-svn: 239786
* [X86] Implement the support for shrink-wrapping.Quentin Colombet2015-05-271-31/+56
| | | | | | | | | | | | | With this patch the x86 backend is now shrink-wrapping capable and this functionality can be tested by using the -enable-shrink-wrap switch. The next step is to make more test and enable shrink-wrapping by default for x86. Related to <rdar://problem/20821487> llvm-svn: 238293
* Reapply r238011 with a fix for the trap instruction.Quentin Colombet2015-05-221-109/+30
| | | | | | | | | | | | | | | | | | | The problem was that I slipped a change required for shrink-wrapping, namely I used getFirstTerminator instead of the getLastNonDebugInstr that was here before the refactoring, whereas the surrounding code is not yet patched for that. Original message: [X86] Refactor the prologue emission to prepare for shrink-wrapping. - Add a late pass to expand pseudo instructions (tail call and EH returns). Instead of doing it in the prologue emission. - Factor some static methods in X86FrameLowering to ease code sharing. NFC. Related to <rdar://problem/20821487> llvm-svn: 238035
* Revert "[X86] Fix a variable name for r237977 so that it works with every ↵Tamas Berghammer2015-05-221-31/+110
| | | | | | | | | | | compilers." Revert "[X86] Refactor the prologue emission to prepare for shrink-wrapping." This reverts commit 6b3b93fc8b68a2c806aa992ee4bd3d7f61898d4b. This reverts commit ab0b15dff8539826283a59c2dd700a18a9680e0f. llvm-svn: 238011
* [X86] Refactor the prologue emission to prepare for shrink-wrapping.Quentin Colombet2015-05-221-110/+31
| | | | | | | | | | | | - Add a late pass to expand pseudo instructions (tail call and EH returns). Instead of doing it in the prologue emission. - Factor some static methods in X86FrameLowering to ease code sharing. NFC. Related to <rdar://problem/20821487> llvm-svn: 237977
* MachineInstr: Change return value of getOpcode() to unsigned.Matthias Braun2015-05-181-1/+1
| | | | | | | | | This was previously returning int. However there are no negative opcode numbers and more importantly this was needlessly different from MCInstrDesc::getOpcode() (which even is the value returned here) and SDValue::getOpcode()/SDNode::getOpcode(). llvm-svn: 237611
* [ShrinkWrap] Add (a simplified version) of shrink-wrapping.Quentin Colombet2015-05-051-17/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces a new pass that computes the safe point to insert the prologue and epilogue of the function. The interest is to find safe points that are cheaper than the entry and exits blocks. As an example and to avoid regressions to be introduce, this patch also implements the required bits to enable the shrink-wrapping pass for AArch64. ** Context ** Currently we insert the prologue and epilogue of the method/function in the entry and exits blocks. Although this is correct, we can do a better job when those are not immediately required and insert them at less frequently executed places. The job of the shrink-wrapping pass is to identify such places. ** Motivating example ** Let us consider the following function that perform a call only in one branch of a if: define i32 @f(i32 %a, i32 %b) { %tmp = alloca i32, align 4 %tmp2 = icmp slt i32 %a, %b br i1 %tmp2, label %true, label %false true: store i32 %a, i32* %tmp, align 4 %tmp4 = call i32 @doSomething(i32 0, i32* %tmp) br label %false false: %tmp.0 = phi i32 [ %tmp4, %true ], [ %a, %0 ] ret i32 %tmp.0 } On AArch64 this code generates (removing the cfi directives to ease readabilities): _f: ; @f ; BB#0: stp x29, x30, [sp, #-16]! mov x29, sp sub sp, sp, #16 ; =16 cmp w0, w1 b.ge LBB0_2 ; BB#1: ; %true stur w0, [x29, #-4] sub x1, x29, #4 ; =4 mov w0, wzr bl _doSomething LBB0_2: ; %false mov sp, x29 ldp x29, x30, [sp], #16 ret With shrink-wrapping we could generate: _f: ; @f ; BB#0: cmp w0, w1 b.ge LBB0_2 ; BB#1: ; %true stp x29, x30, [sp, #-16]! mov x29, sp sub sp, sp, #16 ; =16 stur w0, [x29, #-4] sub x1, x29, #4 ; =4 mov w0, wzr bl _doSomething add sp, x29, #16 ; =16 ldp x29, x30, [sp], #16 LBB0_2: ; %false ret Therefore, we would pay the overhead of setting up/destroying the frame only if we actually do the call. ** Proposed Solution ** This patch introduces a new machine pass that perform the shrink-wrapping analysis (See the comments at the beginning of ShrinkWrap.cpp for more details). It then stores the safe save and restore point into the MachineFrameInfo attached to the MachineFunction. This information is then used by the PrologEpilogInserter (PEI) to place the related code at the right place. This pass runs right before the PEI. Unlike the original paper of Chow from PLDI’88, this implementation of shrink-wrapping does not use expensive data-flow analysis and does not need hack to properly avoid frequently executed point. Instead, it relies on dominance and loop properties. The pass is off by default and each target can opt-in by setting the EnableShrinkWrap boolean to true in their derived class of TargetPassConfig. This setting can also be overwritten on the command line by using -enable-shrink-wrap. Before you try out the pass for your target, make sure you properly fix your emitProlog/emitEpilog/adjustForXXX method to cope with basic blocks that are not necessarily the entry block. ** Design Decisions ** 1. ShrinkWrap is its own pass right now. It could frankly be merged into PEI but for debugging and clarity I thought it was best to have its own file. 2. Right now, we only support one save point and one restore point. At some point we can expand this to several save point and restore point, the impacted component would then be: - The pass itself: New algorithm needed. - MachineFrameInfo: Hold a list or set of Save/Restore point instead of one pointer. - PEI: Should loop over the save point and restore point. Anyhow, at least for this first iteration, I do not believe this is interesting to support the complex cases. We should revisit that when we motivating examples. Differential Revision: http://reviews.llvm.org/D9210 <rdar://problem/3201744> llvm-svn: 236507
* Target/X86: Never use the redzone for Win64 ABI functions.Charles Davis2015-02-271-1/+1
| | | | | | | | | | | | | | | | | Summary: Until now, we did this (among other things) based on whether or not the target was Windows. This is clearly wrong, not just for Win64 ABI functions on non-Windows, but for System V ABI functions on Windows, too. In this change, we make this decision based on the ABI the calling convention specifies instead. Reviewers: rnk Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7953 llvm-svn: 230793
* X86, Win64: Allow 'mov' to restore the stack pointer if we have a FPDavid Majnemer2015-02-251-13/+12
| | | | | | | | | | | | | | | | | | The Win64 epilogue structure is very restrictive, it permits a very small number of opcodes and none of them are 'mov'. This means that given: mov %rbp, %rsp pop %rbp The mov isn't the epilogue, only the pop is. This is problematic unless a frame pointer is present in which case we are free to do whatever we'd like in the "body" of the function. If a frame pointer is present, unwinding will undo the prologue operations in reverse order regardless of the fact that we are at an instruction which is reseting the stack pointer. llvm-svn: 230543
* X86: Only use 'lea' in Win64 epilogues if a frame pointer existsDavid Majnemer2015-02-241-7/+21
| | | | | | | We can only use 'add' in epilogues, 'lea' is not permitted unless we've established a frame pointer in the prologue. llvm-svn: 230286
* X86: Use a smaller 'mov' instruction for stack probe callsDavid Majnemer2015-02-231-3/+13
| | | | | | | | | | | | | Prologue emission, in some cases, requires calls to a stack probe helper function. The amount of stack to probe is passed as a register argument in the Win64 ABI but the instruction sequence used is pessimistic: it assumes that the number of bytes to probe is greater than 4 GB. Instead, select a more appropriate opcode depending on the number of bytes we are going to probe. llvm-svn: 230270
* X86: Use 'mov' instead of 'lea' in Win64 SEH prologues when possibleDavid Majnemer2015-02-231-2/+5
| | | | | | | 'mov' and 'lea' are equivalent when the displacement applied with 'lea' is zero. However, 'mov' should encode smaller. llvm-svn: 230269
* X86: Explain why we cannot use a 'mov' in a Win64 epilogueDavid Majnemer2015-02-231-0/+6
| | | | llvm-svn: 230268
* X86: Consistently use 'epilogue' instead of 'epilog'David Majnemer2015-02-231-1/+1
| | | | llvm-svn: 230267
* Win64: Stack alignment constraints aren't applied during SET_FPREGDavid Majnemer2015-02-211-36/+25
| | | | | | | | | | Stack realignment occurs after the prolog, not during, for Win64. Because of this, don't factor in the maximum stack alignment when establishing a frame pointer. This fixes PR22572. llvm-svn: 230113
* X86: Remove pre-2010 dead code in mergeSPUpdatesDownReid Kleckner2015-02-201-36/+0
| | | | llvm-svn: 230075
* X86: Canonicalize access to function attributes, NFCDuncan P. N. Exon Smith2015-02-141-7/+6
| | | | | | | | | | | | Canonicalize access to function attributes to use the simpler API. getAttributes().getAttribute(AttributeSet::FunctionIndex, Kind) => getFnAttribute(Kind) getAttributes().hasAttribute(AttributeSet::FunctionIndex, Kind) => hasFnAttribute(Kind) llvm-svn: 229214
* X86: Make @llvm.frameaddress work correctly with Windows unwind codesDavid Majnemer2015-02-101-0/+3
| | | | | | | | | Simply loading or storing the frame pointer is not sufficient for Windows targets. Instead, create a synthetic frame object that we will lower later. References to this synthetic object will be replaced with the correct reference to the frame address. llvm-svn: 228748
* X86: Emit Win64 SaveXMM opcodes at the right offset in the right orderDavid Majnemer2015-02-101-19/+18
| | | | | | | | | | | Walk the instructions marked FrameSetup and consider any stores of XMM registers to the stack as needing a SaveXMM opcode. This fixes PR22521. Differential Revision: http://reviews.llvm.org/D7527 llvm-svn: 228724
* X86: Emit an ABI compliant prologue and epilogue for Win64David Majnemer2015-02-101-79/+132
| | | | | | | | | | | | | | Win64 has specific contraints on what valid prologues and epilogues look like. This constraint is born from the flexibility and descriptiveness of Win64's unwind opcodes. Prologues previously emitted by LLVM could not be represented by the unwind opcodes, preventing operations powered by stack unwinding to successfully work. Differential Revision: http://reviews.llvm.org/D7520 llvm-svn: 228641
* Reuse a bunch of cached subtargets and remove getSubtarget callsEric Christopher2015-02-021-42/+37
| | | | | | without a Function argument. llvm-svn: 227814
* [X86] Convert esp-relative movs of function arguments to pushes, step 2Michael Kuperstein2015-02-011-125/+42
| | | | | | | | | | | | | | This moves the transformation introduced in r223757 into a separate MI pass. This allows it to cover many more cases (not only cases where there must be a reserved call frame), and perform rudimentary call folding. It still doesn't have a heuristic, so it is enabled only for optsize/minsize, with stack alignment <= 8, where it ought to be a fairly clear win. (Re-commit of r227728) Differential Revision: http://reviews.llvm.org/D6789 llvm-svn: 227752
* Revert r227728 due to bad line endings.Michael Kuperstein2015-02-011-2020/+2103
| | | | llvm-svn: 227746
* [X86] Convert esp-relative movs of function arguments to pushes, step 2Michael Kuperstein2015-02-011-2103/+2020
| | | | | | | | | | | | This moves the transformation introduced in r223757 into a separate MI pass. This allows it to cover many more cases (not only cases where there must be a reserved call frame), and perform rudimentary call folding. It still doesn't have a heuristic, so it is enabled only for optsize/minsize, with stack alignment <= 8, where it ought to be a fairly clear win. Differential Revision: http://reviews.llvm.org/D6789 llvm-svn: 227728
* Win64: Put a REX_W prefix on all TAILJMP* instructionsReid Kleckner2015-01-301-8/+12
| | | | | | | | | | | | | MSDN's x64 software conventions page says that this is one of the fixed list of legal epilogues: https://msdn.microsoft.com/en-us/library/tawsa7cb.aspx Presumably this is how the unwinder distinguishes epilogue jumps from in-function control flow. Also normalize the way we place "## TAILCALL" comments on such jumps. llvm-svn: 227611
* x86: Remove unused variables not caught by MSVC =PReid Kleckner2015-01-301-2/+0
| | | | llvm-svn: 227520
* x86: Fix large model calls to __chkstk for dynamic allocasReid Kleckner2015-01-291-40/+57
| | | | | | | | | | | | In the large code model, we now put __chkstk in %r11 before calling it. Refactor the code so that we only do this once. Simplify things by using __chkstk_ms instead of __chkstk on cygming. We already use that symbol in the prolog emission, and it simplifies our logic. Second half of PR18582. llvm-svn: 227519
* x86: Remove the W64ALLOCA pseudoReid Kleckner2015-01-291-1/+1
| | | | | | | | | This is just an alias for CALL64pcrel32, and we can just use that opcode with explicit defs in the MI. No functionality change. llvm-svn: 227508
* Update comments to use unreachable instead of llvm.trap, as implemented nowReid Kleckner2015-01-291-9/+26
| | | | | | | | | | | | | win64: Call __chkstk through a register with the large code model Fixes half of PR18582. True dynamic allocas will still have a CALL64pcrel32 which will fail. Reviewers: majnemer Differential Revision: http://reviews.llvm.org/D7267 llvm-svn: 227503
* [X86] Use single add/sub for large stack offsetsRobert Lougher2015-01-291-13/+46
| | | | | | | | | | | For large stack offsets the compiler generates multiple immediate mode sub/add instructions in the prologue/epilogue. This patch makes the compiler place the final amount to be added/subtracted into a register, which is then added/substracted with a single operation. Differential Revision: http://reviews.llvm.org/D7226 llvm-svn: 227458
* X86: Allow the stack probe size to be configurable per functionDavid Majnemer2015-01-071-3/+9
| | | | | | | | | | | | | | | | | | | LLVM emits stack probes on Windows targets to ensure that the stack is correctly accessed. However, the amount of stack allocated before emitting such a probe is hardcoded to 4096. It is desirable to have this be configurable so that a function might opt-out of stack probes. Our level of granularity is at the function level instead of, say, the module level to permit proper generation of code after LTO. Patch by Andrew H! N.B. The inliner needs to be updated to properly consider what happens after inlining a function with a specific stack-probe-size into another function with a different stack-probe-size. llvm-svn: 225360
OpenPOWER on IntegriCloud