Before llvm20, (void)__sync_fetch_and_add(...) always generates locked
xadd insns. In linux kernel upstream discussion [1], it is found that
for arm64 architecture, the original semantics of
(void)__sync_fetch_and_add(...), i.e., __atomic_fetch_add(...), is
preferred in order for jit to emit proper native barrier insns.
In llvm commits [2] and [3], (void)__sync_fetch_and_add(...) will
generate the following insns:
- for cpu v1/v2: locked xadd insns to keep backward compatibility
- for cpu v3/v4: __atomic_fetch_add() insns
To ensure proper barrier semantics for (void)__sync_fetch_and_add(...),
cpu v3/v4 is recommended.
This patch enables cpu=v3 as the default cpu version. For users wanting
to use cpu v1, -mcpu=v1 needs to be explicitly added to clang/llc
command line.
[1]
https://lore.kernel.org/bpf/ZqqiQQWRnz7H93Hc@google.com/T/#mb68d67bc8f39e35a0c3db52468b9de59b79f021f
[2] https://github.com/llvm/llvm-project/pull/101428
[3] https://github.com/llvm/llvm-project/pull/106494
collectInstsToScalarize may decide to scalarize a call. If so, we have
to update the widening decision for the call, otherwise the call won't
be scalarized as expected during VPlan construction.
This issue was uncovered by f82543d509.
Don't just leave the result as unknown. I think this currently
works out thanks to undef resolution, but the correct thing to
do is set it to overdefined explicitly.
As detailed in Issue #101667, two `profile` tests `FAIL` on 32-bit
SPARC, both Linux/sparc64 and Solaris/sparcv9 (where the tests work when
enabled):
```
Profile-sparc :: ContinuousSyncMode/runtime-counter-relocation.c
Profile-sparc :: ContinuousSyncMode/set-file-object.c
```
The Solaris linker provides the crucial clue as to what's wrong:
```
ld: warning: symbol '__llvm_profile_counter_bias' has differing sizes:
(file runtime-counter-relocation-17ff25.o value=0x8; file libclang_rt.profile-sparc.a(InstrProfilingFile.c.o) value=0x4);
runtime-counter-relocation-17ff25.o definition taken
```
In fact, the types in `llvm` and `compiler-rt` differ:
- `__llvm_profile_counter_bias`/`INSTR_PROF_PROFILE_COUNTER_BIAS_VAR` is
created in `llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp`
(`InstrLowerer::getCounterAddress`) as `int64_t`, while
`compiler-rt/lib/profile/InstrProfilingFile.c` uses `intptr_t`. While
this doesn't matter in the 64-bit case, the type sizes differ for
32-bit.
- `__llvm_profile_bitmap_bias`/`INSTR_PROF_PROFILE_BITMAP_BIAS_VAR` has
the same issue: created in `InstrProfiling.cpp`
(`InstrLowerer::getBitmapAddress`) as `int64_t`, while
`InstrProfilingFile.c` again uses `intptr_t`.
This patch changes the `compiler-rt` types to match `llvm`. At the same
time, the affected testcases are enabled on Solaris, too, where they now
just `PASS`.
Tested on `sparc64-unknown-linux-gnu`, `sparcv9-sun-solaris2.11`,
`x86_64-pc-linux-gnu`, and `amd64-pc-solaris2.11.
It appears that the RUNTIMES build prefers the x86-64-unknown-linux-gnu
triple notation for the host. This fixes runtime / test breakages when
compiler-rt is used as the CLANG_DEFAULT_RTLIB.
Assigning to a pointer parameter does not leak the stack address because
it stays within the function and is not shared with the caller.
Previous implementation reported any association of a pointer parameter
with a local address, which is too broad.
This fix enforces that the pointer to a stack variable is related by at
least one level of indirection.
CPP-5642
Fixes#106834
This patch adds a common lower action for `G_FABS`, which generates `and
x8, x8, #0x7fffffffffffffff` to reset the sign bit. The action does not
support vectors since `G_AND` does not support fp128.
This approach is different than what SDAG is doing. SDAG stores the
value onto stack, clears the sign bit in the most significant byte, and
loads the value back into register. This involves multiple memory ops
and sounds slower.
The existing function already used the MainLoop class, which allows one
to wait on multiple events at once. It needed to do this in order to
wait for v4 and v6 connections simultaneously. However, since it was
creating its own instance of MainLoop, this meant that it was impossible
to multiplex these sockets with anything else.
This patch simply adds a version of this function which uses an
externally provided main loop instance, which allows the caller to add
any events it deems necessary. The previous function becomes a very thin
wrapper over the new one.
Overview of changes:
- All memref input arguments are re-named to %mem.
- All vector input arguments are re-named to %vec.
- All index input arguments are re-named to %idx.
- All tensor input arguments are re-named to %src/%dst.
- LIT variables were updated to be consistent with input arguments.
- Renamed all output arguments as %res.
- Removed unused argument in `transfer_write_broadcast_unit_dim`.
- Unified identation of `FileCheck` commands.
- Split `transfer_write_permutations` and `transfer_write_broadcast_unit_dim` into tensor and memref variants.
- Renamed `transfer_write_permutations_tensor` as `transfer_write_permutations_tensor_masked`.
Currently, the testing infrastructure for SPIR-V is based on FileCheck.
Those tests are great to check some level of codegen, but when the test
needs check both the CFG layout and the content of each basic-block,
things becomes messy.
- Because the CHECK/CHECK-DAG/CHECK-NEXT state is limited, it is
sometimes hard to catch the good block: if 2 basic blocks have similar
instructions, FileCheck can match the wrong one.
- Cross-lane interaction can be a bit difficult to understand, and
writting a FileCheck test that is strong enough to catch bad CFG
transforms while not being broken everytime some unrelated codegen part
changes is hard.
And lastly, the spirv-val tooling we have checks that the generated
SPIR-V respects the spec, not that it is correct in regards to the
source IR.
For those reasons, I believe the best way to test the structurizer is
to:
- run spirv-val to make sure the CFG respects the spec.
- simulate the function to validate result for each lane, making sure
the generated code is correct.
This simulator has no other dependencies than core python. It also only
supports a very limited set of instructions as we can test most features
through control-flow and some basic cross-lane interactions.
As-is, the added tests are just a harness for the simulator itself. If
this gets merged, the structurizer PR will benefit from this as I'll be
able to add extensive testing using this.
---------
Signed-off-by: Nathan Gauër <brioche@google.com>
Previously we tracked data sharing attributes by the symbol itself not
by the ultimate symbol. When the private clause came first, subsequent
uses of the symbol found a host-associated version instead of the
ultimate symbol and so the check didn't consider them to be the same
symbol. Always adding and checking for the ultimate symbol ensures that
we have the same behaviour no matter the order of clauses.
The modified list is only used for this multiple clause check.
Closes#78235
ReadProcessMemory will not perform the read if part of the memory is
unreadable (and even though the API has a `number_of_bytes_read`
argument). To make this work, I explicitly inspect the memory region
being read and only read the accessible part.
Compiler-rt can be built for Windows, and most parts of it work. Some
parts only really work on x86/x86_64 (like address sanitizers), but the
OS overall is supported.
The LegalizeDAG expansion will go through memory since i16 isn't a legal
type. Avoid this by using FMV nodes.
Similar to what we did for #106886 for FNEG and FABS. Special care is
needed to handle the Sign operand being a different type.
Fixes#80235
When trying to overload a function within `extern "C"`, the diagnostic
`functions that differ only in their return type cannot be overloaded`
is given. This diagnostic is inappropriate because overloading is
basically not allowed in the C language. However, if the redeclared
function has the `((overloadable))` attribute, it should be diagnosed as
`functions that differ only in their return type cannot be overloaded`.
This patch uses `isExternC()` to provide an appropriate diagnostic
during the diagnostic process. `isExternC()` updates the linkage
information cache internally, so calling it before merging functions can
cause clang to crash. An example is declaring `static void foo()` and
`void foo()` within an `extern "C"` block. Therefore, I decided to call
`isExternC()` after the compilation error is confirmed and select the
diagnostic message. The diagnostic message is `conflicting types for
'func'` similar to the diagnostic in C, and `functions that differ only
in their return type cannot be overloaded` if the `((overloadable))`
attribute is given.
Regression tests verify that the expected diagnostics are given when
trying to overload functions within `extern "C"` and when the
`((overloadable))` attribute is present.
---------
Co-authored-by: Sirraide <aeternalmail@gmail.com>
Without this patch, {ImportMapTy,SortedImportList}::{begin,end} make
unnecessary copies of ImportIDTable via:
map_iterator(Imports.begin(), IDs);
The second parameter, IDs, is passed by value, so we make a copy of
MapVector inside ImportIDTable every time we call begin and end.
These begin and end show up as time-consuming functions in the
performance profile.
This patch fixes the problem by passing IDs by reference with
std::cref.
While we are at it, this patch deletes the copy constructor and
assignment operator. I cannot think of any legitimate need reason to
make a copy of the deduplication table.
Apparently DragonFly BSD and Solaris/illumos call these APIs
`pthread_get_name_np` / `pthread_set_name_np` (with an extra
underscore) instead of `pthread_getname_np` / `pthread_setname_np`.
