summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/X86/X86MCInstLower.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [X86] Make isel select the 2-byte register form of INC/DEC even in ↵Craig Topper2015-01-061-0/+18
| | | | | | | | non-64-bit mode. Convert to the 1-byte form in non-64-bit mode as part of MCInst lowering. Overall this seems simpler. It reduces duplication of patterns between both modes and it simplifies the memory folding/unfolding tables as they don't need to create fake instructions just to keep track of 64-bitness. llvm-svn: 225252
* [X86] Make isel select the shorter form of jump instructions instead of the ↵Craig Topper2015-01-061-22/+0
| | | | | | | | long form. The assembler backend will relax to the long form if necessary. This removes a swap from long form to short form in the MCInstLowering code. Selecting the long form used to be required by the old JIT. llvm-svn: 225242
* [X86] Bring some better consistency to the naming of the move to/from ↵Craig Topper2015-01-021-6/+6
| | | | | | %al/ax/eax/rax with memory offset. llvm-svn: 225078
* [X86] Clean up whitespace as well as minor coding styleMichael Liao2014-12-041-5/+4
| | | | llvm-svn: 223339
* Remove unneccessary code introduced with 223101.Philip Reames2014-12-021-10/+2
| | | | llvm-svn: 223132
* Fix variable used only in assertion.Nick Lewycky2014-12-021-1/+2
| | | | llvm-svn: 223101
* [Statepoints 2/4] Statepoint infrastructure for garbage collection: MI & ↵Philip Reames2014-12-011-1/+63
| | | | | | | | | | | | | | x86-64 Backend This is the second patch in a small series. This patch contains the MachineInstruction and x86-64 backend pieces required to lower Statepoints. It does not include the code to actually generate the STATEPOINT machine instruction and as a result, the entire patch is currently dead code. I will be submitting the SelectionDAG parts within the next 24-48 hours. Since those pieces are by far the most complicated, I wanted to minimize the size of that patch. That patch will include the tests which exercise the functionality in this patch. The entire series can be seen as one combined whole in http://reviews.llvm.org/D5683. The STATEPOINT psuedo node is generated after all gc values are explicitly spilled to stack slots. The purpose of this node is to wrap an actual call instruction while recording the spill locations of the meta arguments used for garbage collection and other purposes. The STATEPOINT is modeled as modifing all of those locations to prevent backend optimizations from forwarding the value from before the STATEPOINT to after the STATEPOINT. (Doing so would break relocation semantics for collectors which wish to relocate roots.) The implementation of STATEPOINT is closely modeled on PATCHPOINT. Eventually, much of the code in this patch will be removed. The long term plan is to merge the functionality provided by statepoints and patchpoints. Merging their implementations in the backend is likely to be a good starting point. Reviewed by: atrick, ributzka llvm-svn: 223085
* Fix a stackmap bug introduced in r220710.Pete Cooper2014-10-271-4/+14
| | | | | | | | For a call to not return in to the stackmap shadow, the shadow must end with the call. To do this, we must insert any required nops *before* the call, and not after it. llvm-svn: 220728
* Stackmap shadows should consider call returns a branch target.Pete Cooper2014-10-271-0/+6
| | | | | | | | To avoid emitting too many nops, a stackmap shadow can include emitted instructions in the shadow, but these must not include branch targets. A return from a call should count as a branch target as patching over the instructions after the call would lead to incorrect behaviour for threads currently making that call, when they return. llvm-svn: 220710
* Fix a bit of confusion about .set and produce more readable assembly.Rafael Espindola2014-10-211-1/+2
| | | | | | | | | | | | | | | Every target we support has support for assembly that looks like a = b - c .long a What is special about MachO is that the above combination suppresses the production of a relocation. With this change we avoid producing the intermediary labels when they don't add any value. llvm-svn: 220256
* [x86] Implement v16i16 support with AVX2 in the new vector shuffleChandler Carruth2014-09-251-1/+2
| | | | | | | | | | | | | | | lowering. This also implements the fancy blend lowering for v16i16 using AVX2 and teaches the X86 backend to print shuffle masks for 256-bit PSHUFB and PBLENDW instructions. It also makes the mask decoding correct for PBLENDW instructions. The yaks, they are legion. Tests are updated accordingly. There are some missing tests for the VBLENDVB lowering, but I'll add those in a follow-up as this commit has accumulated enough cruft already. llvm-svn: 218430
* [x86] Teach the instruction lowering to add comments describing constantChandler Carruth2014-09-241-12/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pool data being loaded into a vector register. The comments take the form of: # ymm0 = [a,b,c,d,...] # xmm1 = <x,y,z...> The []s are used for generic sequential data and the <>s are used for specifically ConstantVector loads. Undef elements are printed as the letter 'u', integers in decimal, and floating point values as floating point values. Suggestions on improving the formatting or other aspects of the display are very welcome. My primary use case for this is to be able to FileCheck test masks passed to vector shuffle instructions in-register. It isn't fantastic for that (no decoding special zeroing semantics or other tricks), but it at least puts the mask onto an instruction line that could reasonably be checked. I've updated many of the new vector shuffle lowering tests to leverage this in their test cases so that we're actually checking the shuffle masks remain as expected. Before implementing this, I tried a *bunch* of different approaches. I looked into teaching the MCInstLower code to scan up the basic block and find a definition of a register used in a shuffle instruction and then decode that, but this seems incredibly brittle and complex. I talked to Hal a lot about the "right" way to do this: attach the raw shuffle mask to the instruction itself in some form of unencoded operands, and then use that to emit the comments. I still think that's the optimal solution here, but it proved to be beyond what I'm up for here. In particular, it seems likely best done by completing the plumbing of metadata through these layers and attaching the shuffle mask in metadata which could have fully automatic dropping when encoding an actual instruction. llvm-svn: 218377
* [x86] More refactoring of the shuffle comment emission. The previousChandler Carruth2014-09-241-38/+38
| | | | | | | | | | | attempt didn't work out so well. It looks like it will be much better for introducing extra logic to find a shuffle mask if the finding logic is totally separate. This also makes it easy to sink the opcode logic completely out of the routine so we don't re-dispatch across it. Still no functionality changed. llvm-svn: 218363
* [x86] Bypass the shuffle mask comment generation when not using verboseChandler Carruth2014-09-241-0/+2
| | | | | | | | asm. This can be somewhat expensive and there is no reason to do it outside of tests or debugging sessions. I'm also likely to make it significantly more expensive to support more styles of shuffles. llvm-svn: 218362
* [x86] Hoist the logic for extracting the relevant bits of informationChandler Carruth2014-09-241-16/+20
| | | | | | | | | | | | | | | from the MachineInstr into the caller which is already doing a switch over the instruction. This will make it more clear how to compute different operands to feed the comment selection for example. Also, in a drive-by-fix, don't append an empty comment string (which is a no-op ultimately). No functionality changed. llvm-svn: 218361
* [x86] Start refactoring the comment printing logic in the MC lowering ofChandler Carruth2014-09-241-87/+102
| | | | | | | | | | | | | | | vector shuffles. This is just the beginning by hoisting it into its own function and making use of early exit to dramatically simplify the flow of the function. I'm going to be incrementally refactoring this until it is a bit less magical how this applies to other instructions, and I can teach it how to dig a shuffle mask out of a register. Then I plan to hook it up to VPERMD so we get our mask comments for it. No functionality changed yet. llvm-svn: 218357
* [x86] Teach the vector comment parsing and printing to correctly handleChandler Carruth2014-09-231-5/+8
| | | | | | | | | | | | | | | | | undef in the shuffle mask. This shows up when we're printing comments during lowering and we still have an IR-level constant hanging around that models undef. A nice consequence of this is *much* prettier test cases where the undef lanes actually show up as undef rather than as a particular set of values. This also allows us to print shuffle comments in cases that use undef such as the recently added variable VPERMILPS lowering. Now those test cases have nice shuffle comments attached with their details. The shuffle lowering for PSHUFB has been augmented to use undef, and the shuffle combining has been augmented to comprehend it. llvm-svn: 218301
* [x86] Teach the AVX1 path of the new vector shuffle lowering one moreChandler Carruth2014-09-231-6/+21
| | | | | | | | | | | | | | | | | | | | | | trick that I missed. VPERMILPS has a non-immediate memory operand mode that allows it to do asymetric shuffles in the two 128-bit lanes. Use this rather than two shuffles and a blend. However, it turns out the variable shuffle path to VPERMILPS (and VPERMILPD, although that one offers no functional differenc from the immediate operand other than variability) wasn't even plumbed through codegen. Do such plumbing so that we can reasonably emit a variable-masked VPERMILP instruction. Also plumb basic comment parsing and printing through so that the tests are reasonable. There are still a few tests which don't show the shuffle pattern. These are tests with undef lanes. I'll teach the shuffle decoding and printing to handle undef mask entries in a follow-up. I've looked at the masks and they seem reasonable. llvm-svn: 218300
* [X86] Allow atomic operations using immediates to avoid using a registerRobin Morisset2014-09-021-8/+32
| | | | | | | | | | | | | | | | The only valid lowering of atomic stores in the X86 backend was mov from register to memory. As a result, storing an immediate required a useless copy of the immediate in a register. Now these can be compiled as a simple mov. Similarily, adding/and-ing/or-ing/xor-ing an immediate to an atomic location (but through an atomic_store/atomic_load, not a fetch_whatever intrinsic) can now make use of an 'add $imm, x(%rip)' instead of using a register. And the same applies to inc/dec. This second point matches the first issue identified in http://llvm.org/bugs/show_bug.cgi?id=17281 llvm-svn: 216980
* fix typoSanjay Patel2014-08-061-1/+1
| | | | llvm-svn: 214995
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-041-7/+7
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* Fix failure to invoke exception handler on Win64Reid Kleckner2014-08-041-0/+29
| | | | | | | | | | | | | When the last instruction prior to a function epilogue is a call, we need to emit a nop so that the return address is not in the epilogue IP range. This is consistent with MSVC's behavior, and may be a workaround for a bug in the Win64 unwinder. Differential Revision: http://reviews.llvm.org/D4751 Patch by Vadim Chugunov! llvm-svn: 214775
* [x86] Switch to using the variable we extracted this operand into.Chandler Carruth2014-08-021-1/+1
| | | | | | | Spotted this missed refactoring by inspection when reading code, and it doesn't changethe functionality at all. llvm-svn: 214627
* [x86] Teach my pshufb comment printer to handle VPSHUFB forms as well asChandler Carruth2014-08-021-2/+3
| | | | | | | PSHUFB forms. This will be important to update some AVX tests when I add PSHUFB combining. llvm-svn: 214624
* [x86] Fix unused variable warning in no-asserts build.Chandler Carruth2014-07-261-0/+1
| | | | llvm-svn: 213989
* [x86] Teach the X86 backend to print shuffle comments for PSHUFBChandler Carruth2014-07-251-0/+80
| | | | | | | | | | | | | | | | | | | | instructions which happen to have a constant mask. Currently, this only handles a very narrow set of cases, but those happen to be the cases that I care about for testing shuffles sanely. This is a bit trickier than other shuffle instructions because we're decoding constants out of the constant pool. The current MC layer makes it completely impossible to inspect a constant pool entry, so we have to do it at the MI level and attach the comment to the streamer on its way out. So no joy for disassembling, but it does make test cases and asm dumps *much* nicer. Sorry for no test cases, but it didn't really seem that valuable to go trolling through existing old test cases and updating them. I'll have lots of testing of this in the upcoming patch for SSSE3 emission in the new vector shuffle lowering code paths. llvm-svn: 213986
* [X86] Clarify some stackmap shadow optimization code as based on reviewLang Hames2014-07-251-5/+6
| | | | | | | | feedback from Eric Christopher. No functional change. llvm-svn: 213917
* [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
OpenPOWER on IntegriCloud