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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@351636 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337007 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@334474 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@333255 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@332705 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@331243 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@331149 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@331138 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@331135 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@329847 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@329673 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@322910 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320846 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320843 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320830 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318996 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@316337 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@300190 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278144 91177308-0d34-0410-b5e6-96231b3b80d8
Their opcodes are used as part of the VEX prefix in 64-bit mode. Clearly the disassembler implicitly decoded them as AVX instructions in 64-bit mode, but I think the AsmParser would have encoded them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258793 91177308-0d34-0410-b5e6-96231b3b80d8
Chandler Carruth