summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/X86/X86InstrSystem.td
Commit message (Collapse)AuthorAgeFilesLines
* Reapply r372285 "GlobalISel: Don't materialize immarg arguments to intrinsics"Matt Arsenault2019-09-191-1/+1
| | | | | | | | | This reverts r372314, reapplying r372285 and the commits which depend on it (r372286-r372293, and r372296-r372297) This was missing one switch to getTargetConstant in an untested case. llvm-svn: 372338
* Revert r372285 "GlobalISel: Don't materialize immarg arguments to intrinsics"Hans Wennborg2019-09-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This broke the Chromium build, causing it to fail with e.g. fatal error: error in backend: Cannot select: t362: v4i32 = X86ISD::VSHLI t392, Constant:i8<15> See llvm-commits thread of r372285 for details. This also reverts r372286, r372287, r372288, r372289, r372290, r372291, r372292, r372293, r372296, and r372297, which seemed to depend on the main commit. > Encode them directly as an imm argument to G_INTRINSIC*. > > Since now intrinsics can now define what parameters are required to be > immediates, avoid using registers for them. Intrinsics could > potentially want a constant that isn't a legal register type. Also, > since G_CONSTANT is subject to CSE and legalization, transforms could > potentially obscure the value (and create extra work for the > selector). The register bank of a G_CONSTANT is also meaningful, so > this could throw off future folding and legalization logic for AMDGPU. > > This will be much more convenient to work with than needing to call > getConstantVRegVal and checking if it may have failed for every > constant intrinsic parameter. AMDGPU has quite a lot of intrinsics wth > immarg operands, many of which need inspection during lowering. Having > to find the value in a register is going to add a lot of boilerplate > and waste compile time. > > SelectionDAG has always provided TargetConstant for constants which > should not be legalized or materialized in a register. The distinction > between Constant and TargetConstant was somewhat fuzzy, and there was > no automatic way to force usage of TargetConstant for certain > intrinsic parameters. They were both ultimately ConstantSDNode, and it > was inconsistently used. It was quite easy to mis-select an > instruction requiring an immediate. For SelectionDAG, start emitting > TargetConstant for these arguments, and using timm to match them. > > Most of the work here is to cleanup target handling of constants. Some > targets process intrinsics through intermediate custom nodes, which > need to preserve TargetConstant usage to match the intrinsic > expectation. Pattern inputs now need to distinguish whether a constant > is merely compatible with an operand or whether it is mandatory. > > The GlobalISelEmitter needs to treat timm as a special case of a leaf > node, simlar to MachineBasicBlock operands. This should also enable > handling of patterns for some G_* instructions with immediates, like > G_FENCE or G_EXTRACT. > > This does include a workaround for a crash in GlobalISelEmitter when > ARM tries to uses "imm" in an output with a "timm" pattern source. llvm-svn: 372314
* GlobalISel: Don't materialize immarg arguments to intrinsicsMatt Arsenault2019-09-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Encode them directly as an imm argument to G_INTRINSIC*. Since now intrinsics can now define what parameters are required to be immediates, avoid using registers for them. Intrinsics could potentially want a constant that isn't a legal register type. Also, since G_CONSTANT is subject to CSE and legalization, transforms could potentially obscure the value (and create extra work for the selector). The register bank of a G_CONSTANT is also meaningful, so this could throw off future folding and legalization logic for AMDGPU. This will be much more convenient to work with than needing to call getConstantVRegVal and checking if it may have failed for every constant intrinsic parameter. AMDGPU has quite a lot of intrinsics wth immarg operands, many of which need inspection during lowering. Having to find the value in a register is going to add a lot of boilerplate and waste compile time. SelectionDAG has always provided TargetConstant for constants which should not be legalized or materialized in a register. The distinction between Constant and TargetConstant was somewhat fuzzy, and there was no automatic way to force usage of TargetConstant for certain intrinsic parameters. They were both ultimately ConstantSDNode, and it was inconsistently used. It was quite easy to mis-select an instruction requiring an immediate. For SelectionDAG, start emitting TargetConstant for these arguments, and using timm to match them. Most of the work here is to cleanup target handling of constants. Some targets process intrinsics through intermediate custom nodes, which need to preserve TargetConstant usage to match the intrinsic expectation. Pattern inputs now need to distinguish whether a constant is merely compatible with an operand or whether it is mandatory. The GlobalISelEmitter needs to treat timm as a special case of a leaf node, simlar to MachineBasicBlock operands. This should also enable handling of patterns for some G_* instructions with immediates, like G_FENCE or G_EXTRACT. This does include a workaround for a crash in GlobalISelEmitter when ARM tries to uses "imm" in an output with a "timm" pattern source. llvm-svn: 372285
* [X86] Remove CustomInserters for RDPKRU/WRPKRU. Use some custom lowering and ↵Craig Topper2019-04-041-9/+4
| | | | | | | | | | | | | | new ISD opcodes instead. These inserters inserted some instructions to zero some registers and copied from virtual registers to physical registers. This change instead inserts the zeros directly into the DAG at lowering time using new ISD opcodes that take the extra zeroes as inputs. The zeros will then go through isel on their own to select the MOV32r0 pseudo. Then we just need to mention the physical registers directly in the isel patterns and the isel table and InstrEmitter will take care of inserting the necessary copies to/from physical registers. llvm-svn: 357659
* [X86] Remove X86 specific dag nodes for RDTSC/RDTSCP/RDPMC. NFCIAndrea Di Biagio2019-03-201-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | This patch removes the following dag node opcodes from namespace X86ISD: RDTSC_DAG, RDTSCP_DAG, RDPMC_DAG The logic that expands RDTSC/RDPMC/XGETBV intrinsics is basically the same. The only differences are: RDTSC/RDTSCP don't implicitly read ECX. RDTSCP also implicitly writes ECX. I moved the common expansion logic into a helper function with the goal to get rid of code repetition. That helper is now used for the expansion of RDTSC/RDTSCP/RDPMC/XGETBV intrinsics. No functional change intended. Differential Revision: https://reviews.llvm.org/D59547 llvm-svn: 356546
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [cfi-verify] Support AArch64.Joel Galenson2018-07-131-1/+1
| | | | | | | | | | | | This patch adds support for AArch64 to cfi-verify. This required three changes to cfi-verify. First, it generalizes checking if an instruction is a trap by adding a new isTrap flag to TableGen (and defining it for x86 and AArch64). Second, the code that ensures that the operand register is not clobbered between the CFI check and the indirect call needs to allow a single dereference (in x86 this happens as part of the jump instruction). Third, we needed to ensure that return instructions are not counted as indirect branches. Technically, returns are indirect branches and can be covered by CFI, but LLVM's forward-edge CFI does not protect them, and x86 does not consider them, so we keep that behavior. In addition, we had to improve AArch64's code to evaluate the branch target of a MCInst to handle calls where the destination is not the first operand (which it often is not). Differential Revision: https://reviews.llvm.org/D48836 llvm-svn: 337007
* [X86] Add NotMemoryFoldable to a bunch of instructions to suppress them from ↵Craig Topper2018-06-121-22/+22
| | | | | | | | | | the autogenerated load folding table. Most of these are system instructions or other instructions we don't use in CodeGen. No point wasting space for them in the table. Removing them from the autogenerated table makes it easier to review the manual table. A few are real opcode collisions where the memory and register forms are completely different instructions. llvm-svn: 334474
* [x86] invpcid LLVM intrinsicGabor Buella2018-05-251-3/+17
| | | | | | | | | | | | | | | Re-add the feature flag for invpcid, which was removed in r294561. Add an intrinsic, which always uses a 32 bit integer as first argument, while the instruction actually uses a 64 bit register in 64 bit mode for the INVPCID_TYPE argument. Reviewers: craig.topper Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D47141 llvm-svn: 333255
* [X86][CET] Changing -fcf-protection behavior to comply with gcc (LLVM part)Alexander Ivchenko2018-05-181-4/+5
| | | | | | | | | | | | | | | | | | | | This patch aims to match the changes introduced in gcc by https://gcc.gnu.org/ml/gcc-cvs/2018-04/msg00534.html. The IBT feature definition is removed, with the IBT instructions being freely available on all X86 targets. The shadow stack instructions are also being made freely available, and the use of all these CET instructions is controlled by the module flags derived from the -fcf-protection clang option. The hasSHSTK option remains since clang uses it to determine availability of shadow stack instruction intrinsics, but it is no longer directly used. Comes with a clang patch (D46881). Patch by mike.dvoretsky Differential Revision: https://reviews.llvm.org/D46882 llvm-svn: 332705
* [X86] ptwrite intrinsicGabor Buella2018-05-101-7/+10
| | | | | | | | | | Reviewers: craig.topper, RKSimon Reviewed By: craig.topper, RKSimon Differential Revision: https://reviews.llvm.org/D46539 llvm-svn: 331961
* [X86] Tag PCONFIG instruction with WriteSystem scheduler classSimon Pilgrim2018-05-081-0/+2
| | | | llvm-svn: 331773
* [x86] Introduce the pconfig instructionGabor Buella2018-05-081-0/+17
| | | | | | | | | | Reviewers: craig.topper, zvi Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D46430 llvm-svn: 331739
* [X86] Remove 'opaque ptr' from the intel syntax parser and printer.Craig Topper2018-05-011-38/+38
| | | | | | | | Previously for instructions like fxsave we would print "opaque ptr" as part of the memory operand. Now we print nothing. We also no longer accept "opaque ptr" in the parser. We still accept any size to be specified for these instructions, but we may want to consider only parsing when no explicit size is specified. This what gas does. llvm-svn: 331243
* [X86] Use a MnemonicAlias instead of an InstAlias.Craig Topper2018-04-301-9/+0
| | | | llvm-svn: 331157
* [X86] Make 64-bit sysret/sysexit not ambiguous in Intel assembly syntax.Craig Topper2018-04-291-2/+2
| | | | | | This also makes it default to the 32-bit non REX.W version in 64-bit mode. This seems to be more consistent with gas. llvm-svn: 331149
* [X86] Add suffixes to the LGDT/LIDT/SGDT/SIDT mnemonics in Intel syntax. Add ↵Craig Topper2018-04-291-8/+17
| | | | | | | | | | aliases based on 16/32-bit mode to choose the default. This allows the instruction selection to follow mode in Intel syntax. And allows a suffix to be used to change size. This matches gas behavior from what I could tell. llvm-svn: 331138
* [X86] Remove SLDT64m instruction.Craig Topper2018-04-291-3/+0
| | | | | | | | It doesn't really exist. The instruction always writes 16-bits of memory. Putting a REX.w on it won't change anything. While I was touching the encoding tests to remove it, I added some other missing register form test cases. llvm-svn: 331135
* [X86] Remove OpSizeIgnore, it's not implemented any differently than ↵Craig Topper2018-04-221-2/+2
| | | | | | OpSizeFixed. llvm-svn: 330532
* [X86] Introduce LLVM wbinvd intrinsicGabor Buella2018-04-121-1/+1
| | | | | | | | | | | | A previously missing intrinsic for an old instruction. Reviewers: craig.topper, echristo Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D45312 llvm-svn: 329936
* [X86] Remove system/control schedule itineraries (PR37093)Simon Pilgrim2018-04-121-238/+189
| | | | llvm-svn: 329903
* [X86] Describe wbnoinvd instructionGabor Buella2018-04-111-0/+6
| | | | | | | | | | | | | | | Similar to the wbinvd instruction, except this one does not invalidate caches. Ring 0 only. The encoding matches a wbinvd instruction with an F3 prefix. Reviewers: craig.topper, zvi, ashlykov Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D43816 llvm-svn: 329847
* [x86] Model the direction flag (DF) separately from the rest of EFLAGS.Chandler Carruth2018-04-101-0/+13
| | | | | | | | | | | | | | | | | | | | | This cleans up a number of operations that only claimed te use EFLAGS due to using DF. But no instructions which we think of us setting EFLAGS actually modify DF (other than things like popf) and so this needlessly creates uses of EFLAGS that aren't really there. In fact, DF is so restrictive it is pretty easy to model. Only STD, CLD, and the whole-flags writes (WRFLAGS and POPF) need to model this. I've also somewhat cleaned up some of the flag management instruction definitions to be in the correct .td file. Adding this extra register also uncovered a failure to use the correct datatype to hold X86 registers, and I've corrected that as necessary here. Differential Revision: https://reviews.llvm.org/D45154 llvm-svn: 329673
* [X86] Change 32 and 64 bit versions of LSL instruction have a 16-bit memory ↵Craig Topper2018-02-151-4/+6
| | | | | | | | operand. This matches the Intel and AMD documentation and is consistent with the LAR instruction. llvm-svn: 325197
* [X86] Tag CET-IBT instruction scheduler classesSimon Pilgrim2018-02-121-2/+2
| | | | llvm-svn: 324898
* [X86] Add intrinsic support for the RDPID instructionCraig Topper2018-01-181-6/+14
| | | | | | | | This adds a new instrinsic to support the rdpid instruction. The implementation is a bit weird because the intrinsic is defined as always returning 32-bits, but the assembler support thinks the instruction produces a 64-bit register in 64-bit mode. But really it zeros the upper 32 bits. So I had to add separate patterns where 64-bit mode uses an extract_subreg. Differential Revision: https://reviews.llvm.org/D42205 llvm-svn: 322910
* [X86] Disable sldtq parsing in 64-bit mode.Craig Topper2018-01-121-2/+2
| | | | llvm-svn: 322353
* Instrument Control Flow For Indirect Branch TrackingOren Ben Simhon2018-01-091-0/+5
| | | | | | | | | | | | | CET (Control-Flow Enforcement Technology) introduces a new mechanism called IBT (Indirect Branch Tracking). According to IBT, each Indirect branch should land on dedicated ENDBR instruction (End Branch). The new pass adds ENDBR instructions for every indirect jmp/call (including jumps using jump tables / switches). For more information, please see the following: https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf Differential Revision: https://reviews.llvm.org/D40482 Change-Id: Icb754489faf483a95248f96982a4e8b1009eb709 llvm-svn: 322062
* [X86] Add 'Requires<[In64BitMode]>' to a bunch of instructions that only ↵Craig Topper2017-12-151-30/+24
| | | | | | | | have memory and immediate operands. The asm parser wasn't preventing these from being accepted in 32-bit mode. Instructions that use a GR64 register are protected by the parser rejecting the register in 32-bit mode. llvm-svn: 320846
* [X86] Remove the 'Requires<[In64BitMode]>' from SHSTK instructions.Craig Topper2017-12-151-9/+5
| | | | | | This has no effect due to a top level "let Predicates =" around the instructions. But its also not required because the GR64 usage in the instruction guarantees it can never match. llvm-svn: 320843
* [X86] Fix XSAVE64 and similar instructions to not be allowed by the ↵Craig Topper2017-12-151-22/+20
| | | | | | | | | | assembler in 32-bit mode. There was a top level "let Predicates =" in the .td file that was overriding the Requires on each instruction. I've added an assert to the code emitter to catch more cases like this. I'm sure this isn't the only place where the right predicates aren't being applied. This assert already found that we don't block btq/btsq/btrq in 32-bit mode. llvm-svn: 320830
* [X86] Add RDMSR/WRMSR, RDPMC + RDTSC/RDTSCP schedule testsSimon Pilgrim2017-12-131-1/+2
| | | | | | Add missing RDTSCP itinerary llvm-svn: 320581
* Strip trailing whitespace. NFCI.Simon Pilgrim2017-12-091-12/+12
| | | | llvm-svn: 320265
* [X86] Tag FS/GS BASE R/W instruction scheduler classesSimon Pilgrim2017-12-091-9/+16
| | | | llvm-svn: 320264
* [X86] Tag segment prefixes as NOP instruction scheduling classesSimon Pilgrim2017-12-091-7/+8
| | | | llvm-svn: 320257
* [X86] Tag VIA PadLock crypto instructions scheduler classesSimon Pilgrim2017-12-081-1/+3
| | | | llvm-svn: 320159
* [X86] Tag PKU/INVPCID/RDPID/SMAP/SMX/PTWRITE system instructions scheduler ↵Simon Pilgrim2017-12-081-16/+30
| | | | | | classes llvm-svn: 320158
* Control-Flow Enforcement Technology - Shadow Stack support (LLVM side)Oren Ben Simhon2017-11-261-0/+58
| | | | | | | | | | | | | | | | | | Shadow stack solution introduces a new stack for return addresses only. The HW has a Shadow Stack Pointer (SSP) that points to the next return address. If we return to a different address, an exception is triggered. The shadow stack is managed using a series of intrinsics that are introduced in this patch as well as the new register (SSP). The intrinsics are mapped to new instruction set that implements CET mechanism. The patch also includes initial infrastructure support for IBT. For more information, please see the following: https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf Differential Revision: https://reviews.llvm.org/D40223 Change-Id: I4daa1f27e88176be79a4ac3b4cd26a459e88fed4 llvm-svn: 318996
* Avoid unecessary opsize byte in segment move to memoryNirav Dave2017-11-211-10/+2
| | | | | | | | | | | | | | | | | Segment moves to memory are always 16-bit. Remove invalid 32 and 64 bit variants. Recommiting with missing clang inline assembly test change. Fixes PR34478. Reviewers: rnk, craig.topper Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D39847 llvm-svn: 318797
* Revert r318678 to fix Clang testRichard Trieu2017-11-211-2/+10
| | | | | | r318678 caused the Clang test CodeGen/ms-inline-asm.c to start failing. llvm-svn: 318710
* [X86] Avoid unecessary opsize byte in segment move to memoryNirav Dave2017-11-201-10/+2
| | | | | | | | | | | | | | | | | Summary: Segment moves to memory are always 16-bit. Remove invalid 32 and 64 bit variants. Fixes PR34478. Reviewers: rnk, craig.topper Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D39847 llvm-svn: 318678
* [X86] Change XRSTOR to use PS instead of TB to match XSAVE.Craig Topper2017-10-231-2/+2
| | | | | | I don't think this changes anything functionally yet, but I plan to fix the disassembler to use this to disable matching certain instructions with 0xf3/0xf2/0x66 prefixes. llvm-svn: 316337
* [X86] Add PTWRITE instruction for assembler and disassembler.Craig Topper2017-10-231-2/+14
| | | | llvm-svn: 316333
* [X86] Add RDPID instruction for assembler and disassembler.Craig Topper2017-10-231-0/+9
| | | | llvm-svn: 316332
* 'into' instruction should not be decoded as a valid instr in 64-bit modeAndrew V. Tischenko2017-09-201-1/+1
| | | | llvm-svn: 313735
* [X86] Added missing mayLoad/mayStore attributes to some X86 instructions.Ayman Musa2017-04-131-5/+20
| | | | | | | | | Throughout the effort of automatically generating the X86 memory folding tables these missing information were encountered. This is a preparation work for a future patch including the automation of these tables. Differential Revision: https://reviews.llvm.org/D31714 llvm-svn: 300190
* [X86] Add xgetbv/xsetbv intrinsics to non-windows platformsGuy Blank2016-08-161-2/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D21958 llvm-svn: 278782
* [X86] Don't model UD2/UD2B as a terminatorDavid Majnemer2016-08-091-1/+1
| | | | | | | | | | | | | | A UD2 might make its way into the program via a call to @llvm.trap. Obviously, calls are not terminators. However, we modeled the X86 instruction, UD2, as a terminator. Later on, this confuses the epilogue insertion machinery which results in the epilogue getting inserted before the UD2. For some platforms, like x64, the result is a violation of the ABI. Instead, model UD2/UD2B as a side effecting instruction which may observe memory. llvm-svn: 278144
* test commit: remove trailing whitespaceZvi Rackover2016-06-181-1/+1
| | | | llvm-svn: 273094
* [X86] Remove many operands that represent memory stores from outs to ins. ↵Craig Topper2016-03-131-13/+13
| | | | | | These operands are the registers and immediates that specify the memory address not the memory itself thus they are inputs. llvm-svn: 263354
OpenPOWER on IntegriCloud