This extra stray space after tab can be traced back to when printing
of this directive was added originally in
4f01b783a3. The same commit added
inconsistent printing of space after the ELF .type directive too,
which was fixed later in
77fe07a93a.
(This is kind of NFC, but it does alter the output, so it's not
strictly non-functional in that sense.)
Differential Revision: https://reviews.llvm.org/D118401
This means sve2 is enabled by default and the v8.8 mops (memcpy
and memset acceleration instructions) and HBC (hinted conditional
branch) extensions can be disassembled.
v9.3-a is equivalent to v8.8-a except that in v9.0-a sve2 was
enabled by default so v9.3-a includes that too.
MTE remains an optional extension, only enabled for specific CPUs.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D118358
With opaque pointers, we can no longer derive this from the pointer
type, so we need to explicitly provide the element type the atomic
operation should work with.
Differential Revision: https://reviews.llvm.org/D118359
Inspecting the pointer element type here is incompatible with
opaque pointers, and doesn't seem necessary to me. I think the
intention might have been to check the type of load/store pointer
arguments, but I believe those should get checked through their
return type or value operand anyway. I don't get any test failures
if I simply drop this.
Differential Revision: https://reviews.llvm.org/D118353
If the user doesn't specify a default target triple, the LLVM CMake usually defaults us into the host triple. This is a problem when building Clang/LLVM on 64-bit AIX (i.e. powerpc64-ibm-aix), as the host toolchain (e.g. ar, ld, nm, dump) all expect the compiler to generate 32-bit objects by default (which both GCC and XL on the platform do) and will hard error if passed a 64-bit object without an explicit option or environment setting. This breaks downstream consumers, such as builds generated with build tools like CMake, which when they invoke clang, etc. without explicit bitmode flags also expect 32-bit mode.
This patch changes the default target selection when the host is powerpc64-ibm-aix to prefer powerpc-ibm-aix to avoid these issues. We don't update the runtimes/CMakeList.txt since the default is less meaningful as we assume runtimes will need to build for both targets anyways.
Differential Revision: https://reviews.llvm.org/D118377
This is similar to D116619, but now it handles `invoke`s. The reason we
didn't handle `invoke`s back then was we didn't support Wasm EH + Wasm
SjLj together, and the only case SjLj transformation will see `invoke`s
is when we are using Wasm EH. (In Emscripten EH, they would have been
transformed to `call`s to invoke wrappers.)
But after D117610 we support Wasm EH + Wasm SjLj together and we can
nullify `invoke`s to `setjmp` when there is no other longjmpable calls
within the function. Actually this is very unlikely to happen in
practice, because we treat destructors as longjmpable and also treat
`__cxa_end_catch` as longjmpable even if it is not.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D118408
Wasm SjLj converts longjmpable calls into `invoke`s that unwind to
`%catch.longjmp.dispatch` BB, from where we check if the thrown
exception is a `longjmp`. But in case a call already has a `funclet`
attribute, i.e., it is within a catch scope, we have to unwind to its
unwind destination first to preserve the scoping structure. That will
eventually unwind to `%catch.longjmp.dispatch`, because all
`catchswitch` and `cleanupret` that unwind to caller are redirected to
`%catch.dispatch.longjmp` during Wasm SjLj transformation.
But the prevous code assumed `cleanuppad`'s parent pad was always an
instruction, and didn't handle when a `cleanuppad`'s parent is `none`.
This CL handles this case, and makes the `while` loop more intuitive by
removing `FromPad` condition and explicitly inserting `break`s.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D118407
Wasm EH, used with either of Emscripten SjLj or Wasm SjLj, does not
allow `setjmp` calls to be placed within a `catch` clause, because we
don't support jumping into a `catch` block. Emscripten EH does not have
this restriction. But I think this restriction wouldn't prevent most of
use cases. This CL errors out with a clear messsage for this case.
Reviewed By: dschuff, kripken
Differential Revision: https://reviews.llvm.org/D118286
When we create an invoke wrapper call, if the original call instruction
has a `noreturn` attribute, we shouldn't copy it, because we expect
invoke wrapper calls to return. This generated incorrect `free` call
before an invoke wrapper call that calls `__cxa_throw`, because
`__cxa_throw` has `noreturn` attribute.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D118274
In D117610 we treated `__cxa_end_catch` longjmpable even though it was
not to make unwind destination relationships correct. But we only need
to do this in Wasm SjLj, and doing this in Emscripten SjLj does not make
the code incorrect but add unnecessary invokes. This CL treats
`__cxa_end_catch` longjmpable only in Wasm SjLj.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D117943
This patch introduces folding of and-reduce idiom and generates code
that is easier to read and which is lest costly in terms of icmp operations.
The folding is
```
icmp eq (bitcast(icmp ne (lhs, rhs)), 0)
```
into
```
icmp eq(bitcast(lhs), bitcast(rhs))
```
See PR53419.
Differential Revision: https://reviews.llvm.org/D118317
Reviewed By: lebedev.ri, spatel
* After 3452a0d8c1 (2020-07), $prefix/$triple-$file is not searched.
* Unlike GCC, -B is not used for include paths. Seems nobody needs this behavior because there are more targeted options like --sysroot/-isystem
According to riscv-v-spec-1.0, widening signed(vs2)-unsigned integer multiply
vwmulsu.vv vd, vs2, vs1, vm # vector-vector
vwmulsu.vx vd, vs2, rs1, vm # vector-scalar
It is worth noting that signed op is only for vs2.
For vwmulsu.vv, we can swap two ops, and don't care which is sign extension,
but for vwmulsu.vx signExt can not be a vector extended from scalar (rs1).
I specifically added two functions ending with _swap in the test case.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D118215
Use the llvm flag `-pgo-function-entry-coverage` to create single byte "counters" to track functions coverage. This mode has significantly less size overhead in both code and data because
* We mark a function as "covered" with a store instead of an increment which generally requires fewer assembly instructions
* We use a single byte per function rather than 8 bytes per block
The trade off of course is that this mode only tells you if a function has been covered. This is useful, for example, to detect dead code.
When combined with debug info correlation [0] we are able to create an instrumented Clang binary that is only 150M (the vanilla Clang binary is 143M). That is an overhead of 7M (4.9%) compared to the default instrumentation (without value profiling) which has an overhead of 31M (21.7%).
[0] https://groups.google.com/g/llvm-dev/c/r03Z6JoN7d4
Reviewed By: kyulee
Differential Revision: https://reviews.llvm.org/D116180
In older versions of llvm (e.g. llvm 13), symbols were not individually
flagged as TLS. In this case, the indent was to implicitly mark any
symbols defined in TLS segments as TLS. However, we were not performing
this implicit conversion if the segment was explicitly marked as TLS
As it happens, llvm 13 was branched between the addition of the segment
flag and the addition of the symbol flag. See:
- segment flag added: https://reviews.llvm.org/D102202
- symbol flag added: https://reviews.llvm.org/D109426
Testing this is tricky because the assembler will imply the TLS status
of the symbol based on the segment its declared in, so we are forced to
use a yaml file here.
Fixes: https://github.com/emscripten-core/emscripten/issues/15891
Differential Revision: https://reviews.llvm.org/D118414
Implement the mechanism that simplifies the execution policy/iterator
category dispatching and allows to implement customizations for
the parallel algorithms with adding custom tags
Reviewed By: rodgert, MikeDvorskiy
Differential Revision: https://reviews.llvm.org/D104492
With these changes, check-asan passes on Linux and Windows.
There are a couple libraries we need to add support for, asan_static, asan_preinit, and the shared library version of asan proper.
Since we need to build the asan proper sources twice, once with -DASAN_DYNAMIC and once without, those sources are no longer in a source_set.
Much of the check-asan target is taken from the existing check-hwasan target.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D118307
If we have a broken assumption we want to print a message to the user.
If the assumption is broken by many threads in many teams this can
become a problem. To avoid it we use a hash that tracks if a broken
assumption has (likely) been printed and avoid printing it again. This
is not fool proof and has some caveats that might cause problems in
the future (see comment) but it should improve the situation
considerably for now.
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D112156
This patch changes the code generation of runtime flags to only occur if
a host bitcode file was passed in. This is a cheap way to determine if
we are compiling the OpenMP device runtime itself or user code. This is
needed because the global flags we generate for the device runtime e.g.
__omp_rtl_debug_kind were being generated with default values when we
compiled the runtime library. This would then invalidate the ones we
want to be able to add in when the user defines it.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D118399
The tests for these are just copy-pasted from the tests for std::{strong,weak,partial}_order,
and then I added an extra clause in each (test_2()) to test the stuff that's not just the same
as std::*_order.
This also includes the fix for https://wg21.link/LWG3465 (which falls naturally out of the
"you must write it three times" style, but I've added test cases for it also).
There is an action item here to go back and give good diagnostics for SFINAE failures
in these CPOs. I've filed this as https://github.com/llvm/llvm-project/issues/53456 .
Differential Revision: https://reviews.llvm.org/D111514
On targets that have limited atomic support, e.g. ones that define
ATOMIC_*_LOCK_FREE to '1' ("sometimes lock free"), we would end up
referencing yet-undefined __libcpp_{,un}signed_lock_free.
This commit adds a guard to prevent these references for such
targets.
Differential Revision: https://reviews.llvm.org/D118391
The aarch64 platform has special registers like X0_X1_X2_X3_X4_X5_X6_X7.
Using the downwards propagation this register will become a super
register for all X0..X7 and its super registers which is not right. This
patch replaces the downwards propagation with caching all the aliases using MCRegAliasIterator.
Vladislav Khmelevsky,
Advanced Software Technology Lab, Huawei
Reviewed By: maksfb
Differential Revision: https://reviews.llvm.org/D117394
Martin Storsjö