summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/X86/X86InstrInfo.td
Commit message (Collapse)AuthorAgeFilesLines
...
* [X86][BMI1] X86DAGToDAGISel: select BEXTR from x & (-1 >> (32 - y)) patternRoman Lebedev2018-10-301-40/+0
| | | | | | | | | | | | | | | | | | | | | Summary: The final pattern. There is no test changes: * We are looking for the pattern with one-use of it's mask, * If the mask is one-use, D48768 will unfold it into pattern d. * Thus, the tests have extra-use on the mask. * Thus, only the BMI2 BZHI can be tested, and it already worked. * So there is no BMI1 test coverage, we just assume it works since it uses the same codepath. Reviewers: craig.topper, RKSimon Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D53575 llvm-svn: 345584
* Experimental re-land of [X86][BMI1] X86DAGToDAGISel: select BEXTR from x << ↵Roman Lebedev2018-10-231-26/+0
| | | | | | | | | | | | | | | | (32 - y) >> (32 - y) pattern This initially landed in rL345014, but was reverted in rL345017 due to sanitizer-x86_64-linux-fast buildbot failure in check-lld (ELF/relocatable-versioned.s) test. While i'm not yet quite sure what is the problem, one obvious thing here is that extra truncation roundtrip. Maybe that's it? If not, will re-revert. Differential Revision: https://reviews.llvm.org/D53521 llvm-svn: 345027
* Revert "[X86][BMI1] X86DAGToDAGISel: select BEXTR from x << (32 - y) >> (32 ↵Roman Lebedev2018-10-231-0/+26
| | | | | | | | | | | | | | | | | | | | - y) pattern" *Seems* to be breaking sanitizer-x86_64-linux-fast buildbot, the ELF/relocatable-versioned.s test: ==17758==MemorySanitizer CHECK failed: /b/sanitizer-x86_64-linux-fast/build/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_allocator.cc:191 "((kBlockMagic)) == ((((u64*)addr)[0]))" (0x6a6cb03abcebc041, 0x0) #0 0x59716b in MsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /b/sanitizer-x86_64-linux-fast/build/llvm/projects/compiler-rt/lib/msan/msan.cc:393 #1 0x586635 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /b/sanitizer-x86_64-linux-fast/build/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_termination.cc:79 #2 0x57d5ff in __sanitizer::InternalFree(void*, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator32<__sanitizer::AP32> >*) /b/sanitizer-x86_64-linux-fast/build/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_allocator.cc:191 #3 0x7fc21b24193f (/lib/x86_64-linux-gnu/libc.so.6+0x3593f) #4 0x7fc21b241999 in exit (/lib/x86_64-linux-gnu/libc.so.6+0x35999) #5 0x7fc21b22c2e7 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e7) #6 0x57c039 in _start (/b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/lld+0x57c039) This reverts commit r345014. llvm-svn: 345017
* [X86][BMI1] X86DAGToDAGISel: select BEXTR from x << (32 - y) >> (32 - y) patternRoman Lebedev2018-10-231-26/+0
| | | | | | | | | | | | | | | | | | Summary: Continuation of D52348. We also get the `c) x & (-1 >> (32 - y))` pattern here, because of the D48768. I will add extra-uses into those tests and follow-up with a patch to handle those patterns too. Reviewers: RKSimon, craig.topper Reviewed By: craig.topper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D53521 llvm-svn: 345014
* X86: add alias for pushfw/popfw in Intel modeTim Northover2018-10-221-0/+4
| | | | | | | | | A while ago we changed pushf and popf in Intel mode to generate pushfq and popfq. Unfortunately that left us with no way to get the 16-bit encoding in Intel mode so this patch adds pushfw and popfw as aliases there. llvm-svn: 344949
* [X86] X86DAGToDAGISel: handle BZHI selection too, not just BEXTR.Roman Lebedev2018-10-221-14/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As discussed in D52304 / IRC, we now have pattern matching for 'bit extract' in two places - tablegen and `X86DAGToDAGISel`. There are 4 patterns. And we will have a problem with `x & (-1 >> (32 - y))` pattern. * If the mask is one-use, then it is always unfolded into `x << (32 - y) >> (32 - y)` first. Thus, the existing test coverage is already broken. * If it is not one-use, then it is not unfolded, and is matched as BZHI. * If it is not one-use, we will not match it as BEXTR. And if it is one-use, it will have been unfolded already. So we will either not handle that pattern for BEXTR, or not have test coverage for it. This is bad. As discussed with @craig.topper, let's unify this matching, and do everything in `X86DAGToDAGISel`. Then we will not have code duplication, and will have proper test coverage. This indeed does not affect any tests, and this is great. It means that for these two patterns, the `X86DAGToDAGISel` is identical to the tablegen version. Please review carefully, i'm not fully sure about that intrinsic change, and introduction of the new `X86ISD` opcode. Reviewers: craig.topper, RKSimon, spatel Reviewed By: craig.topper Subscribers: llvm-commits, craig.topper Differential Revision: https://reviews.llvm.org/D53164 llvm-svn: 344904
* [X86] Move ReadAfterLd functionality into X86FoldableSchedWrite (PR36957)Simon Pilgrim2018-10-051-3/+3
| | | | | | | | | | | | Currently we hardcode instructions with ReadAfterLd if the register operands don't need to be available until the folded load has completed. This doesn't take into account the different load latencies of different memory operands (PR36957). This patch adds a ReadAfterFold def into X86FoldableSchedWrite to replace ReadAfterLd, allowing us to specify the load latency at a scheduler class level. I've added ReadAfterVec*Ld classes that match the XMM/Scl, XMM and YMM/ZMM WriteVecLoad classes that we currently use, we can tweak these values in future patches once this infrastructure is in place. Differential Revision: https://reviews.llvm.org/D52886 llvm-svn: 343868
* [X86] PUSH/POP 'mem-mem' instructions are not RMW - these are 2 different ↵Simon Pilgrim2018-10-031-5/+5
| | | | | | | | | | addresses This patch adds a 'WriteCopy' [WriteLoad, WriteStore] schedule sequence instead to better model the behaviour Found by @andreadb during llvm-mca testing on btver2 which was crashing on "zero uop" WriteRMW only instructions llvm-svn: 343708
* [X86] Create schedule classes for BT(C|R|S)mi and BT(C|R|S)mr instructionsSimon Pilgrim2018-10-011-6/+6
| | | | llvm-svn: 343490
* [X86] Create schedule classes for BTmi and BTmr instructionsSimon Pilgrim2018-10-011-2/+2
| | | | llvm-svn: 343478
* [X86] Fix scheduler class for BTmi instructionsSimon Pilgrim2018-09-301-1/+1
| | | | | | This wasn't treated as a folded load instruction llvm-svn: 343424
* [X86] Split BT and BTC/BTR/BTS scheduler classesSimon Pilgrim2018-09-271-6/+6
| | | | llvm-svn: 343233
* [X86][BMI1] Add scheduler class for BLSI/BLSMSK/BLSR BMI1 instructionsSimon Pilgrim2018-09-141-2/+2
| | | | llvm-svn: 342234
* [X86] Improved sched model for X86 CMPXCHG* instructions.Andrew V. Tischenko2018-08-301-2/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D50070 llvm-svn: 341024
* [x86/retpoline] Split the LLVM concept of retpolines into separateChandler Carruth2018-08-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | subtarget features for indirect calls and indirect branches. This is in preparation for enabling *only* the call retpolines when using speculative load hardening. I've continued to use subtarget features for now as they continue to seem the best fit given the lack of other retpoline like constructs so far. The LLVM side is pretty simple. I'd like to eventually get rid of the old feature, but not sure what backwards compatibility issues that will cause. This does remove the "implies" from requesting an external thunk. This always seemed somewhat questionable and is now clearly not desirable -- you specify a thunk the same way no matter which set of things are getting retpolines. I really want to keep this nicely isolated from end users and just an LLVM implementation detail, so I've moved the `-mretpoline` flag in Clang to no longer rely on a specific subtarget feature by that name and instead to be directly handled. In some ways this is simpler, but in order to preserve existing behavior I've had to add some fallback code so that users who relied on merely passing -mretpoline-external-thunk continue to get the same behavior. We should eventually remove this I suspect (we have never tested that it works!) but I've not done that in this patch. Differential Revision: https://reviews.llvm.org/D51150 llvm-svn: 340515
* [X86] Improved sched models for X86 XCHG*rr and XADD*rr instructions.Andrew V. Tischenko2018-08-091-2/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D49861 llvm-svn: 339321
* [X86] Improved sched models for X86 BT*rr instructions.Andrew V. Tischenko2018-08-011-8/+8
| | | | | | Differential Revision: https://reviews.llvm.org/D49243 llvm-svn: 338507
* Revert r338365: [X86] Improved sched models for X86 BT*rr instructions.Simon Pilgrim2018-07-311-8/+8
| | | | | | | | https://reviews.llvm.org/D49243 Contains WIP code that should not have been included. llvm-svn: 338369
* [X86] Improved sched models for X86 BT*rr instructions.Andrew V. Tischenko2018-07-311-8/+8
| | | | | | https://reviews.llvm.org/D49243 llvm-svn: 338365
* Improved sched model for X86 BSWAP* instrs.Andrew V. Tischenko2018-07-201-1/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D49477 llvm-svn: 337537
* [X86] Prefer MOVSS/SD over BLEND under optsize in isel.Craig Topper2018-07-131-0/+2
| | | | | | Previously we iseled to blend, commuted to another blend, and then commuted back to movss/movsd or blend depending on optsize. Now we do it directly. llvm-svn: 336976
* [X86][Basically NFC] Sched: split WriteBitScan into WriteBSF/WriteBSR.Roman Lebedev2018-07-081-12/+12
| | | | | | | | | | | | | | | | | | Summary: Motivation: {F6597954} This only does the mechanical splitting, does not actually change any numbers, as the tests added in previous revision show. Reviewers: craig.topper, RKSimon, courbet Reviewed By: craig.topper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D48998 llvm-svn: 336511
* [X86] Don't use aligned load/store instructions for fp128 if the load/store ↵Craig Topper2018-07-021-0/+9
| | | | | | | | | | isn't aligned. Similarily, don't fold fp128 loads into SSE instructions if the load isn't aligned. Unless we're targeting an AMD CPU that doesn't check alignment on arithmetic instructions. Should fix PR38001 llvm-svn: 336121
* [X86] Add sched class WriteLAHFSAHF and fix values.Clement Courbet2018-06-201-4/+4
| | | | | | | | | | | | | | | Summary: I ran llvm-exegesis on SKX, SKL, BDW, HSW, SNB. Atom is from Agner and SLM is a guess. I've left AMD processors alone. Reviewers: RKSimon, craig.topper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D48079 llvm-svn: 335097
* [X86] Add '.s' aliases to the assembler for the various redundant move ↵Craig Topper2018-06-181-0/+18
| | | | | | | | | | encodings to match gas and our EVEX instructions. We already have these aliases for EVEX enocded instructions, but not for the GPR, MMX, SSE, and VEX versions. Also remove the vpextrw.s EVEX alias. That's not something gas implements. llvm-svn: 334922
* [X86] Hide POP16/32/64rmr and PUSH16/32/64rmr instructions from the assembly ↵Craig Topper2018-06-161-0/+12
| | | | | | | | parser. These all have a short form encoding that the assembler already prefers. Though that preference seems to only be based on order in the .td fie. Hiding the long form saves space in the table and prevents us from breaking the implicit order based priority. llvm-svn: 334897
* [X86] Add NotMemoryFoldable to more instructions.Craig Topper2018-06-121-14/+22
| | | | | | These include PUSH/POP instructions that don't match the manual table. This also includes CMPXCHG which we never emit in non-locked form. llvm-svn: 334479
* [X86] Add NotMemoryFoldable to a bunch of instructions to suppress them from ↵Craig Topper2018-06-121-10/+10
| | | | | | | | | | 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] Miscellaneous fixes to get the load folding table generator to work again.Craig Topper2018-06-101-5/+5
| | | | llvm-svn: 334377
* [X86] Emit BZHI when mask is ~(-1 << nbits))Roman Lebedev2018-06-061-13/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In D47428, i propose to choose the `~(-(1 << nbits))` as the canonical form of low-bit-mask formation. As it is seen from these tests, there is a reason for that. AArch64 currently better handles `~(-(1 << nbits))`, but not the more traditional `(1 << nbits) - 1` (sic!). The other way around for X86. It would be much better to canonicalize. This patch is completely monkey-typing. I don't really understand how this works :) I have based it on `// x & (-1 >> (32 - y))` pattern. Also, when we only have `BMI`, i wonder if we could use `BEXTR` with `start=0` ? Related links: https://bugs.llvm.org/show_bug.cgi?id=36419 https://bugs.llvm.org/show_bug.cgi?id=37603 https://bugs.llvm.org/show_bug.cgi?id=37610 https://rise4fun.com/Alive/idM Reviewers: craig.topper, spatel, RKSimon, javed.absar Reviewed By: craig.topper Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D47453 llvm-svn: 334125
* [X86] Rename vy512mem->vy512xmem and vz256xmem->vz256mem.Craig Topper2018-06-061-2/+2
| | | | | | | | | | | The index size is represented by the letter after the 'v'. The number represents the memory size. If an 'x' appears after the number its means the index register can be from VR128X/VR256X instead of VR128/VR256. As vy512mem uses a VR256X index it should have an x. And vz256mem uses a VR512 index so it shouldn't have an x. I admit these names kind of suck and are confusing. llvm-svn: 334120
* [X86][BMI][TBM] Only demand bottom 16-bits of the BEXTR control op (PR34042)Simon Pilgrim2018-06-061-26/+44
| | | | | | | | Only the bottom 16-bits of BEXTR's control op are required (0:8 INDEX, 15:8 LENGTH). Differential Revision: https://reviews.llvm.org/D47690 llvm-svn: 334083
* [X86] Don't hardcode scheduler classSimon Pilgrim2018-05-271-21/+24
| | | | | | Also fixes BEXTRI instruction to use WritBEXTR class, which was missed when the class was added. llvm-svn: 333360
* [x86] invpcid LLVM intrinsicGabor Buella2018-05-251-0/+1
| | | | | | | | | | | | | | | 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][MIPS][ARM] New machine instruction property 'isMoveReg'Petar Jovanovic2018-05-231-3/+3
| | | | | | | | | | | | | This property is needed in order to follow values movement between registers. This property is used in TII to implement method that returns true if simple copy like instruction is recognized, along with source and destination machine operands. Patch by Nikola Prica. Differential Revision: https://reviews.llvm.org/D45204 llvm-svn: 333093
* [X86][CET] Changing -fcf-protection behavior to comply with gcc (LLVM part)Alexander Ivchenko2018-05-181-1/+0
| | | | | | | | | | | | | | | | | | | | 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-0/+1
| | | | | | | | | | Reviewers: craig.topper, RKSimon Reviewed By: craig.topper, RKSimon Differential Revision: https://reviews.llvm.org/D46539 llvm-svn: 331961
* [x86] Introduce the enclv instructionGabor Buella2018-05-081-0/+1
| | | | | | | | | | | | | | Summary: and use the -msgx flag as a requirement for the SGX instructions. Reviewers: craig.topper, zvi Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D46436 llvm-svn: 331742
* [x86] Introduce the pconfig instructionGabor Buella2018-05-081-0/+1
| | | | | | | | | | Reviewers: craig.topper, zvi Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D46430 llvm-svn: 331739
* [X86] movdiri and movdir64b instructionsGabor Buella2018-05-011-0/+33
| | | | | | | | | | Reviewers: spatel, craig.topper, RKSimon Reviewed By: craig.topper, RKSimon Differential Revision: https://reviews.llvm.org/D45983 llvm-svn: 331248
* [X86] Remove 'opaque ptr' from the intel syntax parser and printer.Craig Topper2018-05-011-8/+7
| | | | | | | | 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] Remove some InstAliases aren't needed because a MnemonicAlias makes ↵Craig Topper2018-04-301-3/+0
| | | | | | them unreachable. llvm-svn: 331159
* [X86] Use a MnemonicAlias instead of an InstAlias.Craig Topper2018-04-301-0/+8
| | | | llvm-svn: 331157
* [X86] Remove support for accepting 'fnstsw %eax' and 'fnstsw %al'.Craig Topper2018-04-301-4/+1
| | | | | | I assume this was done because gas accepted it at one point, but current versions of gas don't. llvm-svn: 331154
* [X86] Mark some more InstAliases as 'att' syntax only.Craig Topper2018-04-301-6/+6
| | | | | | These aliases are used to default the memory forms of call and jmp to the size of the operating mode. This doesn't work for Intel syntax. We have a different hack in the AsmParser code itself to force a size on unsized memory operands. llvm-svn: 331153
* [X86] Remove unnecessary InstAliases. NFCICraig Topper2018-04-291-6/+0
| | | | | | These used to disambiguate MOV16ms/MOV16sm from other size instructions that no longer exist. llvm-svn: 331134
* [X86] Restrict many of the InstAliases to either to only att or intel ↵Craig Topper2018-04-281-43/+43
| | | | | | | | | | | | syntax. NFCI Many of these aliases exist to give one syntax or the other a slightly different mnemonic and the other variant gets a duplicate of its normal mnemonic This patch restricts a lot of these to only one variant so we don't get the duplication. This removes a lot of duplicate entries from the matcher table. It also reduces the number of warnings printed when you enable the ambiguous match warning in tablegen. llvm-svn: 331117
* [X86] Add a BSWAP16 instruction using the 32-bit encoding plus a 0x66 prefix.Craig Topper2018-04-241-2/+6
| | | | | | This encoding is recognized by the CPU, but the behavior is undefined. This makes the disassembler handle it correctly so we don't print bswapl with a 16-bit register. llvm-svn: 330682
* [X86] Revert r330638 - accidental commitGabor Buella2018-04-231-5/+0
| | | | llvm-svn: 330640
* [X86] movdiri and movdir64b instructionsGabor Buella2018-04-231-0/+5
| | | | | Reviewers: craig.topper llvm-svn: 330638
OpenPOWER on IntegriCloud