The test case is based on the example from the post-commit thread for:
https://reviews.llvm.org/rGc9171bd0a955
This replaces the x86-specific simple-type check from:
rL367766
with a check in the DAGCombiner. Adding the check isn't
strictly necessary after the fix from:
rL367768
...but it seems likely that we're heading for trouble if
we are creating weird types in this transform.
I combined the earlier legality check into the initial
clause to simplify the code.
So we should only try the trunc/sext transform at the
earliest combine stage, but we limit the transform to
simple types anyway because the TLI hook is probably
too lax about what it considers a free truncate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367834 91177308-0d34-0410-b5e6-96231b3b80d8
Adds a two way mapping between the scalable vector IR type and
corresponding SelectionDAG ValueTypes.
Reviewers: craig.topper, jeroen.dobbelaere, fhahn, rengolin, greened, rovka
Reviewed By: greened
Differential Revision: https://reviews.llvm.org/D47770
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367832 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is patch is part of a serie to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Reviewers: courbet, jfb, jakehehrlich
Reviewed By: jfb
Subscribers: wuzish, jholewinski, arsenm, dschuff, nemanjai, jvesely, nhaehnle, javed.absar, sbc100, jgravelle-google, hiraditya, aheejin, kbarton, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, s.egerton, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65514
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367828 91177308-0d34-0410-b5e6-96231b3b80d8
Add an explicit construction of the ArrayRef, gcc 5 and earlier don't
seem to select the ArrayRef constructor which takes a C array when the
construction is implicit.
Original commit message:
- Avoid a crash when IPRA calls ARMFrameLowering::determineCalleeSaves
with a null RegScavenger. Simply not updating the register scavenger
is fine because IPRA only cares about the SavedRegs vector, the acutal
code of the function has already been generated at this point.
- Add a new hook to TargetRegisterInfo to get the set of registers which
can be clobbered inside a call, even if the compiler can see both
sides, by linker-generated code.
Differential revision: https://reviews.llvm.org/D64908
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367819 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The SimplifyDemandedVectorElts function can replace with undef
when no elements are demanded, but due to how it interacts with
TargetLoweringOpts, it can only do this when the node has
no other users.
Remove a now unneeded DAG combine from the X86 backend.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65713
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367788 91177308-0d34-0410-b5e6-96231b3b80d8
This is further fix for PR42880.
Sanjay already disabled the X86 TLI hook for non-simple types,
but we should really call isTypeLegal here if we're after type
legalization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367768 91177308-0d34-0410-b5e6-96231b3b80d8
This is an old commit that exposed a bug in the GISel importer, which caused
non-truncating stores to be selected for truncating store patterns. Now that's
been fixed in r367737 this can go back in.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367739 91177308-0d34-0410-b5e6-96231b3b80d8
Same as what was done for gather/scatter/load/store in r367489.
Expandload/compressstore were delayed due to lack of constant
masking handling that has since been fixed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367738 91177308-0d34-0410-b5e6-96231b3b80d8
Noticed by inspection - this was copied from the X86 target equivalent where we can assume its legal/simple.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367721 91177308-0d34-0410-b5e6-96231b3b80d8
This really should have been part of 366765. For some reason, I forgot to handle the corresponding load side, and the readable test cases (using deopt vs statepoints) turned out to be overly reduced. Oops.
As seen in the test change, the problem was that we were using a load with alignment expectations rather than the unaligned variant when the stack alignment was less than that prefered type alignment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367718 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a crash in the case where the type info object is an alias
pointing to a non-zero offset within a global or is otherwise unanalyzable
by the stripPointerCasts() function. Looking through the alias is not the
right thing to do anyway for similar reasons as D65118.
Differential Revision: https://reviews.llvm.org/D65314
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367696 91177308-0d34-0410-b5e6-96231b3b80d8
This optimisation isn't generally profitable for ARM, because we can
save/restore many registers in the prologue and epilogue using the PUSH
and POP instructions, but mostly use individual LDR/STR instructions for
other spills.
Differential revision: https://reviews.llvm.org/D64910
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367670 91177308-0d34-0410-b5e6-96231b3b80d8
- Avoid a crash when IPRA calls ARMFrameLowering::determineCalleeSaves
with a null RegScavenger. Simply not updating the register scavenger
is fine because IPRA only cares about the SavedRegs vector, the acutal
code of the function has already been generated at this point.
- Add a new hook to TargetRegisterInfo to get the set of registers which
can be clobbered inside a call, even if the compiler can see both
sides, by linker-generated code.
Differential revision: https://reviews.llvm.org/D64908
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367669 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The old code can be simplified to define the element type of TailCalls as `BasicBlock` not `CallInst`. Also I use the for-range loop instead the for loop.
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D64905
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367644 91177308-0d34-0410-b5e6-96231b3b80d8
AMDGPU sometimes has legal s16 and <2 x s16> operations, but all
registers are really 32-bit. An unmerge destination really should ben
widened to a 32-bit register. If widening a scalarizing vector with a
target size that matches the vector size, bitcast to integer and
extract the relevant bits with shifts.
I'm not sure if this is the right place for this. This could arguably
be part of widenScalar for the result. I also have a growing feeling
that we're missing a bitcast legalize action.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367604 91177308-0d34-0410-b5e6-96231b3b80d8
If a type is larger than a legal type and needs to be split, we would previously allow the multiply to be decomposed even if the split multiply is legal. Since the shift + add/sub code would also need to be split, its not any better to decompose it.
This patch figures out what type the mul will eventually be legalized to and then uses that type for the query. I tried just returning false illegal types and letting them get handled after type legalization, but then we can't recognize and i64 constant splat on 32-bit targets since will be destroyed by type legalization. We could special case vectors of i64 to avoid that...
Differential Revision: https://reviews.llvm.org/D65533
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367601 91177308-0d34-0410-b5e6-96231b3b80d8
The note in the documentation suggests this restriction is a compile
time optimization for architectures that make heavy use of
bundling. Allowing virtual registers in a bundle is useful for some
(non-R600) AMDGPU use cases and are infrequent enough to matter.
A more common AMDGPU use case has already been using virtual registers
in bundles since r333691, although never calling finalizeBundle on
them and manually creating the use/def list on the BUNDLE
instruction. This is also relatively infrequent, and only happens for
consecutive sequences of some load/store types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367597 91177308-0d34-0410-b5e6-96231b3b80d8
This allows functions and globals to to be reordered later in the linking phase
(using the -symbol-ordering-file) even though reordering will be limited to
the scope of the explicit section.
Patch by Rahman Lavaee!
Differential Revision: https://reviews.llvm.org/D65478
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367501 91177308-0d34-0410-b5e6-96231b3b80d8
and partial fix.
Causes windows buildbot errors.
This reverts commit 6e65c34523963094acd0d6c94a5f5c64b32fe6aa and
53da7ca94343166ac68aef81db0398932fc258bb.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367496 91177308-0d34-0410-b5e6-96231b3b80d8
X86 at least is able to use movmsk or kmov to move the mask to the scalar
domain. Then we can just use test instructions to test individual bits.
This is more efficient than extracting each mask element
individually.
I special cased v1i1 to use the previous behavior. This avoids
poor type legalization of bitcast of v1i1 to i1.
I've skipped expandload/compressstore as I think we need to
handle constant masks for those better first.
Many tests end up with duplicate test instructions due to tail
duplication in the branch folding pass. But the same thing
happens when constructing similar code in C. So its not unique
to the scalarization.
Not sure if this lowering code will also be good for other targets,
but we're only testing X86 today.
Differential Revision: https://reviews.llvm.org/D65319
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367489 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Honoring no signed zeroes is also available as a user control through clang separately regardless of fastmath or UnsafeFPMath context, DAG guards should reflect this context.
Reviewers: spatel, arsenm, hfinkel, wristow, craig.topper
Reviewed By: spatel
Subscribers: rampitec, foad, nhaehnle, wuzish, nemanjai, jvesely, wdng, javed.absar, MaskRay, jsji
Differential Revision: https://reviews.llvm.org/D65170
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367486 91177308-0d34-0410-b5e6-96231b3b80d8
after windows buildbot failure.
Added a check that the MachineInstr exists and is a call before trying
to add symbols around it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367483 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This will make it possible to improve IPRA by taking into account
register usage in indirect calls.
NFC yet; this is just laying the groundwork to start building
up patches to take advantage of the information for improved register
allocation.
Reviewers: aditya_nandakumar, volkan, qcolombet, arsenm, rovka, aemerson, paquette
Subscribers: sdardis, wdng, javed.absar, hiraditya, jrtc27, atanasyan, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65488
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367476 91177308-0d34-0410-b5e6-96231b3b80d8
This makes the field wider than MachineOperand::SubReg_TargetFlags so that
we don't end up silently truncating any higher bits. We should still catch
any bits truncated from the MachineOperand field as a consequence of the
assertion in MachineOperand::setTargetFlags().
Differential Revision: https://reviews.llvm.org/D65465
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367474 91177308-0d34-0410-b5e6-96231b3b80d8
to bail out in store merging dependence check.
We run into a case where dependence check in store merging bail out many times
for the same store and root nodes in a huge basicblock. That increases compile
time by almost 100x. The patch add a map to track how many times the bailing
out happen for the same store and root, and if it is over a limit, stop
considering the store with the same root as a merging candidate.
Differential Revision: https://reviews.llvm.org/D65174
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367472 91177308-0d34-0410-b5e6-96231b3b80d8
Nilanjana Basu