Some atomic loads are implemented as cmpxchg (particularly if large or
floating), and that usually requires write access to the memory involved
or it will segfault.
We can still propagate the constant value to users we understand though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360662 91177308-0d34-0410-b5e6-96231b3b80d8
.gnu_debuglink section contains information regarding file with
debugging symbols, identified by its CRC32. This target file is not
intended to ever change or it would invalidate the stored checksum, yet
the checksum is calculated over and over again for each of the objects
inside the archive, usually hundreds of times.
This patch precomputes the CRC32 of the target once and then reuses the
value where required, saving lots of redundant I/O.
The error message reported should stay the same, although now it might
be reported earlier.
Reviewed by: jhenderson, jakehehrlich, MaskRay
Differential Revision: https://reviews.llvm.org/D61343
Patch by Michal Janiszewski
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360661 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, the test didn't work because '\' characters appeared in the
sed string, causing bogus escape characters to form in the substituted
string literal. Switching to using '%/p' causes the path to be emitted
with '/' characters instead, so that there are are no escaping issues.
Reviewed by: kzhuravl, grimar
Differential Revision: https://reviews.llvm.org/D61856
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360660 91177308-0d34-0410-b5e6-96231b3b80d8
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
Change
std::error_code getSectionContents(DataRefImpl, StringRef &) const;
to
Expected<ArrayRef<uint8_t>> getSectionContents(DataRefImpl) const;
Many object formats use ArrayRef<uint8_t> as the underlying type, which
is generally better than StringRef to represent binary data, so change
the type to decrease the number of type conversions.
Reviewed By: ruiu, sbc100
Differential Revision: https://reviews.llvm.org/D61781
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360648 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
Summary:
CoroFrame was not considering static array allocas, and was only ever reserving a single element in the coroutine frame.
This meant that stores to the non-zero'th element would corrupt later frame data.
Store static array allocas as field arrays in the coroutine frame.
Added test.
Committed by Gor Nishanov on behalf of ben-clayton
Reviewers: GorNishanov, modocache
Reviewed By: GorNishanov
Subscribers: Orlando, capn, EricWF, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61372
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360636 91177308-0d34-0410-b5e6-96231b3b80d8
Returning SDValue() makes the caller think that nothing happened and it will
end up executing the Expand path. This generates extra nodes that will need to
be pruned as dead code.
Returning an ISD::MERGE_VALUES will tell the caller that we'd like to make a
change and it will take care of replacing uses. This will prevent falling into
the Expand path.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360627 91177308-0d34-0410-b5e6-96231b3b80d8
This patch just adds a test case to show the differences in code emitted
by opt before and after https://reviews.llvm.org/D61726.
Previous attempt to commit this did not include the registered target
requirement so it caused buildbot breaks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360620 91177308-0d34-0410-b5e6-96231b3b80d8
These are updates to match how isel table would emit a LOCK_OR32mi8 node.
-Use i32 for the immediate zero even though only 8 bits are encoded.
-Use i16 for segment register.
-Use LOCK_OR32mi8 for idempotent atomic operations in 32-bit mode to match
64-bit mode. I'm not sure why OR32mi8Locked and LOCK_OR32mi8 both exist. The
only difference seems to be that OR32mi8Locked is marked as UnmodeledSideEffects=1.
-Emit an extra i32 result for the flags output.
I don't know if the types here really matter just noticed it was inconsistent
with normal behavior.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360619 91177308-0d34-0410-b5e6-96231b3b80d8
stdout may be buffered, and may not flush on every write. Explicitly flushing
before redirecting the output ensures that the captured output does not contain
output from other tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360617 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
We have a similar match for patterns ending in a truncate. This
should be ok for all targets because the default expansion would
still likely be better from replacing 2 'and' ops with 1.
Attempt to show the logic equivalence in Alive (which doesn't
currently have funnel-shift in its vocabulary AFAICT):
%shamt = zext i8 %i to i32
%m = and i32 %shamt, 31
%neg = sub i32 0, %shamt
%and4 = and i32 %neg, 31
%shl = shl i32 %v, %m
%shr = lshr i32 %v, %and4
%or = or i32 %shr, %shl
=>
%a = and i8 %i, 31
%shamt2 = zext i8 %a to i32
%neg2 = sub i32 0, %shamt2
%and4 = and i32 %neg2, 31
%shl = shl i32 %v, %shamt2
%shr = lshr i32 %v, %and4
%or = or i32 %shr, %shl
https://rise4fun.com/Alive/V9r
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360605 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
zlib/nozlib, asan/not_asan, msan/not_msan, ubsan/not_ubsan.
We still have two other ways to express the absence of a feature.
First, we have the '!' operator to invert the sense of a keyword. For
example, given a feature that depends on zlib being unavailable, its
test can say:
REQUIRES: !zlib
Second, if a test doesn't play well with some features, such as
sanitizers, that test can say:
UNSUPPORTED: asan, msan
The different ways of writing these exclusions both have the same
technical effect, but have different implications to the reader.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360603 91177308-0d34-0410-b5e6-96231b3b80d8
The tablegen groups only need public_deps for inc files included
(possibly transitively) in other targets. Move inc files that are
internan to the MCTargetDesc libraries into regular deps.
Related to the changes that merged InstPrinter into MCTargetDesc
(360484, 360486 etc).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360600 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
Test case will be included in a followup - its being used but its tricky to show a case that isn't caught at a later stage anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360588 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
Summary:
This patch is part of a patch series to add support for FileCheck
numeric expressions. This specific patch introduces regular numeric
variables which can be set on the command-line.
This commit introduces regular numeric variable that can be set on the
command-line with the -D option to a numeric value. They can then be
used in CHECK patterns in numeric expression with the same shape as
@LINE numeric expression, ie. VAR, VAR+offset or VAR-offset where offset
is an integer literal.
The commit also enable strict whitespace in the verbose.txt testcase to
check that the position or the location diagnostics. It fixes one of the
existing CHECK in the process which was not accurately testing a
location diagnostic (ie. the diagnostic was correct, not the CHECK).
Copyright:
- Linaro (changes up to diff 183612 of revision D55940)
- GraphCore (changes in later versions of revision D55940 and
in new revision created off D55940)
Reviewers: jhenderson, chandlerc, jdenny, probinson, grimar, arichardson, rnk
Subscribers: hiraditya, llvm-commits, probinson, dblaikie, grimar, arichardson, tra, rnk, kristina, hfinkel, rogfer01, JonChesterfield
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60385
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360578 91177308-0d34-0410-b5e6-96231b3b80d8
Variables with linkonce_odr and weak_odr linkage shouldn't be internalized
if they're not readonly. Otherwise we may end up with multiple copies of
such variable, so reads and writes will become inconsistent
Differential revision: https://reviews.llvm.org/D61255
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360577 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch adds the following features defined by Arm SVE2 architecture
extension:
sve2, sve2-aes, sve2-sm4, sve2-sha3, bitperm
For existing CPUs these features are declared as unsupported to prevent
scheduler errors.
The specification can be found here:
https://developer.arm.com/docs/ddi0602/latest
Reviewers: SjoerdMeijer, sdesmalen, ostannard, rovka
Reviewed By: SjoerdMeijer, rovka
Subscribers: rovka, javed.absar, tschuett, kristof.beyls, kristina, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61513
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360573 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
Tim Northover