Add registers still missing after r328016 (D43353):
- for bits 15-8 of SI, DI, BP, SP (*H), and R8-R15 (*BH),
- for bits 31-16 of R8-R15 (*WH).
Thanks to Craig Topper for pointing it out.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@336134 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@336121 91177308-0d34-0410-b5e6-96231b3b80d8
We were only doing this for basic blends, despite shuffle lowering now being good enough to handle more complex blends. This means that the two v8i16 splat shifts are performed in parallel instead of serially as the general shift case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@336113 91177308-0d34-0410-b5e6-96231b3b80d8
The X86 asm parser currently has custom parsing logic for .word. Rather than
use this custom logic, we can just use addAliasForDirective to enable the
reuse of AsmParser::parseDirectiveValue.
See also similar changes to Sparc (rL333078), AArch64 (rL333077), and Hexagon
(rL332607) backends.
Differential Revision: https://reviews.llvm.org/D47004
This is a fixed reland of rL336100. This should have been caught in
pre-commit testing so apologies for the noise.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@336104 91177308-0d34-0410-b5e6-96231b3b80d8
The X86 asm parser currently has custom parsing logic for .word. Rather than
use this custom logic, we can just use addAliasForDirective to enable the
reuse of AsmParser::parseDirectiveValue.
See also similar changes to Sparc (rL333078), AArch64 (rL333077), and Hexagon
(rL332607) backends.
Differential Revision: https://reviews.llvm.org/D47004
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@336100 91177308-0d34-0410-b5e6-96231b3b80d8
We don't have PMCs to cover many of the Jaguar resources but we can at least monitor the FPU issue pipes which give an indication of the fpu uop count, just not the execution resources.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@336089 91177308-0d34-0410-b5e6-96231b3b80d8
It looks like someone ran clang-format over this entire file which reformatted these switches into a multiline form. But I think the single line form is more useful here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@336077 91177308-0d34-0410-b5e6-96231b3b80d8
I separated out the rounding and broadcast groups into their own tables because it made the ordering in the main table easier.
Further splitting of the tables might make it possible to directly index using bits from the TSFlags, but its probably not worth it right now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@336075 91177308-0d34-0410-b5e6-96231b3b80d8
findCommutedOpIndices does the pre-checking for whether commuting is possible. There should be no reason left to fail in commuteInstructionImpl. There was a missing pre-check that I've added there and changed the check to an assert in commuteInstructionImpl.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@336070 91177308-0d34-0410-b5e6-96231b3b80d8
I've check the disassembler tables and this shouldn't be reachable. Which is good since if it was reachable there should have been a 'return' after the addOperand line.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@336066 91177308-0d34-0410-b5e6-96231b3b80d8
Also move the static folding tables, their search functions and the new class into new cpp/h files.
The unfolding table is effectively static data. It's just a different ordering and a subset of the static folding tables.
By putting it in a separate ManagedStatic we ensure we only have one copy instead of one per X86InstrInfo object. This way also makes it only get initialized when really needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@336056 91177308-0d34-0410-b5e6-96231b3b80d8
The class only exists to hold a DenseMap and is only created as a ManagedStatic. It used to expose a single static method that outside code was expected to use.
This patch moves that static function out of the class and moves it implementation into the cpp file. It can now access the ManagedStatic directly by name without the need for the other static method that accessed the ManagedStatic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@336055 91177308-0d34-0410-b5e6-96231b3b80d8
There are no instructions that use them so they weren't causing any bad matches. But they weren't being diagnosed as "invalid register name" if they were used and would instead trigger some form of invalid operand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@336054 91177308-0d34-0410-b5e6-96231b3b80d8
I believe all of these are constants so legalizing them should be pretty trivial, but this saves a step.
In one case it looks like we may have been creating a shift amount larger than the shift input itself.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@336052 91177308-0d34-0410-b5e6-96231b3b80d8
This combine runs pretty late and causes us to introduce a shift after the op legalization phase has run. We need to be sure we create the shift with the proper type for the shift amount. If we don't do this, we will still re-legalize the operation properly, but we won't get a chance to fully optimize the truncate that gets inserted.
So this patch adds the necessary truncate when the shift is created. I've also narrowed the subtract that gets created to always be an i32 type. The truncate would have trigered SimplifyDemandedBits to optimize it anyway. But using a more appropriate VT here is free and saves an optimization step.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@336051 91177308-0d34-0410-b5e6-96231b3b80d8
The important part is the creation of the SHLD/SHRD nodes. The compare and the conditional move can use target independent nodes that can be legalized on their own. This gives some opportunities to trigger the optimizations present in the lowering for those things. And its just better to limit the number of places we emit target specific nodes.
The changed test cases still aren't optimal.
Differential Revision: https://reviews.llvm.org/D48619
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335998 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we used a DenseMap which is costly to set up due to multiple full table rehashes as the size increases and causes the table to be reallocated.
This patch changes the table to a vector of structs. We now walk the reg->mem tables and push new entries in the mem->reg table for each row not marked TB_NO_REVERSE. Once all the table entries have been created, we sort the vector. Then we can use a binary search for lookups.
Differential Revision: https://reviews.llvm.org/D48585
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335994 91177308-0d34-0410-b5e6-96231b3b80d8
This uses the same technique as for shifts - split the rotation into 4/2/1-bit partial rotations and select those partials based on the amount bit, making use of PBLENDVB if available. This halves the use of PBLENDVB compared to expanding to shifts, which can be a slow op.
Unfortunately I haven't found a decent way to share much of this code with the shift equivalent.
Differential Revision: https://reviews.llvm.org/D48655
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335957 91177308-0d34-0410-b5e6-96231b3b80d8
Reverting because this is causing failures in the LLDB test suite on
GreenDragon.
LLVM ERROR: unsupported relocation with subtraction expression, symbol
'__GLOBAL_OFFSET_TABLE_' can not be undefined in a subtraction
expression
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335894 91177308-0d34-0410-b5e6-96231b3b80d8
Targets should be able to define whether or not they support the outliner
without the outliner being added to the pass pipeline. Before this, the
outliner pass would be added, and ask the target whether or not it supports the
outliner.
After this, it's possible to query the target in TargetPassConfig, before the
outliner pass is created. This ensures that passing -enable-machine-outliner
will not modify the pass pipeline of any target that does not support it.
https://reviews.llvm.org/D48683
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335887 91177308-0d34-0410-b5e6-96231b3b80d8
Add NoTrapAfterNoreturn target option which skips emission of traps
behind noreturn calls even if TrapUnreachable is enabled.
Enable the feature on Mach-O to save code size; Comments suggest it is
not possible to enable it for the other users of TrapUnreachable.
rdar://41530228
DifferentialRevision: https://reviews.llvm.org/D48674
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335877 91177308-0d34-0410-b5e6-96231b3b80d8
These are all benign races and only visible in !NDEBUG. tsan complains
about it, but a simple atomic bool is sufficient to make it happy.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335823 91177308-0d34-0410-b5e6-96231b3b80d8
This more efficient for the isel table generator since we can use CheckChildInteger instead of MoveChild, CheckPredicate, MoveParent. This reduced the table size by 1-2K.
I wish there was a way to share the values with X86BaseInfo.h and still use a PatFrag like this. These numbers are fixed by the X86 intrinsic spec going back many years and we should never need to change them. So we shouldn't waste table bytes to support sharing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335806 91177308-0d34-0410-b5e6-96231b3b80d8
BMI2 added new shift by register instructions that have the ability to fold a load.
Normally without doing anything special isel would prefer folding a load over folding an immediate because the load folding pattern has higher "complexity". This would require an instruction to move the immediate into a register. We would rather fold the immediate instead and have a separate instruction for the load.
We used to enforce this priority by artificially lowering the complexity of the load pattern.
This patch changes this to instead reject the load fold in isProfitableToFoldLoad if there is an immediate. This is more consistent with other binops and feels less hacky.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335804 91177308-0d34-0410-b5e6-96231b3b80d8
If we turn X86ISD::AND into ISD::AND, we delete N. But we were continuing onto the next block of code even though N no longer existed.
Just happened to notice it. I assume asan didn't notice it because we explicitly unpoison deleted nodes and give them a DELETE_NODE opcode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335787 91177308-0d34-0410-b5e6-96231b3b80d8
The %eiz/%riz are dummy registers that force the encoder to emit a SIB byte when it normally wouldn't. By emitting them in the disassembly output we ensure that assembling the disassembler output would also produce a SIB byte.
This should match the behavior of objdump from binutils.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335768 91177308-0d34-0410-b5e6-96231b3b80d8
If we are just modifying a single bit at a variable bit position we can use the BT* instructions to make the change instead of shifting a 1(or rotating a -1) and doing a binop. These instruction also ignore the upper bits of their index input so we can also remove an and if one is present on the index.
Fixes PR37938.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335754 91177308-0d34-0410-b5e6-96231b3b80d8
I think the intrinsics named 'avx512.mask.' should refer to the previous behavior of taking a mask argument in the intrinsic instead of using a 'select' or 'and' instruction in IR to accomplish the masking. This is more consistent with the goal that eventually we will have no intrinsics that have masking builtin. When we reach that goal, we should have no intrinsics named "avx512.mask".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335744 91177308-0d34-0410-b5e6-96231b3b80d8
Nothing was using this relationship. By splitting them we no longer need to worry about register or memory entries being empty in a group.
The memory folding tables in X86InstrInfo.cpp can be used to access this relationship if needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335694 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 4850a9aae8b38c7deadc103d634ec7397e6c323b.
It caused MC/X86/x86_errors.s to fail. Will fix and recommit shortly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335660 91177308-0d34-0410-b5e6-96231b3b80d8
Right now, when we use RIP-relative instructions in 32-bit mode, we'll just
assert and crash.
This adds an error message which tells the user that they can't do that in
32-bit mode, so that we don't crash (and also can see the issue outside of
assert builds).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335658 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
If a routine with no stack frame makes a sibling call, we need to
preserve the stack space check even if the local stack frame is empty,
since the call target could be a "no-split" function (in which case
the linker needs to be able to fix up the prolog sequence in order to
switch to a larger stack).
This fixes PR37807.
Reviewers: cherry, javed.absar
Subscribers: srhines, llvm-commits
Differential Revision: https://reviews.llvm.org/D48444
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335604 91177308-0d34-0410-b5e6-96231b3b80d8
These opcodes have a fixed type of i8 for their immediate and shouldn't have anything to do with the scalar shift amount used by target independent shift nodes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335578 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Same idea as D48529, but restricted to X86 and done very late to avoid any surprises where subtract might be better for DAG combining.
This seems like the safest way to do this trick. And we consider doing it as a DAG combine later.
Reviewers: spatel, RKSimon
Reviewed By: spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D48557
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335575 91177308-0d34-0410-b5e6-96231b3b80d8
This recommits r335562 and 335563 as a single commit.
The frontend will surround the intrinsic with the appropriate marshalling to/from a scalar type to match the sigature of the builtin that software expects.
By exposing the vXi1 type directly in the llvm intrinsic we make it available to optimizers much earlier. This can enable the scalar marshalling code to be optimized away.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335568 91177308-0d34-0410-b5e6-96231b3b80d8
std::lower_bound doesn't require the thing to search for to be the same type as the table entries. We just need to define an appropriate comparison function that can take an table entry and an intrinsic number.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335518 91177308-0d34-0410-b5e6-96231b3b80d8
Benjamin Kramer