summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/X86/X86RegisterInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Move most EH from MachineModuleInfo to MachineFunctionMatthias Braun2016-12-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Recommitting r288293 with some extra fixes for GlobalISel code. Most of the exception handling members in MachineModuleInfo is actually per function data (talks about the "current function") so it is better to keep it at the function instead of the module. This is a necessary step to have machine module passes work properly. Also: - Rename TidyLandingPads() to tidyLandingPads() - Use doxygen member groups instead of "//===- EH ---"... so it is clear where a group ends. - I had to add an ugly const_cast at two places in the AsmPrinter because the available MachineFunction pointers are const, but the code wants to call tidyLandingPads() in between (markFunctionEnd()/endFunction()). Differential Revision: https://reviews.llvm.org/D27227 llvm-svn: 288405
* Temporarily Revert "Move most EH from MachineModuleInfo to MachineFunction"Eric Christopher2016-12-011-1/+1
| | | | | | | | | This apprears to have broken the global isel bot: http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-globalisel_build/5174/console This reverts commit r288293. llvm-svn: 288322
* Move most EH from MachineModuleInfo to MachineFunctionMatthias Braun2016-11-301-1/+1
| | | | | | | | | | | | | | | | | | | | | Most of the exception handling members in MachineModuleInfo is actually per function data (talks about the "current function") so it is better to keep it at the function instead of the module. This is a necessary step to have machine module passes work properly. Also: - Rename TidyLandingPads() to tidyLandingPads() - Use doxygen member groups instead of "//===- EH ---"... so it is clear where a group ends. - I had to add an ugly const_cast at two places in the AsmPrinter because the available MachineFunction pointers are const, but the code wants to call tidyLandingPads() in between (markFunctionEnd()/endFunction()). Differential Revision: https://reviews.llvm.org/D27227 llvm-svn: 288293
* Clarify rules for reserved regs, fix aarch64 ones.Matthias Braun2016-11-301-0/+2
| | | | | | | | | No test case necessary as the problematic condition is checked with the newly introduced assertAllSuperRegsMarked() function. Differential Revision: https://reviews.llvm.org/D26648 llvm-svn: 288277
* X86: Move a non-null assert to before the pointer is dereferencedJustin Bogner2016-11-031-1/+2
| | | | llvm-svn: 285975
* [X86] Basic additions to support RegCall Calling Convention.Oren Ben Simhon2016-10-131-0/+26
| | | | | | | | | | The Register Calling Convention (RegCall) was introduced by Intel to optimize parameter transfer on function call. This calling convention ensures that as many values as possible are passed or returned in registers. This commit presents the basic additions to LLVM CodeGen in order to support RegCall in X86. Differential Revision: http://reviews.llvm.org/D25022 llvm-svn: 284108
* [AVX-512] Fix a bug in getLargestLegalSuperClass where we inflated to ↵Craig Topper2016-10-081-10/+9
| | | | | | | | VR128X/VR256X even when VLX isn't supported. This seems to have been responsible for the XMM16-31 spills observed in PR29112. With this fixed the test case has been modified to no longer have a spill of XMM16. llvm-svn: 283668
* [X86] Preserve BasePtr for LEA64_32rMichael Kuperstein2016-10-061-3/+5
| | | | | | | | | | | | When replacing FrameIndex with BasePtr, we must preserve BasePtr for LEA64_32r since BasePtr is used later for stack adjustment if it is the same as StackPtr. Patch by H.J Lu <hjl.tools@gmail.com> Differential Revision: https://reviews.llvm.org/D23575 llvm-svn: 283486
* [X86] Don't preserve Win64 SSE CSRs when SSE is disabledReid Kleckner2016-09-301-1/+6
| | | | | | | | | Code that doesn't use floating point and doesn't use SSE (kernel code) shouldn't save and restore SSE registers. Fixes PR30503 llvm-svn: 282819
* [X86] Optimization for replacing LEA with MOV at frame index elimination timeZvi Rackover2016-09-261-1/+31
| | | | | | | | | | | | | | | Summary: Replace a LEA instruction of the form 'lea (%esp), %ebx' --> 'mov %esp, %ebx' MOV is preferable over LEA because usually there are more issue-slots available to execute MOVs than LEAs. Latest processors also support zero-latency MOVs. Fixes pr29022. Reviewers: hfinkel, delena, igorb, myatsina, mkuper Differential Revision: https://reviews.llvm.org/D24705 llvm-svn: 282385
* [AVX-512] Replace get512BitSuperRegister with calls to ↵Craig Topper2016-09-251-10/+0
| | | | | | TargetRegisterInfo::getMatchingSuperReg. llvm-svn: 282359
* [AVX-512] Teach X86InstrInfo::copyPhysReg to use a 512-bit move if ↵Craig Topper2016-09-201-0/+10
| | | | | | | | XMM16-XMM31 or YMM16-YMM31 are the source or dest of the copy and VLX is not supported. This can happen with SUBREG_TO_REG of ZMM16-ZMM31. Fixes PR30430. llvm-svn: 281959
* [AVX-512] Simplify X86InstrInfo::copyPhysReg for 128/256-bit vectors with ↵Craig Topper2016-09-051-10/+0
| | | | | | | | AVX512, but not VLX. We should use the VEX opcodes and trust the register allocator to not use the extended XMM/YMM register space. Previously we were extending to copying the whole ZMM register. The register allocator shouldn't use XMM16-31 or YMM16-31 in this configuration as the instructions to spill them aren't available. llvm-svn: 280648
* Replace "fallthrough" comments with LLVM_FALLTHROUGHJustin Bogner2016-08-171-2/+3
| | | | | | | This is a mechanical change of comments in switches like fallthrough, fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead. llvm-svn: 278902
* [AVX-512] Teach X86InstrInfo::getLargestLegalSuperClass to inflate to ↵Craig Topper2016-08-011-4/+26
| | | | | | | | FR32X/FR64X if AVX512 is supported and VR128X/VR256X if VLX is supported. Had to update a stack folding test to clobber the other 16 registers since this now made them get used instead of spilling. llvm-svn: 277321
* [AVX512] Add X86::VR512RegClassID to X86RegisterInfo::getLargestLegalSuperClass.Craig Topper2016-07-311-0/+1
| | | | llvm-svn: 277301
* MachineFunction: Return reference for getFrameInfo(); NFCMatthias Braun2016-07-281-6/+6
| | | | | | | getFrameInfo() never returns nullptr so we should use a reference instead of a pointer. llvm-svn: 277017
* Fixed the callee saved registers list for X86 AllRegs calling convention.Amjad Aboud2016-05-121-8/+13
| | | | | | | | | | | | | | | | 32-bit AllRegs: SSE: xmm0-xmm7 AVX: ymm0-ymm7 AVX512: zmm0-zmm7 + k0-k7 64-bit AllRegs: SSE: xmm0-xmm15 AVX: ymm0-ymm15 AVX512: zmm0-zmm31 + k0-k7 Differential Revision: http://reviews.llvm.org/D20142 llvm-svn: 269337
* [X86] Add ZMM registers to the X86_INTR calling convention preserved mask ↵Craig Topper2016-05-101-0/+2
| | | | | | when AVX512 is enabled. llvm-svn: 269018
* [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
OpenPOWER on IntegriCloud