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
Summary:
For a given loop, getLoopLatch returns a non-null value
when a loop has only one latch block. In the modified
context a check on both the outgoing branches of a terminator instruction (of latch) to same header is redundant.
Reviewers: jbhateja
Reviewed By: jbhateja
Subscribers: sanjoy
Differential Revision: https://reviews.llvm.org/D40460
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318991 91177308-0d34-0410-b5e6-96231b3b80d8
(this header is not fully implemented (the out of line function
writeTypeRecordKind is called in an inline function but never
implemented - this fails to link under modular code generation) and not
included anywhere)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318987 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
These instructions zero the non-scalar part of the lower 128-bits which makes them different than the FMA3 instructions which pass through the non-scalar part of the lower 128-bits.
I've only added fmadd because we should be able to derive all other variants using operand negation in the intrinsic header like we do for AVX512.
I think there are still some missed negate folding opportunities with the FMA4 instructions in light of this behavior difference that I hadn't noticed before.
I've split the tests so that we can use different intrinsics for scalar testing between the two. I just copied the tests split the RUN lines and changed out the scalar intrinsics.
fma4-fneg-combine.ll is a new test to make sure we negate the fma4 intrinsics correctly though there are a couple TODOs in it.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39851
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318984 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This adds a new fast gather feature bit to cover all CPUs that support fast gather that we can use independent of whether the AVX512 feature is enabled. I'm only using this new bit to qualify AVX2 codegen. AVX512 is still implicitly assuming fast gather to keep tests working and to match the scatter behavior.
Test command lines have been added for these two cases.
Reviewers: magabari, delena, RKSimon, zvi
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40282
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318983 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Currently ScalarizeVecRes_SETCC checks for the result type being a vector and jumps to ScalarizeVecRes_VSETCC. But if we're scalarizing a vector result, aren't we guaranteed to be looking at a vector type?
This patch deletes the current ScalarizeVecRes_SETCC and renames ScalarizeVecRes_VSETCC to ScalarizeVecRes_SETCC.
Reviewers: RKSimon, arsenm, eladcohen, zvi
Reviewed By: RKSimon
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D40452
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318982 91177308-0d34-0410-b5e6-96231b3b80d8
Other checks inside require a build_vector, but we this lets us stop earlier and makes the code more clear.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318969 91177308-0d34-0410-b5e6-96231b3b80d8
v4i32 isn't a legal type with sse1 only and would end up getting scalarized otherwise.
This isn't completely ideal as it doesn't handle cases like v8i32 that would get split to v4i32. But it at least helps with code written using the clang intrinsic header.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318967 91177308-0d34-0410-b5e6-96231b3b80d8
The previous commit had the condition in the do/while backwards.
Debug builds currently print out low level details of the Knuth division algorithm when -debug is used. This information isn't useful in most cases and just adds noise to the log.
This adds a new preprocessor flag to enable the prints in the knuth division code in APInt.
Differential Revision: https://reviews.llvm.org/D40404
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318966 91177308-0d34-0410-b5e6-96231b3b80d8
This optimization can occur after type legalization and emit a vselect with v4i32 type. But that type is not legal with sse1. This ultimately gets scalarized by the second type legalization that runs after vector op legalization, but that's really intended to handle the scalar types that might be introduced by legalizing vector ops.
For now just stop this from happening by disabling the optimization with sse1.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318965 91177308-0d34-0410-b5e6-96231b3b80d8
Debug builds currently print out low level details of the Knuth division algorithm when -debug is used. This information isn't useful in most cases and just adds noise to the log.
This adds a new preprocessor flag to enable the prints in the knuth division code in APInt.
Differential Revision: https://reviews.llvm.org/D40404
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318963 91177308-0d34-0410-b5e6-96231b3b80d8
CodeGenPrepare sinks address computations from one basic block to another
and attempts to reuse address computations that have already been sunk. If
the same address computation appears twice with the first instance as an
operand of a load whose result is an operand to a simplifable select,
CodeGenPrepare simplifies the select and recursively erases the now dead
instructions. CodeGenPrepare then attempts to use the erased address
computation for the second load.
Fix this by erasing the cached address value if it has zero uses before
looking for the address value in the sunken address map.
This partially resolves PR35209.
Thanks to Alexander Richardson for reporting the issue!
This fixed version relands r318032 which was reverted in r318049 due to
sanitizer buildbot failures.
Reviewers: john.brawn
Differential Revision: https://reviews.llvm.org/D39841
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318956 91177308-0d34-0410-b5e6-96231b3b80d8
This patch extends the recent work in optimizeMemoryInst to make it able to
combine more ExtAddrMode fields than just the BaseReg.
This fixes some benchmark regressions introduced by r309397, where GVN PRE is
hoisting a getelementptr such that it can no longer be combined into the
addressing mode of the load or store that uses it.
Differential Revision: https://reviews.llvm.org/D38133
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318949 91177308-0d34-0410-b5e6-96231b3b80d8
The NewCC variable is calculated outside of the loop that processes jcc/setcc/cmovcc instructions. If we invert it during the loop it can cause an incorrect value to be used by a later iteration. Instead only read it during the loop and use a new variable to store the possibly inverted value.
Fixes PR35399.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318934 91177308-0d34-0410-b5e6-96231b3b80d8
A later DAG combine will turn the VSELECT into an AND, but we have the other mask compare opcodes here so add this one too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318931 91177308-0d34-0410-b5e6-96231b3b80d8
(V)PHMINPOSUW determines the UMIN element in an v8i16 input, with suitable bit flipping it can also be used for SMAX/SMIN/UMAX cases as well.
This patch matches vXi16 SMAX/SMIN/UMAX/UMIN horizontal reductions and reduces the input down to a v8i16 vector before calling (V)PHMINPOSUW.
A later patch will use this for v16i8 reductions as well (PR32841).
Differential Revision: https://reviews.llvm.org/D39729
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318917 91177308-0d34-0410-b5e6-96231b3b80d8
TableGen already generates code for selecting a G_FDIV, so we only need
to add a test.
For the legalizer and reg bank select, we do the same thing as for the
other floating point binary operations: either mark as legal if we have
a FP unit or lower to a libcall, and map to the floating point
registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318915 91177308-0d34-0410-b5e6-96231b3b80d8
TableGen already generates code for selecting a G_FMUL, so we only need
to add a test for that part.
For the legalizer and reg bank select, we do the same thing as the other
floating point binary operators: either mark as legal if we have a FP
unit or lower to a libcall, and map to the floating point registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318910 91177308-0d34-0410-b5e6-96231b3b80d8
The MIPS delay slot filler converts delay slot branches into compact
forms for the MIPS ISAs which support them. For branches that compare
(in)equality with with zero, it converts them into branches with implict
zero register operands. These branches have a slightly greater range
than normal two register operands branches.
Changing the branches at this point in the pipeline offers the long
branch pass the ability to mark better judgements if a long branch
sequence is required.
Reviewers: atanasyan
Differential Revision: https://reviews.llvm.org/D40314
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318908 91177308-0d34-0410-b5e6-96231b3b80d8
MSan used to insert the shadow check of the store pointer operand
_after_ the shadow of the value operand has been written.
This happens to work in the userspace, as the whole shadow range is
always mapped. However in the kernel the shadow page may not exist, so
the bug may cause a crash.
This patch moves the address check in front of the shadow access.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318901 91177308-0d34-0410-b5e6-96231b3b80d8
If Values.size() == 0, we should have returned 0 or undef earlier. If it was 1, it's a splat and we already handled that too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318894 91177308-0d34-0410-b5e6-96231b3b80d8
256 and 512 bit vectors were picked off earlier in the function. Lots of code between there and here already assumed 128-bit vectors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318893 91177308-0d34-0410-b5e6-96231b3b80d8
This patch reverts change to X86TargetLowering::getScalarShiftAmountTy in
rL318727 and move the logic to DAGTypeLegalizer::SplitInteger.
The reason is that getScalarShiftAmountTy returns a shift amount type that
is suitable for common use cases in CodeGen. DAGTypeLegalizer::SplitInteger
is a rare situation which requires a shift amount type larger than what
getScalarShiftAmountTy. In this case, it is more reasonable to do special
handling of shift amount type in DAGTypeLegalizer::SplitInteger only. If
similar situations arises the logic may be moved to a separate function.
Differential Revision: https://reviews.llvm.org/D40320
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318890 91177308-0d34-0410-b5e6-96231b3b80d8
