When breaking up loads and stores of aggregates, the IRTranslator uses
LLT::scalar(64) for the index type of the G_GEP instructions that
compute the addresses. This is unnecessarily large for 32-bit targets.
Use the int ptr type provided by the DataLayout instead.
Note that we're already doing the right thing when translating
getelementptr instructions from the IR. This is just an oversight when
generating new ones while translating loads/stores.
Both x86 and AArch64 already have tests confirming that the old
behaviour is preserved for 64-bit targets.
Differential Revision: https://reviews.llvm.org/D61852
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360656 91177308-0d34-0410-b5e6-96231b3b80d8
This is a follow on to D58632, with the same logic. Given a memory operation which needs ordering, but doesn't need to modify any particular address, prefer to use a locked stack op over an mfence.
Differential Revision: https://reviews.llvm.org/D61863
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360649 91177308-0d34-0410-b5e6-96231b3b80d8
X32 can refer to a 64-bit ABI that uses 32-bit ints, longs, and pointers.
I plan to add gnux32 command lines to this test so this prepares for that.
Also remove some check lines that have a prefix that is not in any run lines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360642 91177308-0d34-0410-b5e6-96231b3b80d8
This follows the pattern of the existing isCommutativeBinOp().
x86 shows improvements from vector narrowing for the min/max opcodes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360639 91177308-0d34-0410-b5e6-96231b3b80d8
Usually this will abort fast-isel at the instruction using the
non-legal result, but if the only use is in a different basic block,
we'll incorrectly assume that the zext/sext is to i32 (rather than
i128 in this case).
Differential Revision: https://reviews.llvm.org/D61823
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360616 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
X86TargetLowering::LowerAsmOperandForConstraint had better support than
TargetLowering::LowerAsmOperandForConstraint for arbitrary depth
getelementpointers for "i", "n", and "s" extended inline assembly
constraints. Hoist its support from the derived class into the base
class.
Link: https://github.com/ClangBuiltLinux/linux/issues/469
Reviewers: echristo, t.p.northover
Reviewed By: t.p.northover
Subscribers: t.p.northover, E5ten, kees, jyknight, nemanjai, javed.absar, eraman, hiraditya, jsji, llvm-commits, void, craig.topper, nathanchance, srhines
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61560
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360604 91177308-0d34-0410-b5e6-96231b3b80d8
Now that we can use HADD/SUB for scalar additions from any pair of extracted elements (D61263), we can relax the one use limit as we will be able to merge multiple uses into using the same HADD/SUB op.
This exposes a couple of missed opportunities in LowerBuildVectorv4x32 which will be committed separately.
Differential Revision: https://reviews.llvm.org/D61782
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360594 91177308-0d34-0410-b5e6-96231b3b80d8
We catch most of these patterns (on x86 at least) by matching
a concat vectors opcode early in combining, but the pattern may
emerge later using insert subvector instead.
The AVX1 diffs for add/sub overflow show another missed narrowing
pattern. That one may be falling though the cracks because of
combine ordering and multiple uses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360585 91177308-0d34-0410-b5e6-96231b3b80d8
The new fptrunc and fpext intrinsics are constrained versions of the
regular fptrunc and fpext instructions.
Reviewed by: Andrew Kaylor, Craig Topper, Cameron McInally, Conner Abbot
Approved by: Craig Topper
Differential Revision: https://reviews.llvm.org/D55897
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360581 91177308-0d34-0410-b5e6-96231b3b80d8
This adds the FPC (floating-point control register) as a reserved
physical register and models its use by SystemZ instructions.
Note that only the current rounding modes and the IEEE exception
masks are modeled. *Changes* of the FPC due to exceptions (in
particular the IEEE exception flags and the DXC) are not modeled.
At this point, this patch is mostly NFC, but it will prevent
scheduling of floating-point instructions across SPFC/LFPC etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360570 91177308-0d34-0410-b5e6-96231b3b80d8
When deciding the safety of generating smlad, we checked for any
writes within the block that may alias with any of the loads that
need to be widened. This is overly conservative because it only
matters when there's a potential aliasing write to a location
accessed by a pair of loads.
Now we check for aliasing writes only once, during setup. If two
loads are found to have an aliasing write between them, we don't add
these loads to LoadPairs. This means that later during the transform,
we can safely widened a pair without worrying about aliasing.
However, to maintain correctness, we also need to change the way that
wide loads are inserted because the order is now important.
The MatchSMLAD method has also been changed, absorbing
MatchReductions and AddMACCandidate to hopefully improve readability.
Differential Revision: https://reviews.llvm.org/D6102
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360567 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
When we know for sure whether two addresses do or do not alias, we
should immediately return from DAGCombiner::isAlias().
I think this comes from a bad copy/paste, Sorry for not catching that during the
code review.
Fixes PR41855.
Reviewers: niravd, gchatelet, EricWF
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61846
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360566 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, without -g, BTF sections may still be emitted with
data sections, e.g., for linux kernel bpf selftest
test_tcp_check_syncookie_kern.c issue discovered by Martin
as shown below.
-bash-4.4$ bpftool btf dump file test_tcp_check_syncookie_kern.o
[1] VAR 'results' type_id=0, linkage=global-alloc
[2] VAR '_license' type_id=0, linkage=global-alloc
[3] DATASEC 'license' size=0 vlen=1
type_id=2 offset=0 size=4
[4] DATASEC 'maps' size=0 vlen=1
type_id=1 offset=0 size=28
Let disable BTF generation if no debuginfo, which is
the original design.
Signed-off-by: Yonghong Song <yhs@fb.com>
Differential Revision: https://reviews.llvm.org/D61826
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360556 91177308-0d34-0410-b5e6-96231b3b80d8
I've included a new fix in X86RegisterInfo to prevent PR41619 without
reintroducing r359392. We might be able to improve that in the base class
implementation of shouldRewriteCopySrc somehow. But this hopefully enables
forward progress on SimplifyDemandedBits improvements for now.
Original commit message:
This patch adds support for BigBitWidth -> SmallBitWidth bitcasts, splitting the DemandedBits/Elts accordingly.
The AMDGPU backend needed an extra (srl (and x, c1 << c2), c2) -> (and (srl(x, c2), c1) combine to encourage BFE creation, I investigated putting this in DAGComb
but it caused a lot of noise on other targets - some improvements, some regressions.
The X86 changes are all definite wins.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360552 91177308-0d34-0410-b5e6-96231b3b80d8
I noticed that we were failing to narrow an x86 ymm math op in a case similar
to the 'madd' test diff. That is because a bitcast is sitting between the math
and the extract subvector and thwarting our pattern matching for narrowing:
t56: v8i32 = add t59, t58
t68: v4i64 = bitcast t56
t73: v2i64 = extract_subvector t68, Constant:i64<2>
t96: v4i32 = bitcast t73
There are a few wins and neutral diffs in the other tests.
Differential Revision: https://reviews.llvm.org/D61806
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360541 91177308-0d34-0410-b5e6-96231b3b80d8
See if we can simplify the demanded vector elts from the extraction before trying to simplify the demanded bits.
This helps us with target shuffles and hops in particular.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360535 91177308-0d34-0410-b5e6-96231b3b80d8
Fast isel picks the FR32X/FR64X register classes when lowering pseudo select, but it didn't have the right opcode to go with it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360524 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Skip over prefetches when assigning debug info to instructions with memory operands. This way, the debug info is stable after instrumenting a binary with prefetches, allowing for iterative profiling and instrumentation.
Reviewers: davidxl
Reviewed By: davidxl
Subscribers: aprantl, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61789
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360471 91177308-0d34-0410-b5e6-96231b3b80d8
Split out from D61692 per RKSimon's suggestion. Vector op
legalization will automatically recursively legalize the returned
SDValue, but we need to take care of the other results ourselves.
Otherwise it will end up getting legalized only during op
legalization, by which point it might be too late (though I'm not
aware of any specific cases right now).
There are codegen differences because expansion occurs earlier now
and we don't get a DAGCombiner run in between.
Differential Revision: https://reviews.llvm.org/D61744
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360470 91177308-0d34-0410-b5e6-96231b3b80d8
This fix allows the scheduler to take into account the number of instances of
each ProcResource specified. Previously a declaration in a scheduler of
ProcResource<1> would be treated identically to a declaration of
ProcResource<2>. Now the hazard recognizer would report a hazard only after all
of the resource instances are busy.
Patch by Jackson Woodruff and Momchil Velikov.
Differential Revision: https://reviews.llvm.org/D51160
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360441 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes https://bugs.llvm.org/show_bug.cgi?id=40969
The functions findPotentiallyBlockedCopies and buildCopy are currently not
accounting for the presence of debug instructions. In the former this results
in the optimization not being trigerred, and in the latter results in
inconsistent codegen.
This patch enables the optimization to be performed in a debug build and
ensures the codegen is consistent with non-debug builds.
Patch by Chris Dawson.
Differential Revision: https://reviews.llvm.org/D61680
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360436 91177308-0d34-0410-b5e6-96231b3b80d8
If we only use the lower xmm of a ymm hop, then extract the xmm's (for free), perform the xmm hop and then insert back into a ymm (for free).
Fixes some of the regressions noted in D61782
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360435 91177308-0d34-0410-b5e6-96231b3b80d8
We were applying a pointer truncation to floating types, which crashed LLVM.
That is Not A Good Thing(TM).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360421 91177308-0d34-0410-b5e6-96231b3b80d8
The current PIC model for WebAssembly is more like ELF in that it
allows symbol interposition.
This means that more functions end up being addressed via the GOT
and fewer directly added to the wasm table.
One effect is a reduction in the number of wasm table entries similar
to the previous attempt in https://reviews.llvm.org/D61539 which was
reverted.
Differential Revision: https://reviews.llvm.org/D61772
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360402 91177308-0d34-0410-b5e6-96231b3b80d8
The current lowering uses an mfence. mfences are substaintially higher latency than the locked operations originally requested, but we do want to avoid contention on the original cache line. As such, use a locked instruction on a cache line assumed to be thread local.
Differential Revision: https://reviews.llvm.org/D58632
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360393 91177308-0d34-0410-b5e6-96231b3b80d8
As reported on PR39920, "slow horizontal ops" targets tend to internally expand to 2*shuffle+add/sub - so if we can reduce 2*shuffle+add/sub to a hadd/sub then we should do it - similar port usage but reduced instruction count.
This works out in most cases, although the "PR22377" regression in vector-shuffle-combining.ll is annoying - going from 2*shuffle+add+shuffle to hadd+2*shuffle - I've opened PR41813 to cover this.
Differential Revision: https://reviews.llvm.org/D61308
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360360 91177308-0d34-0410-b5e6-96231b3b80d8
Add an Argument that has the SExtAttr attached, as well as SIToFP
instructions, as values that generate sign bits. SIToFP doesn't
strictly do this and could be treated as a sink to be sign-extended.
Differential Revision: https://reviews.llvm.org/D61381
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360331 91177308-0d34-0410-b5e6-96231b3b80d8
Diana Picus