summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/X86/X86RegisterInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [X86][AVX512] Use the proper load/store for AVX512 registers.Quentin Colombet2016-05-101-2/+3
| | | | | | | | | | | | | | When loading or storing AVX512 registers we were not using the AVX512 variant of the load and store for VR128 and VR256 like registers. Thus, we ended up with the wrong encoding and actually were dropping the high bits of the instruction. The result was that we load or store the wrong register. The effect is visible only when we emit the object file directly and disassemble it. Then, the output of the disassembler does not match the assembly input. This is related to llvm.org/PR27481. llvm-svn: 269001
* Reapply [X86] Add a new LOW32_ADDR_ACCESS_RBP register class.Quentin Colombet2016-05-091-1/+9
| | | | | | | | | | | | | | | This reapplies commit r268796, with a fix for the setting of the inline asm constraints. I.e., "mark" LOW32_ADDR_ACCESS_RBP as a GR variant, so that the regular processing of the GR operands (setting of the subregisters) happens. Original commit log: [X86] Add a new LOW32_ADDR_ACCESS_RBP register class. ABIs like NaCl uses 32-bit addresses but have 64-bit frame. The new register class reflects those constraints when choosing a register class for a address access. llvm-svn: 268955
* Revert "[X86] Add a new LOW32_ADDR_ACCESS_RBP register class."Quentin Colombet2016-05-061-9/+1
| | | | | | | | This reverts commit r268796. I believe it breaks test/CodeGen/X86/asm-mismatched-types.ll with: Cannot emit physreg copy instruction llvm-svn: 268799
* [X86] Add a new LOW32_ADDR_ACCESS_RBP register class.Quentin Colombet2016-05-061-1/+9
| | | | | | | | ABIs like NaCl uses 32-bit addresses but have 64-bit frame. The new register class reflects those constraints when choosing a register class for a address access. llvm-svn: 268796
* [X86] Rename the X32_ADDR_ACCESS register class into LOW32_ADDR_ACCESS.Quentin Colombet2016-05-061-2/+3
| | | | | | | | This register class may be used by any ABIs that uses x86_64 ISA while using 32-bit addresses, not just in X32 cases. Make sure the name reflects that. llvm-svn: 268795
* [X86] Get rid of X32_NOREX_ADDR_ACCESS register class.Quentin Colombet2016-05-061-2/+1
| | | | | | | According to H.J. Lu <hjl.tools@gmail.com>, this register class is never used. llvm-svn: 268771
* [X86] Add a few register classes for x32 address accesses.Quentin Colombet2016-05-041-2/+8
| | | | | | | | | | | | The new register classes allow to tell the machine verifier that it is fine to use RIP for address accesses in x32 mode. Prior to that patch, we would complain that we are using a GR64 in place of GR32, whereas it is actually fine to use GR64 for x32 as long as the 32 high bits are 0s. RIP has this property and is used for RIP-relative addressing. This partially fixes http://llvm.org/PR27481. llvm-svn: 268567
* Swift Calling Convention: swifterror target support.Manman Ren2016-04-111-0/+8
| | | | | | Differential Revision: http://reviews.llvm.org/D18716 llvm-svn: 265997
* [codeview] Describe int local variables using .cv_def_rangeReid Kleckner2016-02-101-1/+1
| | | | | | | | | | | | | | | | Summary: Refactor common value, scope, and label tracking logic out of DwarfDebug into a common base class called DebugHandlerBase. Update an old LLVM IR test case to avoid an assertion in LexicalScopes. Reviewers: dblaikie, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16931 llvm-svn: 260432
* CXX_FAST_TLS calling convention: performance improvement for x86-64.Manman Ren2016-01-121-1/+11
| | | | | | | This is the same change on x86-64 as r255821 on AArch64. rdar://9001553 llvm-svn: 257428
* [X86] Move getX86SubSuperRegisterOrZero to X86MCTargetDesc.cpp so it can be ↵Craig Topper2015-12-251-182/+1
| | | | | | used by AsmParser library without depending on X86CodeGen library. llvm-svn: 256428
* [X86] Replace MVT::SimpleValueType in the AsmParser library and ↵Craig Topper2015-12-251-15/+12
| | | | | | | | getX86SubSuperRegister with just an unsigned representing size. This a is step towards fixing a layering violation so the X86 AsmParser won't depending on CodeGen types. llvm-svn: 256425
* [X86] Don't pass the default value to the High argument of ↵Craig Topper2015-12-251-4/+3
| | | | | | getX86SubSuperRegister. Most place don't care about this argument. NFC llvm-svn: 256424
* [X86] getX86SubSuperRegisterOrZero shouldn't call getX86SubSuperRegister ↵Craig Topper2015-12-251-1/+1
| | | | | | recursively. It should call itself instead. Otherwise it might fire an assertion when it was designed not too. llvm-svn: 256422
* [X86] Use assert instead of if and llvm_unreachable. NFCCraig Topper2015-12-251-2/+1
| | | | llvm-svn: 256420
* Implemented Support of IA interrupt and exception handlers:Amjad Aboud2015-12-211-2/+28
| | | | | | | | http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html Differential Revision: http://reviews.llvm.org/D15567 llvm-svn: 256155
* [CXX TLS calling convention] Add CXX TLS calling convention.Manman Ren2015-12-041-0/+8
| | | | | | | | | | | | | | | | | | | | | This commit adds a new target-independent calling convention for C++ TLS access functions. It aims to minimize overhead in the caller by perserving as many registers as possible. 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) The callee preserves all GPRs - except RAX and RDI The access function makes C-style TLS function calls in the entry and exit block, C-style TLS functions save a lot more registers than normal calls. The added calling convention ties into the existing implementation of the C-style TLS functions, so we can't simply use existing calling conventions such as preserve_mostcc. rdar://9001553 llvm-svn: 254737
* findDeadCallerSavedReg needs to pay attention to calling conventionAndy Ayers2015-11-231-10/+15
| | | | | | | | | | Caller saved regs differ between SysV and Win64. Use the tail call available set to scavenge from. Refactor register info to create new helper to get at tail call GPRs. Added a new test case for windows. Fixed up a number of X64 tests since now RCX is preferred over RDX on SysV. Differential Revision: http://reviews.llvm.org/D14878 llvm-svn: 253927
* [TLS on Darwin] use a different mask for tls calls on x86-64.Manman Ren2015-11-121-0/+4
| | | | | | | | | Calls involved in thread-local variable lookup save more registers than normal calls. rdar://problem/23073171 llvm-svn: 252837
* Make Win64 localescape offsets FP relative instead of SP relativeReid Kleckner2015-10-121-8/+2
| | | | | | | | | We made them SP relative back in March (r233137) because that's the value the runtime passes to EH functions. With the new cleanuppad IR, funclets adjust their frame argument from SP to FP, so our offsets should now be FP-relative. llvm-svn: 250088
* HHVM calling conventions.Maksim Panchenko2015-09-291-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | HHVM calling convention, hhvmcc, is used by HHVM JIT for functions in translated cache. We currently support LLVM back end to generate code for X86-64 and may support other architectures in the future. In HHVM calling convention any GP register could be used to pass and return values, with the exception of R12 which is reserved for thread-local area and is callee-saved. Other than R12, we always pass RBX and RBP as args, which are our virtual machine's stack pointer and frame pointer respectively. When we enter translation cache via hhvmcc function, we expect the stack to be aligned at 16 bytes, i.e. skewed by 8 bytes as opposed to standard ABI alignment. This affects stack object alignment and stack adjustments for function calls. One extra calling convention, hhvm_ccc, is used to call C++ helpers from HHVM's translation cache. It is almost identical to standard C calling convention with an exception of first argument which is passed in RBP (before we use RDI, RSI, etc.) Differential Revision: http://reviews.llvm.org/D12681 llvm-svn: 248832
* Revert r247692: Replace Triple with a new TargetTuple in MCTargetDesc/* and ↵Daniel Sanders2015-09-151-2/+2
| | | | | | | | related. NFC. Eric has replied and has demanded the patch be reverted. llvm-svn: 247702
* Re-commit r247683: Replace Triple with a new TargetTuple in MCTargetDesc/* ↵Daniel Sanders2015-09-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | and related. NFC. Summary: This is the first patch in the series to migrate Triple's (which are ambiguous) to TargetTuple's (which aren't). For the moment, TargetTuple simply passes all requests to the Triple object it holds. Once it has replaced Triple, it will start to implement the interface in a more suitable way. This change makes some changes to the public C++ API. In particular, InitMCSubtargetInfo(), createMCRelocationInfo(), and createMCSymbolizer() now take TargetTuples instead of Triples. The other public C++ API's have been left as-is for the moment to reduce patch size. This commit also contains a trivial patch to clang to account for the C++ API change. Thanks go to Pavel Labath for fixing LLDB for me. Reviewers: rengolin Subscribers: jyknight, dschuff, arsenm, rampitec, danalbert, srhines, javed.absar, dsanders, echristo, emaste, jholewinski, tberghammer, ted, jfb, llvm-commits, rengolin Differential Revision: http://reviews.llvm.org/D10969 llvm-svn: 247692
* Revert r247684 - Replace Triple with a new TargetTuple ...Daniel Sanders2015-09-151-2/+2
| | | | | | LLDB needs to be updated in the same commit. llvm-svn: 247686
* Replace Triple with a new TargetTuple in MCTargetDesc/* and related. NFC.Daniel Sanders2015-09-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the first patch in the series to migrate Triple's (which are ambiguous) to TargetTuple's (which aren't). For the moment, TargetTuple simply passes all requests to the Triple object it holds. Once it has replaced Triple, it will start to implement the interface in a more suitable way. This change makes some changes to the public C++ API. In particular, InitMCSubtargetInfo(), createMCRelocationInfo(), and createMCSymbolizer() now take TargetTuples instead of Triples. The other public C++ API's have been left as-is for the moment to reduce patch size. This commit also contains a trivial patch to clang to account for the C++ API change. Reviewers: rengolin Subscribers: jyknight, dschuff, arsenm, rampitec, danalbert, srhines, javed.absar, dsanders, echristo, emaste, jholewinski, tberghammer, ted, jfb, llvm-commits, rengolin Differential Revision: http://reviews.llvm.org/D10969 llvm-svn: 247683
* x32. Fixes a bug in i8mem_NOREX declaration.Derek Schuff2015-09-081-1/+9
| | | | | | | | | | | | | | The old implementation assumed LP64 which is broken for x32. Specifically, the MOVE8rm_NOREX and MOVE8mr_NOREX, when selected, would cause a 'Cannot emit physreg copy instruction' error message to be reported. This patch also enable the h-register*ll tests for x32. Differential Revision: http://reviews.llvm.org/D12336 Patch by João Porto llvm-svn: 247058
* Remove redundant TargetFrameLowering::getFrameIndexOffset virtualJames Y Knight2015-08-151-3/+7
| | | | | | | | | | | function. This was the same as getFrameIndexReference, but without the FrameReg output. Differential Revision: http://reviews.llvm.org/D12042 llvm-svn: 245148
* x86: check hasOpaqueSPAdjustment in canRealignStackJF Bastien2015-07-311-4/+6
| | | | | | | | | | | | | | | Summary: @rnk pointed out in [1] that x86's canRealignStack logic should match that in CantUseSP from hasBasePointer. [1]: http://reviews.llvm.org/D11160?id=29713#inline-89350 Reviewers: rnk Subscribers: rnk, llvm-commits Differential Revision: http://reviews.llvm.org/D11377 llvm-svn: 243772
* 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
OpenPOWER on IntegriCloud