[DAG] expandCLMUL - unroll vector clmul if vector multiplies are not supported (#182041)
Fixes powerpc cases reported on #182039
I'm hoping #177566 can be adapted to improve upon this.
[LLVM][CLANG] Update signal-handling behavior to comply with POSIX (#169340)
The POSIX standard
[POSIX.1-2024](https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap01.html#tag_18)
specifies how the utility reacts to signals as follows. This includes
clang when invoke through a invocation such as
[c17](https://pubs.opengroup.org/onlinepubs/9799919799/utilities/c17.html)
```
ASYNCHRONOUS EVENTS
The ASYNCHRONOUS EVENTS section lists how the utility reacts to such events as signals and what signals are caught.
Default Behavior: When this section is listed as "Default.", or it refers to "the standard action" for any signal, it means that the action taken as a result of the signal shall be as follows:
If the action inherited from the invoking process, according to the rules of inheritance of signal actions defined in the System Interfaces volume of POSIX.1-2024, is for the signal to be ignored, the utility shall ignore the signal.
If the action inherited from the invoking process, according to the rules of inheritance of signal actions defined in System Interfaces volume of POSIX.1-2024, is the default signal action, the result of the utility's execution shall be as if the default signal action had been taken.
When the required action is for the signal to terminate the utility, the utility may catch the signal, perform some additional processing (such as deleting temporary files), restore the default signal action, and resignal itself.
```
[9 lines not shown]
[TableGen] Return int32_t from InstrMapping table lookup functions. NFC. (#182079)
Since #182059 there is only one case in which these functions return -1,
so callers no longer need to distinguish between (int64_t)-1 and
(uint32_t)-1, so we can go back to a 32-bit return value like it was
before #180954.
[ConstantFolding] Fix type mismatch in ConstantFolding for vector types. (#181695)
Drop `Bitcast` case from `IsConstantOffsetFromGlobal` to avoid
misdetections.
Merge commit bfb276e55c76 from upstream OpenZFS (by Jessica Clarke)
Once upon a time, 32-bit PowerPC did indeed have a 32-bit time_t, but
FreeBSD 12.0 switched to a 64-bit time_t for PowerPC as an ABI break,
which predates the addition of FreeBSD support to OpenZFS. Moreover,
64-bit PowerPC has existed since FreeBSD 9.0, where __powerpc__ is also
defined (alongside __powerpc64__ to disambiguate), which has always had
a 64-bit time_t. This code has therefore always been wrong for all
PowerPC variants. Fix this by limiting the 32-bit case to just i386,
which is the only architecture in FreeBSD to have a 32-bit time_t and
not have broken ABI, due to its special legacy compatibility status.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Jessica Clarke <jrtc27 at jrtc27.com>
Closes #18217
Closes #18218
Reported by: fuz
[3 lines not shown]
Merge commit bfb276e55c76 from upstream OpenZFS (by Jessica Clarke)
Once upon a time, 32-bit PowerPC did indeed have a 32-bit time_t, but
FreeBSD 12.0 switched to a 64-bit time_t for PowerPC as an ABI break,
which predates the addition of FreeBSD support to OpenZFS. Moreover,
64-bit PowerPC has existed since FreeBSD 9.0, where __powerpc__ is also
defined (alongside __powerpc64__ to disambiguate), which has always had
a 64-bit time_t. This code has therefore always been wrong for all
PowerPC variants. Fix this by limiting the 32-bit case to just i386,
which is the only architecture in FreeBSD to have a 32-bit time_t and
not have broken ABI, due to its special legacy compatibility status.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Jessica Clarke <jrtc27 at jrtc27.com>
Closes #18217
Closes #18218
Reported by: fuz
[3 lines not shown]
Merge commit bfb276e55c76 from upstream OpenZFS (by Jessica Clarke)
Once upon a time, 32-bit PowerPC did indeed have a 32-bit time_t, but
FreeBSD 12.0 switched to a 64-bit time_t for PowerPC as an ABI break,
which predates the addition of FreeBSD support to OpenZFS. Moreover,
64-bit PowerPC has existed since FreeBSD 9.0, where __powerpc__ is also
defined (alongside __powerpc64__ to disambiguate), which has always had
a 64-bit time_t. This code has therefore always been wrong for all
PowerPC variants. Fix this by limiting the 32-bit case to just i386,
which is the only architecture in FreeBSD to have a 32-bit time_t and
not have broken ABI, due to its special legacy compatibility status.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Jessica Clarke <jrtc27 at jrtc27.com>
Closes #18217
Closes #18218
Reported by: fuz
[3 lines not shown]
Merge commit bfb276e55c76 from upstream OpenZFS (by Jessica Clarke)
Once upon a time, 32-bit PowerPC did indeed have a 32-bit time_t, but
FreeBSD 12.0 switched to a 64-bit time_t for PowerPC as an ABI break,
which predates the addition of FreeBSD support to OpenZFS. Moreover,
64-bit PowerPC has existed since FreeBSD 9.0, where __powerpc__ is also
defined (alongside __powerpc64__ to disambiguate), which has always had
a 64-bit time_t. This code has therefore always been wrong for all
PowerPC variants. Fix this by limiting the 32-bit case to just i386,
which is the only architecture in FreeBSD to have a 32-bit time_t and
not have broken ABI, due to its special legacy compatibility status.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Jessica Clarke <jrtc27 at jrtc27.com>
Closes #18217
Closes #18218
Reported by: fuz
[3 lines not shown]
Merge commit bfb276e55c76 from upstream OpenZFS (by Jessica Clarke)
Once upon a time, 32-bit PowerPC did indeed have a 32-bit time_t, but
FreeBSD 12.0 switched to a 64-bit time_t for PowerPC as an ABI break,
which predates the addition of FreeBSD support to OpenZFS. Moreover,
64-bit PowerPC has existed since FreeBSD 9.0, where __powerpc__ is also
defined (alongside __powerpc64__ to disambiguate), which has always had
a 64-bit time_t. This code has therefore always been wrong for all
PowerPC variants. Fix this by limiting the 32-bit case to just i386,
which is the only architecture in FreeBSD to have a 32-bit time_t and
not have broken ABI, due to its special legacy compatibility status.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Jessica Clarke <jrtc27 at jrtc27.com>
Closes #18217
Closes #18218
Reported by: fuz
MFC after: 1 day
Merge commit bfb276e55c76 from upstream OpenZFS (by Jessica Clarke)
Once upon a time, 32-bit PowerPC did indeed have a 32-bit time_t, but
FreeBSD 12.0 switched to a 64-bit time_t for PowerPC as an ABI break,
which predates the addition of FreeBSD support to OpenZFS. Moreover,
64-bit PowerPC has existed since FreeBSD 9.0, where __powerpc__ is also
defined (alongside __powerpc64__ to disambiguate), which has always had
a 64-bit time_t. This code has therefore always been wrong for all
PowerPC variants. Fix this by limiting the 32-bit case to just i386,
which is the only architecture in FreeBSD to have a 32-bit time_t and
not have broken ABI, due to its special legacy compatibility status.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Jessica Clarke <jrtc27 at jrtc27.com>
Closes #18217
Closes #18218
Reported by: fuz
MFC after: 1 day
[clang][ARM] Refactor argument handling in `EmitAArch64BuiltinExpr` (2/2) (NFC)
Refactor `EmitAArch64BuiltinExpr` so that all AArch64/NEON builtins
handled by this hook _and marked as overloaded_ share a common path
for generating LLVM IR arguments (collected into the `Ops`
`SmallVector<Value*>`) (*). This is a follow-up for #181794 - please
refer to that PR for more context.
As in the previous PR, the key change is implemented in
`HasExtraNeonArgument` , i.e. in the hook that identifies Builtins with
the extra argument. In this PR, I am replacing the ad-hoc switch
statement with a more principled approach borrowed from SemaARM.cpp,
namely:
```cpp
uint64_t mask = 0;
switch (BuiltinID) {
#define GET_NEON_OVERLOAD_CHECK
#include "clang/Basic/arm_fp16.inc"
#include "clang/Basic/arm_neon.inc"
[28 lines not shown]
[HLSL] Define CBuffer field alignment for matrix types (#179836)
fixes https://github.com/llvm/llvm-project/issues/179834
Change defines Matrix alignment as buffer row length (16). Same as
arrays and structs.
Change also adds tests for matrix, matrix in structs, & arrays.
[clang][ARM] Refactor argument handling in `EmitAArch64BuiltinExpr` (1/2) (NFC)
Refactor `EmitAArch64BuiltinExpr` so that all AArch64/NEON builtins
handled by this hook _and marked as non-overloaded_ share a common path
for generating LLVM IR arguments (collected into the `Ops`
`SmallVector<Value*>`) (*)
Previously, the argument emission loop unconditionally skipped the
trailing argument:
```cpp
for (unsigned i = 0, e = E->getNumArgs() - 1; i != e; ++i)
```
This was originally intended to ignore the extra Sema-only argument
used by overloaded NEON builtins (e.g. the type discriminator passed
by `__builtin_neon_*` intrinsics). However, this logic was applied
unconditionally.
[37 lines not shown]
[HLSL][Cbuffer][Matrix] Add Cbuffer padding and createBufferMatrixTempAddress (#181903)
fixes #181901
This change detects when a HLSL Cbuffer matrix’s layout differs from its
in-memory type and materializes a temporary with the non-padded matrix
type. Matrix elements are copied explicitly from the padded buffer
layout into the temporary, ensuring correct addressing and avoiding
overlapping GEPs or incorrect vector flattening.
