summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/X86/X86RegisterInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Targets: commonize some stack realignment codeJF Bastien2015-07-201-22/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Target RegisterInfo: devirtualize TargetFrameLoweringJF Bastien2015-07-101-8/+7
| | | | | | | | | | | | | Summary: The target frame lowering's concrete type is always known in RegisterInfo, yet it's only sometimes devirtualized through a static_cast. This change adds an auto-generated static function <Target>GenRegisterInfo::getFrameLowering(const MachineFunction &MF) which does this devirtualization, and uses this function in all targets which can. This change was suggested by sunfish in D11070 for WebAssembly, I figure that I may as well improve the other targets while I'm here. Subscribers: sunfish, ted, llvm-commits, jfb Differential Revision: http://reviews.llvm.org/D11093 llvm-svn: 241921
* [WinEH] Make llvm.x86.seh.restoreframe work for stack realignment prologuesReid Kleckner2015-07-071-1/+1
| | | | | | | | | | 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
* Rename llvm.frameescape and llvm.framerecover to localescape and localrecoverReid Kleckner2015-07-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Initially, these intrinsics seemed like part of a family of "frame" related intrinsics, but now I think that's more confusing than helpful. Initially, the LangRef specified that this would create a new kind of allocation that would be allocated at a fixed offset from the frame pointer (EBP/RBP). We ended up dropping that design, and leaving the stack frame layout alone. These intrinsics are really about sharing local stack allocations, not frame pointers. I intend to go further and add an `llvm.localaddress()` intrinsic that returns whatever register (EBP, ESI, ESP, RBX) is being used to address locals, which should not be confused with the frame pointer. Naming suggestions at this point are welcome, I'm happy to re-run sed. Reviewers: majnemer, nicholas Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11011 llvm-svn: 241633
* X86: Rework inline asm integer register specification.Matthias Braun2015-06-291-7/+15
| | | | | | | | | | | | | | | | | | | | | | | This is a new version of http://reviews.llvm.org/D10260. It turned out that when you specify an integer register in inline asm on x86 you get the register of the required type size back. That means that X86TargetLowering::getRegForInlineAsmConstraint() has to accept any of the integer registers and adapt its size to the given target size which may be any 8/16/32/64 bit sized type. Surprisingly that means given a constraint of "{ax}" and a type of MVT::F32 we need to return X86::EAX. This change makes this face explicit, the previous code seemed like working by accident because there it never returned an error once a register was found. On the other hand this rewrite allows to actually return errors for invalid situations like requesting an integer register for an i128 type. Related to rdar://21042280 Differential Revision: http://reviews.llvm.org/D10813 llvm-svn: 241002
* Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)Alexander Kornienko2015-06-231-1/+1
| | | | | | Apparently, the style needs to be agreed upon first. llvm-svn: 240390
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-191-1/+1
| | | | | | | | | | | | | The patch is generated using this command: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ llvm/lib/ Thanks to Eugene Kosov for the original patch! llvm-svn: 240137
* [Stackmaps][X86] Remove EFLAGS and IP registers from the live-out mask.Juergen Ributzka2015-06-111-0/+16
| | | | | | | | | | | | | Remove the EFLAGS from the stackmap live-out mask. The EFLAGS register is not supposed to be part of that set, because the X86 calling conventions mark the register as NOT preserved. Also remove the IP registers, since spilling and restoring those doesn't really make any sense. Related to rdar://problem/21019635. llvm-svn: 239568
* [Target/X86] Don't use callee-saved registers in a Win64 tail call on ↵Charles Davis2015-06-041-2/+2
| | | | | | | | | | | | | | | | | | | | | | non-Windows. Summary: A small bit that I missed when I updated the X86 backend to account for the Win64 calling convention on non-Windows. Now we don't use dead non-volatile registers when emitting a Win64 indirect tail call on non-Windows. Should fix PR23710. Test Plan: Added test for the correct behavior based on the case I posted to PR23710. Reviewers: rnk Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10258 llvm-svn: 239111
* Reapply r238011 with a fix for the trap instruction.Quentin Colombet2015-05-221-1/+2
| | | | | | | | | | | | | | | | | | | 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-2/+1
| | | | | | | | | | | 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-1/+2
| | | | | | | | | | | | - 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
* X86: Fix frameescape when not using an FPReid Kleckner2015-03-241-5/+5
| | | | | | | | | | | We can't use TargetFrameLowering::getFrameIndexOffset directly, because Win64 really wants the offset from the stack pointer at the end of the prologue. Instead, use X86FrameLowering::getFrameIndexOffsetFromSP(), which is a pretty close approximiation of that. It fails to handle cases with interestingly large stack alignments, which is pretty uncommon on Win64 and is TODO. llvm-svn: 233137
* Remove the need to cache the subtarget in the X86 TargetRegisterInfoEric Christopher2015-03-121-17/+21
| | | | | | | classes. Use a Triple instead and simplify a lot of the querying logic to use lookups on the Triple. llvm-svn: 232071
* Have getCallPreservedMask and getThisCallPreservedMask take aEric Christopher2015-03-111-3/+4
| | | | | | | MachineFunction argument so that we can grab subtarget specific features off of it. llvm-svn: 231979
* Have TargetRegisterInfo::getLargestLegalSuperClass take aEric Christopher2015-03-101-2/+3
| | | | | | | MachineFunction argument so that it can look up the subtarget rather than using a cached one in some Targets. llvm-svn: 231888
* Replace llvm.frameallocate with llvm.frameescapeReid Kleckner2015-03-051-0/+19
| | | | | | | | | | Turns out it's pretty straightforward and simplifies the implementation. Reviewers: andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D8051 llvm-svn: 231386
* Target/X86: Save Win64 non-volatile registers in a Win64 ABI function.Charles Davis2015-02-271-1/+11
| | | | | | | | | | | | | | Summary: This change causes us to actually save non-volatile registers in a Win64 ABI function that calls a System V ABI function, and vice-versa. Reviewers: rnk Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7919 llvm-svn: 230714
* [x32] Mark RBX as reserved when EBX is the base pointer.Michael Kuperstein2015-02-241-1/+3
| | | | | | This should have gone into r230334. llvm-svn: 230339
* [x32] x32 should use ebx as the base pointer.Michael Kuperstein2015-02-241-8/+9
| | | | | | This fixes the original issue in PR22655, but not the secondary one. llvm-svn: 230334
* X86: Canonicalize access to function attributes, NFCDuncan P. N. Exon Smith2015-02-141-4/+2
| | | | | | | | | | | | 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] Convert esp-relative movs of function arguments to pushes, step 2Michael Kuperstein2015-02-011-2/+3
| | | | | | | | | | | | | | 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-3/+2
| | | | llvm-svn: 227746
* [X86] Convert esp-relative movs of function arguments to pushes, step 2Michael Kuperstein2015-02-011-2/+3
| | | | | | | | | | | | 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
* Use 32-bit ebp for NaCl64 in a limited case: llvm.frameaddress.Jan Wen Voung2014-12-051-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Follow up to [x32] "Use ebp/esp as frame and stack pointer": http://reviews.llvm.org/D4617 In that earlier patch, NaCl64 was made to always use rbp. That's needed for most cases because rbp should hold a full 64-bit address within the NaCl sandbox so that load/stores off of rbp don't require sandbox adjustment (zeroing the top 32-bits, then filling those by adding r15). However, llvm.frameaddress returns a pointer and pointers are 32-bit for NaCl64. In this case, use ebp instead, which will make the register copy type check. A similar mechanism may be needed for llvm.eh.return, but is not added in this change. Test Plan: test/CodeGen/X86/frameaddr.ll Reviewers: dschuff, nadav Subscribers: jfb, llvm-commits Differential Revision: http://reviews.llvm.org/D6514 llvm-svn: 223510
* Fix a typo in a comment.Craig Topper2014-11-201-1/+1
| | | | llvm-svn: 222412
* Remove unnecessary getTarget call now that the subtarget is cachedEric Christopher2014-09-031-4/+2
| | | | | | on the machine function. llvm-svn: 217070
* [x32] Fix FrameIndex check in SelectLEA64_32AddrPavel Chupin2014-08-201-0/+6
| | | | | | | | | | | | | | | | | | Summary: Fixes http://llvm.org/bugs/show_bug.cgi?id=20016 reproducible on new lea-5.ll case. Also use RSP/RBP for x32 lea to save 1 byte used for 0x67 prefix in ESP/EBP case. Test Plan: lea tests modified to include x32/nacl and new test added Reviewers: nadav, dschuff, t.p.northover Subscribers: llvm-commits, zinovy.nis Differential Revision: http://reviews.llvm.org/D4929 llvm-svn: 216065
* [x32] Use ebp/esp as frame and stack pointerPavel Chupin2014-08-071-9/+7
| | | | | | | | | | | | | | | | | | | | | | | Summary: Since pointers are 32-bit on x32 we can use ebp and esp as frame and stack pointer. Some operations like PUSH/POP and CFI_INSTRUCTION still require 64-bit register, so using 64-bit MachineFramePtr where required. X86_64 NaCl uses 64-bit frame/stack pointers, however it's been found that both isTarget64BitLP64 and isTarget64BitILP32 are true for NaCl. Addressing this issue here as well by making isTarget64BitLP64 false. Also mark hasReservedSpillSlot unreachable on X86. See inlined comments. Test Plan: Add one new simple test and upgrade 2 existing with x32 target case. Reviewers: nadav, dschuff Subscribers: llvm-commits, zinovy.nis Differential Revision: http://reviews.llvm.org/D4617 llvm-svn: 215091
* Have MachineFunction cache a pointer to the subtarget to make lookupsEric Christopher2014-08-051-10/+5
| | | | | | | | | | | shorter/easier and have the DAG use that to do the same lookup. This can be used in the future for TargetMachine based caching lookups from the MachineFunction easily. Update the MIPS subtarget switching machinery to update this pointer at the same time it runs. llvm-svn: 214838
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-041-6/+14
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* TargetRegisterInfo: Remove function that fell out of use years ago.Benjamin Kramer2014-07-091-15/+0
| | | | llvm-svn: 212636
* Move X86RegisterInfo away from using the TargetMachine and onlyEric Christopher2014-06-101-21/+18
| | | | | | using the subtarget. llvm-svn: 210595
* [C++] Use 'nullptr'. Target edition.Craig Topper2014-04-251-1/+1
| | | | llvm-svn: 207197
* [cleanup] Lift using directives, DEBUG_TYPE definitions, and even someChandler Carruth2014-04-221-2/+2
| | | | | | | | | | | | system headers above the includes of generated '.inc' files that actually contain code. In a few targets this was already done pretty consistently, but it wasn't done *really* consistently anywhere. It is strictly cleaner IMO and necessary in a bunch of places where the DEBUG_TYPE is referenced from the generated code. Consistency with the necessary places trumps. Hopefully the build bots are OK with the movement of intrin.h... llvm-svn: 206838
* Make consistent use of MCPhysReg instead of uint16_t throughout the tree.Craig Topper2014-04-041-1/+1
| | | | llvm-svn: 205610
* Prune includes in X86 target.Craig Topper2014-03-191-1/+0
| | | | llvm-svn: 204216
* Replace ValueTypes.h with MachineValueType.h if possible.Patrik Hagglund2014-03-151-1/+1
| | | | | | | | | Utilize the previous move of MVT to a separate header for all trivial cases (that don't need any further restructuring). Reviewed By: Tim Northover llvm-svn: 204003
* x86: Add missing break to getCallPreservedMask()Duncan P. N. Exon Smith2014-03-141-0/+1
| | | | | | | | | | | | This change brings getCallPreservedMask()'s logic in line with getCalleeSavedRegs(). While this changes the control flow slightly, the change is not currently observable. is64Bit must be false to get to the accidental fallthrough, but the case that we fall into (coldcc) does nothing unless is64Bit is true. llvm-svn: 203943
* x86: NFC: Make getCallPreservedMask() more similar to getCalleeSavedRegs()Duncan P. N. Exon Smith2014-03-141-4/+6
| | | | | | | Changing order of checks in getCallPreservedMask() to match getCalleeSavedRegs() so that the logic is easier to compare. llvm-svn: 203939
* x86: getCalleeSavedRegs() would crash on 0 (so don't default to it)Duncan P. N. Exon Smith2014-03-141-0/+1
| | | | | | | The current logic assumes that MF is not 0. Assert that it isn't, and remove the default of 0 from the header. llvm-svn: 203934
* [Stackmaps] Move the target-independent frame index elimination for ↵Juergen Ributzka2014-02-211-0/+9
| | | | | | | | | | | | stackmaps and patchpoints into target-specific code. The lowering of the frame index for stackmaps and patchpoints requires some target-specific magic and should therefore be handled in the target-specific eliminateFrameIndex method. This is related to <rdar://problem/16106219> llvm-svn: 201904
* Add two new calling conventions for runtime callsJuergen Ributzka2014-01-171-0/+12
| | | | | | | | | | | | | | This patch adds two new target-independent calling conventions for runtime calls - PreserveMost and PreserveAll. The target-specific implementation for X86-64 is defined as following: - Arguments are passed as for the default C calling convention - The same applies for the return value(s) - PreserveMost preserves all GPRs - except R11 - PreserveAll preserves all GPRs and all XMMs/YMMs - except R11 Reviewed by Lang and Philip llvm-svn: 199508
* [anyregcc] Fix callee-save mask for anyregccJuergen Ributzka2014-01-111-20/+30
| | | | | | | Use separate callee-save masks for XMM and YMM registers for anyregcc on X86 and select the proper mask depending on the target cpu we compile for. llvm-svn: 198985
* [Stackmap] Only the AnyReg calling convention should preserve all registers.Juergen Ributzka2013-12-141-5/+3
| | | | llvm-svn: 197316
* Revert the backend fatal error from r196939Reid Kleckner2013-12-101-6/+0
| | | | | | | | | | | | | | The combination of inline asm, stack realignment, and dynamic allocas turns out to be too common to reject out of hand. ASan inserts empy inline asm fragments and uses aligned allocas. Compiling any trivial function containing a dynamic alloca with ASan is enough to trigger the check. XFAIL the test cases that would be miscompiled and add one that uses the relevant functionality. llvm-svn: 196986
* Reland "Fix miscompile of MS inline assembly with stack realignment"Reid Kleckner2013-12-101-12/+15
| | | | | | | | | | | This re-lands commit r196876, which was reverted in r196879. The tests have been fixed to pass on platforms with a stack alignment larger than 4. Update to clang side tests will land shortly. llvm-svn: 196939
* Revert "Fix miscompile of MS inline assembly with stack realignment"Reid Kleckner2013-12-101-15/+12
| | | | | | | This reverts commit r196876. Its tests failed on the bots, so I'll figure it out tomorrow. llvm-svn: 196879
* Fix miscompile of MS inline assembly with stack realignmentReid Kleckner2013-12-101-12/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | For stack frames requiring realignment, three pointers may be needed: - ebp to address incoming arguments - esi (could be any callee-saved register) to address locals - esp to address outgoing arguments We would use esi unconditionally without verifying that it did not conflict with inline assembly. This change doesn't do the verification, it simply emits a fatal error on functions that use stack realignment, dynamic SP adjustments, and inline assembly. Because stack realignment is common on Windows, we also no longer assume that MS inline assembly clobbers esp. Instead, we analyze the inline instructions for implicit definitions and check if esp is there. If so, we require the use of a base pointer and consider it in the condition above. Mostly fixes PR16830, but we could try harder to find a non-conflicting base pointer. Reviewers: sunfish Differential Revision: http://llvm-reviews.chandlerc.com/D1317 llvm-svn: 196876
* The WebKit_JS CC preserves the same registers as the C CC.Juergen Ributzka2013-11-161-0/+1
| | | | llvm-svn: 194936
OpenPOWER on IntegriCloud