The intrinsic @llvm.amdgcn.flat.atomic.{fadd,fmax,fmin} can only be
selected for flat address spaces (constant, flat and global).
This patch restricts the cases over which GCNTTIImpl::rewriteIntrinsicWithAddressSpace
rewrites the intrinsic.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D149938
Make it clearer minnum(+0, +0) cannot return -0. Also remove
a note about the result always being quiet which is directly
contradicted by the following paragraph.
Show line numbers to the left of diagnostic code snippets and increase
the numbers of lines shown from 1 to 16.
Differential Revision: https://reviews.llvm.org/D147875
MS link accepts *.obj with ehcont bit set only. LLD should match this
behavoir too.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D150508
This patch adds support for DWARFv5 .debug_line_str table.
It replaces code generating line table. Instead of copying original
table and patching certain places this patch implements full line table
generation.
Differential Revision: https://reviews.llvm.org/D150554
Make sure the code comments in processMemSetMemCpyDependence match
with the actual transform. They indicated that the memset being
rewritten was sunk to after a memcpy, while it actually is inserted
just before the memcpy.
Also make sure we use the debug location of the original memset
when creating the new simplified memset. In the past we've been
using the debug location for the memcpy which could be a bit
confusing.
Differential Revision: https://reviews.llvm.org/D135574
This reverts commit 5cafecf9f9.
Buildbots are not happy with the patch.
Lots of crashes and assertion failures such as
llvm::LegalizeRuleSet &llvm::LegalizerInfo::getActionDefinitionsBuilder(
std::initializer_list<unsigned int>): Assertion `Opcodes.size() >= 2 &&
"Initializer list must have at least two opcodes"' failed.
Summary:
1. we use the unsigned type for NextOffset,PrevOffset ,GlobalSymbolOffset , MemberTableSize, it will caused a malform big archive when the archive file size is large than 4G.
2. also fix a NFC comment on https://reviews.llvm.org/D142479#inline-1443927
Reviewers: James Henderson
Differential Revision: https://reviews.llvm.org/D150462
This remove a bunch of #include statements in Scalar.cpp. I do not
think those should be needed any longer (assuming that they once
upon a time possibly were needed for legacy PM C bindings, but
that is not supported any longer).
Also removing some other #include statements not needed any longer
due to deprecation of legacy PM.
Differential Revision: https://reviews.llvm.org/D149438
These intrinsics are used to implement the pext intrinsics that extract
two predicates (mask) from a predicate-as-counter value, e.g.
__attribute__((arm_streaming))
svboolx2_t svpext_lane_c8_x2(svcount_t pnn, uint64_t imm);
As described in https://github.com/ARM-software/acle/pull/217
Reviewed By: kmclaughlin
Differential Revision: https://reviews.llvm.org/D150442
These intrinsics are used to implement the pext intrinsics that extract
a predicate (mask) from a predicate-as-counter value, e.g.
__attribute__((arm_streaming))
svbool_t svpext_lane_c8(svcount_t pnn, uint64_t imm);
As described in https://github.com/ARM-software/acle/pull/217
Reviewed By: david-arm
Differential Revision: https://reviews.llvm.org/D150441
In D148674, the negative condition was weakened to only
checking isKnownNever(fcNegative), instead of cannotBeOrderedLessThanZero().
This avoids a regression when CannotBeOrderedLessThanZero is
replaced with computeKnownFPClass.
The COMPILER_RT_HAS_FLOAT16 cmake check is now set per architecture,
which needs to be reflected when building the tests.
Additionally added armhf to the architecture list.
Reviewed By: dim
Differential Revision: https://reviews.llvm.org/D150281
This change is necessary to set correct EFlags according to the
options (-m*-float and -mabi=) passed to clang when input is assembly.
Note: `-mabi=` is not documented by `as`.
```
$ as --version
GNU assembler (GNU Binutils) 2.40.50.20230316
...
$ as --target-help
LARCH options:
```
But we can see gcc invokes `as` and passes the `-mabi=` option when compiling C or assembly.
```
$ gcc -c a.c -v 2>&1 -msoft-float | grep "as -v"
as -v -mabi=lp64s -o a.o /tmp/ccFrxzZi.s
$ gcc -c a.s -v 2>&1 -msoft-float | grep "as -v"
as -v -mabi=lp64s -o a.o a.s
```
Reviewed By: xen0n
Differential Revision: https://reviews.llvm.org/D150537
In practice, a Warning on every occurrence is very unpopular, even on a codebase
with clear rules about direct inclusion & moderately good compliance.
This change has various practical effects (in vscode for concreteness):
- makes the diagnostic decoration less striking (blue vs yellow)
- makes these diagnostics visually distinct from others when reading
- causes these diagnostics to sort last in the "problems" view
- allows these diagnostics to be easily filtered from the "problems" view
Differential Revision: https://reviews.llvm.org/D149912
This alters the lowering of shifts by a constant, so that the type is lowered
to a v1i64 instead of a i64. This helps communicate that the type will live in
a neon register, and can help clean up surrounding code. Note this is only
currently for the scalar shifts of a constant that go through the nodes in
tryCombineShiftImm.
ssra instructions are no longer being recognized in places, but that can be
cleaned up in a followup patch that combines the i64 add into a v1i64 add.
Differential Revision: https://reviews.llvm.org/D148309
This is the second part of the below RFC:
https://discourse.llvm.org/t/rfc-handle-execution-results-in-clang-repl/68493
This patch implements a Value class that can be used to carry expression
results in clang-repl. In other words, when we see a top expression
without semi, it will be captured and stored to a Value object. You can
explicitly specify where you want to store the object, like:
```
Value V;
llvm::cantFail(Interp->ParseAndExecute("int x = 42;"));
llvm::cantFail(Interp->ParseAndExecute("x", &V));
```
`V` now stores some useful infomation about `x`, you can get its real
value (42), it's `clang::QualType` or anything interesting.
However, if you don't specify the optional argument, it will be captured
to a local variable, and automatically called `Value::dump`, which is
not implemented yet in this patch.
Signed-off-by: Jun Zhang <jun@junz.org>
This patch is the first part of the below RFC:
https://discourse.llvm.org/t/rfc-handle-execution-results-in-clang-repl/68493
It adds an annotation token which will replace the original EOF token
when we are in the incremental C++ mode. In addition, when we're
parsing an ExprStmt and there's a missing semicolon after the
expression, we set a marker in the annotation token and continue
parsing.
Eventually, we propogate this info in ParseTopLevelStmtDecl and are able
to mark this Decl as something we want to do value printing. Below is a
example:
clang-repl> int x = 42;
clang-repl> x
// `x` is a TopLevelStmtDecl and without a semicolon, we should set
// it's IsSemiMissing bit so we can do something interesting in
// ASTConsumer::HandleTopLevelDecl.
The idea about annotation toke is proposed by Richard Smith, thanks!
Signed-off-by: Jun Zhang <jun@junz.org>
Differential Revision: https://reviews.llvm.org/D148997
llvm-clang-x86_64-expensive-checks-debian will fail after D150436 merged.
The fail occurred in X86, I changed the sort rule in AsmMatcher in Patch D150436, so x86 code will arrive line 633 first(will not affect other targets).
The logic here want to use the order record written in source file to make AsmMatcher to first use AVX instructions, it used field HasPositionOrder.
But the condition here just makes sure one of the compared record is subclass of Instruction and has field HasPositionOrder true, and didn't check another.
(Committing on behalf of @XinWang10 to unblock broken expensive-cjhecks builds)
Differential Revision: https://reviews.llvm.org/D150651
This moves all but one remaining tests which use clang-cl and test
MSVC-specific behaviour into its own subdirectory. `dll_host.cpp` test
is excluded from the move because other tests also depend on its source
file, making it not MSVC-specific.
Differential Revision: https://reviews.llvm.org/D150271
This appears to be a leftover from when these tests were first added in
D62927. Because of this, these tests had never run with `check-asan` or
`check-asan-dynamic`.
I've tested locally that these tests do pass on both i686 MSVC and MinGW
targets. They are disabled for 64-bit though, and I believe no LLVM
buildbots are testing for 32-bit Windows targets.
Differential Revision: https://reviews.llvm.org/D150270
