summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/X86/X86MCInstLower.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [X86] Optimize stackmap shadows on X86.Lang Hames2014-07-241-44/+88
| | | | | | | | | | | | | | | | | | | This patch minimizes the number of nops that must be emitted on X86 to satisfy stackmap shadow constraints. To minimize the number of nops inserted, the X86AsmPrinter now records the size of the most recent stackmap's shadow in the StackMapShadowTracker class, and tracks the number of instruction bytes emitted since the that stackmap instruction was encountered. Padding is emitted (if it is required at all) immediately before the next stackmap/patchpoint instruction, or at the end of the basic block. This optimization should reduce code-size and improve performance for people using the llvm stackmap intrinsic on X86. <rdar://problem/14959522> llvm-svn: 213892
* MC: rename EmitWin64EH routinesSaleem Abdulrasool2014-06-291-12/+10
| | | | | | | | | | | | | | | Rename the routines to reflect the reality that they are more related to call frame information than to Win64 EH. Although EH is implemented in an intertwined manner by augmenting with an exception handler and an associated parameter, the majority of these routines emit information required to unwind the frames. This also helps identify that these routines are generic for most windows platforms (they apply equally to nearly all architectures except x86) although the encoding of the information is architecture dependent. Unwinding data is emitted via EmitWinCFI* and exception handling information via EmitWinEH*. llvm-svn: 211994
* Re-apply r211399, "Generate native unwind info on Win64" with a fix to ↵NAKAMURA Takumi2014-06-251-0/+37
| | | | | | | | | | | | | | | | | | | | | | | ignore SEH pseudo ops in X86 JIT emitter. -- This patch enables LLVM to emit Win64-native unwind info rather than DWARF CFI. It handles all corner cases (I hope), including stack realignment. Because the unwind info is not flexible enough to describe stack frames with a gap of unknown size in the middle, such as the one caused by stack realignment, I modified register spilling code to place all spills into the fixed frame slots, so that they can be accessed relative to the frame pointer. Patch by Vadim Chugunov! Reviewed By: rnk Differential Revision: http://reviews.llvm.org/D4081 llvm-svn: 211691
* Revert r211399, "Generate native unwind info on Win64"NAKAMURA Takumi2014-06-221-37/+0
| | | | | | It broke Legacy JIT Tests on x86_64-{mingw32|msvc}, aka Windows x64. llvm-svn: 211480
* Generate native unwind info on Win64Reid Kleckner2014-06-201-0/+37
| | | | | | | | | | | | | | | | | | | | This patch enables LLVM to emit Win64-native unwind info rather than DWARF CFI. It handles all corner cases (I hope), including stack realignment. Because the unwind info is not flexible enough to describe stack frames with a gap of unknown size in the middle, such as the one caused by stack realignment, I modified register spilling code to place all spills into the fixed frame slots, so that they can be accessed relative to the frame pointer. Patch by Vadim Chugunov! Reviewed By: rnk Differential Revision: http://reviews.llvm.org/D4081 llvm-svn: 211399
* [C++] Use 'nullptr'. Target edition.Craig Topper2014-04-251-4/+4
| | | | llvm-svn: 207197
* Prune includes in X86 target.Craig Topper2014-03-191-3/+4
| | | | llvm-svn: 204216
* X86: Use enums for memory operand decoding instead of integer literals.Manuel Jacob2014-03-181-10/+10
| | | | | | | | | | | | | | | | Summary: X86BaseInfo.h defines an enum for the offset of each operand in a memory operand sequence. Some code uses it and some does not. This patch replaces (hopefully) all remaining locations where an integer literal was used instead of this enum. No functionality change intended. Reviewers: nadav CC: llvm-commits, t.p.northover Differential Revision: http://llvm-reviews.chandlerc.com/D3108 llvm-svn: 204158
* Add back r201608, r201622, r201624 and r201625Rafael Espindola2014-02-191-1/+1
| | | | | | | | | | | | | | r201608 made llvm corretly handle private globals with MachO. r201622 fixed a bug in it and r201624 and r201625 were changes for using private linkage, assuming that llvm would do the right thing. They all got reverted because r201608 introduced a crash in LTO. This patch includes a fix for that. The issue was that TargetLoweringObjectFile now has to be initialized before we can mangle names of private globals. This is trivially true during the normal codegen pipeline (the asm printer does it), but LTO has to do it manually. llvm-svn: 201700
* Revert r201622 and r201608.Daniel Jasper2014-02-191-1/+1
| | | | | | | This causes the LLVMgold plugin to segfault. More information on the replies to r201608. llvm-svn: 201669
* Fix PR18743.Rafael Espindola2014-02-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | The IR @foo = private constant i32 42 is valid, but before this patch we would produce an invalid MachO from it. It was invalid because it would use an L label in a section where the liker needs the labels in order to atomize it. One way of fixing it would be to just reject this IR in the backend, but that would not be very front end friendly. What this patch does is use an 'l' prefix in sections that we know the linker requires symbols for atomizing them. This allows frontends to just use private and not worry about which sections they go to or how the linker handles them. One small issue with this strategy is that now a symbol name depends on the section, which is not available before codegen. This is not a problem in practice. The reason is that it only happens with private linkage, which will be ignored by the non codegen users (llvm-nm and llvm-ar). llvm-svn: 201608
* Change MCStreamer EmitInstruction interface to take subtarget infoDavid Woodhouse2014-01-281-27/+28
| | | | llvm-svn: 200345
* Add an emitRawComment function and use it to simplify some uses of EmitRawText.Rafael Espindola2014-01-161-2/+1
| | | | llvm-svn: 199397
* Copy segment register when optimizing to MOV8ao8/MOV16ao16/MOV32ao32.Craig Topper2014-01-161-1/+2
| | | | llvm-svn: 199365
* [x86] Disambiguate RET[QL] and fix aliases for 16-bit modeDavid Woodhouse2014-01-081-3/+8
| | | | | | | | | | I couldn't see how to do this sanely without splitting RETQ from RETL. Eric says: "sad about the inability to roundtrip them now, but...". I have no idea what that means, but perhaps it wants preserving in the commit comment. llvm-svn: 198756
* Move the llvm mangler to lib/IR.Rafael Espindola2014-01-071-1/+1
| | | | | | This makes it available to tools that don't link with target (like llvm-ar). llvm-svn: 198708
* Make the llvm mangler depend only on DataLayout.Rafael Espindola2014-01-031-1/+2
| | | | | | | | | | | | | | Before this patch any program that wanted to know the final symbol name of a GlobalValue had to link with Target. This patch implements a compromise solution where the mangler uses DataLayout. This way, any tool that already links with Target (llc, clang) gets the exact behavior as before and new IR files can be mangled without linking with Target. With this patch the mangler is constructed with just a DataLayout and DataLayout is extended to include the information the Mangler needs. llvm-svn: 198438
* Handle MOV32r0 in expandPostRAPseudo instead of MCInst lowering. No ↵Craig Topper2013-12-311-8/+0
| | | | | | functional change intended. llvm-svn: 198254
* Remove the isImplicitlyPrivate argument of getNameWithPrefix.Rafael Espindola2013-12-051-1/+1
| | | | | | | | | | | | getSymbolWithGlobalValueBase use is to create a name of a new symbol based on the name of an existing GV. Assert that and then remove the last call to pass true to isImplicitlyPrivate. This gives the mangler API a 1:1 mapping from GV to names, which is what we need to drop the mangler dependency on the target (and use an extended datalayout instead). llvm-svn: 196472
* Hide the stub created for MO_ExternalSymbol too.Rafael Espindola2013-12-051-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | given declare void @llvm.memset.p0i8.i32(i8* nocapture, i8, i32, i32, i1) declare void @foo() define void @bar() { call void @foo() call void @llvm.memset.p0i8.i32(i8* null, i8 0, i32 188, i32 1, i1 false) ret void } We used to produce L_foo$stub: .indirect_symbol _foo .ascii "\364\364\364\364\364" _memset$stub: .indirect_symbol _memset .ascii "\364\364\364\364\364" We not produce a private stub for memset too. Stubs are not needed with recent linkers, but we still produce them for darwin8. Thanks to David Fang for confirming that gcc used to do this too. llvm-svn: 196468
* [Stackmap] Emit multi-byte nops for X86.Juergen Ributzka2013-12-041-22/+70
| | | | llvm-svn: 196334
* Refactor a lot of patchpoint/stackmap related code to simplify and make itLang Hames2013-11-291-84/+0
| | | | | | | | | | | | | | | | | | | | | | target independent. Most of the x86 specific stackmap/patchpoint handling was necessitated by the use of the native address-mode format for frame index operands. PEI has now been modified to treat stackmap/patchpoint similarly to DEBUG_INFO, allowing us to use a simple, platform independent register/offset pair for frame indexes on stackmap/patchpoints. Notes: - Folding is now platform independent and automatically supported. - Emiting patchpoints with direct memory references now just involves calling the TargetLoweringBase::emitPatchPoint utility method from the target's XXXTargetLowering::EmitInstrWithCustomInserter method. (See X86TargetLowering for an example). - No more ugly platform-specific operand parsers. This patch shouldn't change the generated output for X86. llvm-svn: 195944
* Refactor to remove a bit of duplication. No functionality change.Rafael Espindola2013-11-281-24/+24
| | | | llvm-svn: 195933
* Use the mangler consistently instead of using getGlobalPrefix directly.Rafael Espindola2013-11-281-2/+1
| | | | llvm-svn: 195911
* Add an abstraction to handle patchpoint operands.Andrew Trick2013-11-191-63/+17
| | | | | | | Hard-coded operand indices were scattered throughout lowering stages and layers. It was super bug prone. llvm-svn: 195093
* Added a size field to the stack map record to handle subregister spills.Andrew Trick2013-11-171-10/+27
| | | | | | | | Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
* Remove unused arguments.Lang Hames2013-11-151-4/+2
| | | | llvm-svn: 194882
* Minor extension to llvm.experimental.patchpoint: don't require a call.Andrew Trick2013-11-141-11/+16
| | | | | | | | If a null call target is provided, don't emit a dummy call. This allows the runtime to reserve as little nop space as it needs without the requirement of emitting a call. llvm-svn: 194676
* Lower X86::MORESTACK_RET and X86::MORESTACK_RET_RESTORE_R10 inLang Hames2013-11-111-12/+12
| | | | | | | | | | | | | | X86AsmPrinter::EmitInstruction, rather than X86MCInstLower::Lower. The aim is to improve the reusability of the X86MCInstLower class by making it more function-like. The X86::MORESTACK_RET_RESTORE_R10 pseudo broke the function model by emitting an extra instruction to the MCStreamer attached to the AsmPrinter. The patch should have no impact on generated code. llvm-svn: 194431
* [Stackmap] Materialize the jump address within the patchpoint noop slide.Juergen Ributzka2013-11-091-3/+22
| | | | | | | | | | | | | | | This patch moves the jump address materialization inside the noop slide. This enables patching of the materialization itself or its complete removal. This patch also adds the ability to define scratch registers that can be used safely by the code called from the patchpoint intrinsic. At least one scratch register is required, because that one is used for the materialization of the jump address. This patch depends on D2009. Differential Revision: http://llvm-reviews.chandlerc.com/D2074 Reviewed by Andy llvm-svn: 194306
* [Stackmap] Add AnyReg calling convention support for patchpoint intrinsic.Juergen Ributzka2013-11-081-8/+27
| | | | | | | | | | | | | | The idea of the AnyReg Calling Convention is to provide the call arguments in registers, but not to force them to be placed in a paticular order into a specified set of registers. Instead it is up tp the register allocator to assign any register as it sees fit. The same applies to the return value (if applicable). Differential Revision: http://llvm-reviews.chandlerc.com/D2009 Reviewed by Andy llvm-svn: 194293
* Fix unused variable warnings.Dan Gohman2013-10-311-0/+3
| | | | llvm-svn: 193823
* Add support for stack map generation in the X86 backend.Andrew Trick2013-10-311-0/+124
| | | | | | Originally implemented by Lang Hames. llvm-svn: 193811
* Add a helper getSymbol to AsmPrinter.Rafael Espindola2013-10-291-3/+3
| | | | llvm-svn: 193627
* The asm printer has a mangler. Don't keep a second pointer to it.Rafael Espindola2013-10-291-10/+11
| | | | llvm-svn: 193616
* X86: Shrink certain forms of movsx.Benjamin Kramer2013-07-121-0/+35
| | | | | | | | | | | | In particular: movsbw %al, %ax --> cbtw movswl %ax, %eax --> cwtl movslq %eax, %rax --> cltq According to Intel's manual those have the same performance characteristics but come with a smaller encoding. llvm-svn: 186174
* DebugInfo: remove target-specific Frame Index handling for DBG_VALUE ↵David Blaikie2013-06-161-7/+1
| | | | | | | | | | MachineInstrs Frame index handling is now target-agnostic, so delete the target hooks for creation & asm printing of target-specific addressing in DBG_VALUEs and any related functions. llvm-svn: 184067
* X86: Stop LEA64_32r doing unspeakable things to its arguments.Tim Northover2013-06-101-17/+1
| | | | | | | | | | | | Previously LEA64_32r went through virtually the entire backend thinking it was using 32-bit registers until its blissful illusions were cruelly snatched away by MCInstLower and 64-bit equivalents were substituted at the last minute. This patch makes it behave normally, and take 64-bit registers as sources all the way through. Previous uses (for 32-bit arithmetic) are accommodated via SUBREG_TO_REG instructions which make the types and classes agree properly. llvm-svn: 183693
* Revert r183069: "TMP: LEA64_32r fixing"Tim Northover2013-06-011-1/+17
| | | | | | Very sorry, it was committed from the wrong branch by mistake. llvm-svn: 183070
* TMP: LEA64_32r fixingTim Northover2013-06-011-17/+1
| | | | llvm-svn: 183069
* X86: change MOV64ri64i32 into MOV32ri64Tim Northover2013-06-011-13/+4
| | | | | | | | | | | | | | The MOV64ri64i32 instruction required hacky MCInst lowering because it was allocated as setting a GR64, but the eventual instruction ("movl") only set a GR32. This converts it into a so-called "MOV32ri64" which still accepts a (appropriate) 64-bit immediate but defines a GR32. This is then converted to the full GR64 by a SUBREG_TO_REG operation, thus keeping everyone happy. This fixes a typo in the opcode field of the original patch, which should make the legact JIT work again (& adds test for that problem). llvm-svn: 183068
* Temporarily Revert "X86: change MOV64ri64i32 into MOV32ri64" as itEric Christopher2013-05-311-4/+13
| | | | | | seems to have caused PR16192 and other JIT related failures. llvm-svn: 183059
* X86: change MOV64ri64i32 into MOV32ri64Tim Northover2013-05-311-13/+4
| | | | | | | | | | The MOV64ri64i32 instruction required hacky MCInst lowering because it was allocated as setting a GR64, but the eventual instruction ("movl") only set a GR32. This converts it into a so-called "MOV32ri64" which still accepts a (appropriate) 64-bit immediate but defines a GR32. This is then converted to the full GR64 by a SUBREG_TO_REG operation, thus keeping everyone happy. llvm-svn: 182991
* X86: use sub-register sequences for MOV*r0 operationsTim Northover2013-05-301-10/+0
| | | | | | | | | | | | Instead of having a bunch of separate MOV8r0, MOV16r0, ... pseudo-instructions, it's better to use a single MOV32r0 (which will expand to "xorl %reg, %reg") and obtain other sizes with EXTRACT_SUBREG and SUBREG_TO_REG. The encoding is smaller and partial register updates can sometimes be avoided. Until recently, this sequence was a barrier to rematerialization though. That should now be fixed so it's an appropriate time to make the change. llvm-svn: 182928
* X86: change zext moves to use sub-register infrastructure.Tim Northover2013-05-301-6/+0
| | | | | | | | | | | | 32-bit writes on amd64 zero out the high bits of the corresponding 64-bit register. LLVM makes use of this for zero-extension, but until now relied on custom MCLowering and other code to fixup instructions. Now we have proper handling of sub-registers, this can be done by creating SUBREG_TO_REG instructions at selection-time. Should be no change in functionality. llvm-svn: 182921
* Add X86 code emitter support AVX encoded MRMDestReg instructions.Craig Topper2013-03-161-24/+33
| | | | | | Previously we weren't skipping the VVVV encoded register. Based on patch by Michael Liao. llvm-svn: 177221
* Teach X86 MC instruction lowering that VMOVAPSrr and other VEX-encoded ↵Craig Topper2013-03-141-0/+42
| | | | | | register to register moves should be switched from using the MRMSrcReg form to the MRMDestReg form if the source register is a 64-bit extended register and the destination register is not. This allows the instruction to be encoded using the 2-byte VEX form instead of the 3-byte VEX form. The GNU assembler has similar behavior. llvm-svn: 177011
* Two changes relevant to LEA and x32:David Sehr2013-02-011-1/+2
| | | | | | | | | 1) allows the use of RIP-relative addressing in 32-bit LEA instructions under x86-64 (ILP32 and LP64) 2) separates the size of address registers in 64-bit LEA instructions from control by ILP32/LP64. llvm-svn: 174208
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-1/+1
| | | | | | | | | | | | | | | | | | | | | into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-4/+4
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
OpenPOWER on IntegriCloud