The verifier check was in the wrong place, meaning it wasn't actually
checking many instructions.
Fixing that causes a test failure (coro-dwarf-key-instrs.cpp) because
coros turn off the feature but still annotate instructions with the
metadata (which is a supported situation, but the verifier doesn't like
it, and it's hard to teach the verifier to like it).
Fix that by avoiding emitting any key instruction metadata if the
DISubprogram has opted out of key instructions.
(cherry picked from commit 653872f782e1faaabc1da23769e6b35b10e74bde)
If the environment is considered to be the triple component as a whole,
so, including the object format, if any, and if that is the intended
behaviour, then the loongarch64 function `computeTargetABI()` should be
changed to not rely on `hasEnvironment()`, but, rather, to check if
there is a non-unknown environment set.
Without this change, using a (ideally valid) target of
loongarch64-unknown-none-elf, with a manually specified ABI of lp64s,
will result in a completely superfluous warning:
```
warning: triple-implied ABI conflicts with provided target-abi 'lp64s', using target-abi
```
(cherry picked from commit 9ed8816dc63776259d2190bdc8a7a29698c62749)
This is a follow-up PR for post-commit comments in
https://github.com/llvm/llvm-project/pull/146610
- Changed "exporteddllmain" references to "importeddllmain".
- Add support for x86 target and test coverage.
- Changed a comment to better express why we're skipping importing
`DllMain`.
(cherry picked from commit fcacd4e880c9a0b3f2bdaa43603aeddfa1b1cd2e)
Mips was the only architecture having PtrDiffType = SignedInt and
IntPtrType = SignedLong
This fixes a problem on mipsel-windows-gnu triple, where uintptr_t was
wrongly defined as unsigned long instead of unsigned int, leading to
problems in compiler-rt.
compiler-rt/lib/interception/interception_type_test.cpp:24:17: error:
static assertion failed due to requirement
'__sanitizer::is_same<unsigned long, unsigned int>::value':
24 | COMPILER_CHECK((__sanitizer::is_same<__sanitizer::uptr,
::uintptr_t>::value));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compiler-rt/lib/interception/../sanitizer_common/sanitizer_internal_defs.h:369:44:
note: expanded from macro 'COMPILER_CHECK'
369 | #define COMPILER_CHECK(pred) static_assert(pred, "")
| ^~~~
compiler-rt/lib/interception/interception_type_test.cpp:25:17: error:
static assertion failed due to requirement '__sanitizer::is_same<long,
int>::value':
25 | COMPILER_CHECK((__sanitizer::is_same<__sanitizer::sptr,
::intptr_t>::value));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compiler-rt/lib/interception/../sanitizer_common/sanitizer_internal_defs.h:369:44:
note: expanded from macro 'COMPILER_CHECK'
369 | #define COMPILER_CHECK(pred) static_assert(pred, "")
| ^~~~
compiler-rt/lib/interception/interception_type_test.cpp:27:17: error:
static assertion failed due to requirement '__sanitizer::is_same<long,
int>::value':
27 | COMPILER_CHECK((__sanitizer::is_same<::PTRDIFF_T,
::ptrdiff_t>::value));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compiler-rt/lib/interception/../sanitizer_common/sanitizer_internal_defs.h:369:44:
note: expanded from macro 'COMPILER_CHECK'
369 | #define COMPILER_CHECK(pred) static_assert(pred, "")
(cherry picked from commit 13906724ff7aa1bc58202faac62690570dfe0dc3)
Fixes#149669; the old check compared with the end of the literal, but
we can just check that after parsing digits, we're pointing to one
character past the token start.
(cherry picked from commit 8366dc207a2e6b50cb8afe2d98fca68bd78bd0fa)
The pattern i32xi32->i64, should be matched to the sign-extended
multiply op, instead of explicit sign- extension of the operands
followed by non-widening multiply (this takes 4 operations instead of
one). Currently, if one of the operands of multiply inside a loop is a
constant, the sign-extension of this constant is hoisted out of the loop
by LICM pass and this pattern is not matched by the ISEL.
This change handles multiply operand with Opcode of the type AssertSext
which is seen when the sign-extension is hoisted out-of the loop.
Modifies the DetectUseSxtw() to check for this.
(cherry picked from commit fcabb53f0c349885167ea3d0e53915e6c42271a7)
The instruction does `rd = (rs1 << shamt) + rs2` but the ISEL patterns
had `rs1` and `rs2` the other way around which is incorrect.
(cherry picked from commit 84e689b1db02be1687c3093d66ace913250780bd)
This is so that it's performed also for flang and not just for clang.
This should fix https://github.com/llvm/llvm-project/issues/138494.
(cherry picked from commit 38fc453afdb6a4511b7c8e189f12a92559ecc396)
While building libclang_rt.asan-hexagon.so, lld would assert in
lld:🧝:hexagonTLSSymbolUpdate().
Fixes#132766
(cherry picked from commit 3e9ceae29f39456508eef5b4af4d3c895048706a)
This reverts commit 85d09de5fa19a32bbcc400928d55f9d633077640. This
change caused broken symlinks in the build directory, and the subsequent
commits fixing that introduced other issues.
This reverts commit 81e6552a3d6835c4e10eb981402febfac9df6156. This
change caused libclc to start installing broken symlinks that contain
absolute paths to the build directory rather than relative paths
within the install directory.
This reverts commit 8a7a64873b13e6fd931b748fbf50b3da26fe7fca. It broke
standalone builds since the necessary variables are now limited in scope
to `libclc/utils` while they are used in the top-level CMakeLists.
Hexagon instructions are VLIW "bundles" of up to four instruction words
encoded as a single MCInst with operands for each sub-instruction.
Previously, the disassembler's getInstruction() returned the full
bundle, which made it difficult to work with llvm-objdump.
For example, since all instructions are bundles, and bundles do not
branch, branch targets could not be printed.
This patch modifies the Hexagon disassembler to return individual
sub-instructions instead of entire bundles, enabling correct printing of
branch targets and relocations. It also introduces
`MCDisassembler::getInstructionBundle` for cases where the full bundle
is still needed.
By default, llvm-objdump separates instructions with newlines. However,
this does not work well for Hexagon syntax:
{ inst1
inst2
inst3
inst4 <branch> } :endloop0
Instructions may be followed by a closing brace, a closing brace with
`:endloop`, or a newline. Branches must appear within the braces.
To address this, `PrettyPrinter::getInstructionSeparator()` is added and
overridden for Hexagon.
(cherry picked from commit ac7ceb3dabfac548caa993e7b77bbadc78af4464)
cc https://github.com/llvm/llvm-project/pull/138299
rustc sets `allockind("uninitialized")` - if we copy the attributes
as-is when creating a dummy function, Verify complains about
`allockind("uninitialized,zeroed")` conflicting, so we need to clear the
flag.
Co-authored-by: Jamie Hill-Daniel <jamie@osec.io>
(cherry picked from commit 74c396afb26dec74c0b799e218c63f1a26e90d21)
When not in the prologue we do not want to set the FrameSetup flag, by
passing the flag as argument we can use allocateStack correctly on those
cases.
This fixes the allocation and probe in eliminateCallFramePseudoInstr.
(cherry picked from commit 1db9eb23209826d9e799e68a9a4090f0328bf70c)
Reverts llvm/llvm-project#148613
Considering object argument conversion qualifications perfect leads to
situations where we prefer a non-template const qualified function over
a non-qualified template function, which is very wrong indeed.
I explored solutions to work around that, but instead, we might want to
go the GCC road and prefer the friend overload in the #147374 example,
as this seems a lot more consistent and reliable
(cherry picked from commit 28e1e7e1b4b059a2e42f68061475cddb4ad0a6a3)
This is a follow-up to #149079. Seems like we forgot about the fact that
the symbols also need to be in `libclang.map`.
(cherry picked from commit 7e0fde0c2f6b0b9d727ce9196956b36e91961ac4)
Fixes: https://github.com/llvm/llvm-project/issues/148953
Currently when coroutine return object type is const qualified, we don't
do direct emission. The regular emission logic assumed that the auto var
emission will always result in an `AllocaInst`. However, based on my
findings, NRVO var emissions don't result in `AllocaInst`s. Therefore,
this
[assertion](1a940bfff9/clang/lib/CodeGen/CGCoroutine.cpp (L712))
will fail.
Since the NRVOed returned object don't live on the coroutine frame, we
won't have the problem of it outliving the coroutine frame, therefore,
we can safely omit this metadata.
(cherry picked from commit c36156de45a0f5e24e7a4ee2259c3302ea814785)
A constexpr-unknown reference can be equal to an arbitrary value, except
values allocated during constant evaluation. Fix the handling.
The standard is unclear exactly which pointer comparisons count as
"unknown" in this context; for example, in some cases we could use
alignment to prove two constexpr-unknown references are not equal. I
decided to ignore all the cases involving variables not allocated during
constant evaluation.
While looking at this, I also spotted that there might be issues with
lifetimes, but I didn't try to address it.
(cherry picked from commit 20c8e3c2a4744524396cc473a370cfb7855850b6)
This was dropped in #147948 and causes symbol conflicts if libblake3 is
also linked.
(cherry picked from commit 1754a7d5733d5305e4ec25ef0945b39d6882bb28)
There's probably an existing test this should be added to,
but our test coverage is really bad that this wasn't caught
by one.
(cherry picked from commit 0110168f6aa5c8a8d02ffd9e62c7929ce6d24d26)
This patch switches the windows testing over to server 2022 by switching
to the recently introduced runner set.
(cherry picked from commit 3248a6d76abccbbe78e853c76bc022b70d594347)
For more context, see
https://github.com/llvm/llvm-project/pull/119269#issuecomment-3075444493,
but briefly, when removing ARCMigrate, I also removed some symbols in
libclang, which constitutes an ABI break that we don’t want, so this pr
reintroduces the removed symbols; the declarations are marked as
deprecated for future removal, and the implementations print an error
and do nothing, which is what we used to do when ARCMigrate was
disabled.
(cherry picked from commit 1600450f9098e5c9cb26840bd53f1be8a2559b7d)
Added by #147948, blake3_xof_many and blake3_compress_subtree_wide cause
conflicts when linking llvm and blake3 statically into the same binary.
Similar to #148607.
(cherry picked from commit 60579ec3059b2b6cc9dad90eaac1ed363fc395a7)
Happened to spot this while looking at libclang.map for other reasons.
clang_visitCXXMethods was added in LLVM 21, not LLVM 20.
(cherry picked from commit 116110e1a93531a64d82f049b6e36403bc14f278)
The transformation done in #147349 was incorrect since we were not
passing the input node of the `OR` instruction to the `QC.INSBI`
instruction leading to the generated instruction doing the wrong thing.
In order to do this we first needed to add the output register to
`QC.INSBI` as being both an input and output.
The code produced after the above fix will need a copy (mv) to preserve
the register input to the OR instruction if it has more than one use
making the transformation net neutral ( `6-byte QC.E.ORI/ORAI` vs
`2-byte C.MV + 4-byte QC.INSB`I). Avoid doing the transformation if
there is more than one use of the input register to the OR instruction.
(cherry picked from commit d67d91a9906366585162cebf292f923a3f28c8a6)
To fold a FrameIndex, we need to teach eliminateFrameIndex to respect
the uimm9 range.
(cherry picked from commit 63d099af146a19bc8fd5a791d6184125e6cc42e7)
This sets the cache line size to 64 for the Neoverse V2 and V3. I've
tested this with loop-interchange: it doesn't result in extra
compile-times, but it does enable a lot more interchange.
Commit a6293228fdd5aba8c04c63f02f3d017443feb3f2 forced the register
class of ZPR[24]StridedOrContiguous for spills/fills of ZPR2 and ZPR4,
but this may result in issues when the regclass for the fill is a
ZPR2/ZPR4 which would allow the register allocator to pick `z1_z2`,
which is not a supported register for ZPR2StridedOrContiguous that only
supports tuples of the form (strided) `z0_z8`, `z1_z9` or (contiguous,
start at multiple of 2) `z0_z1`, `z2_z3`. For spills we could add a new
register class that supports any of the tuple forms, but I've decided
to use two pseudos similar to the fills for consistency.
Fixes https://github.com/llvm/llvm-project/issues/148655
This analysis currently just crashes when applied to a graph region that
has a use-def cycle. This PR fixes that by keeping track of the
operations the DFS has already visited when following use-def edges and
stopping once we visit an operation again.
This patch introduces two new ops to the SPIR-V dialect:
- `spirv.EXT.ConstantCompositeReplicate`
- `spirv.EXT.SpecConstantCompositeReplicate`
These ops represent composite constants and specialization constants,
respectively, constructed by replicating a single splat constant across
all elements. They correspond to `SPV_EXT_replicated_composites`
extension instructions:
- `OpConstantCompositeReplicatedEXT`
- `OpSpecConstantCompositeReplicatedEXT`
No transformation to these new ops has been introduced in this patch.
This approach is chosen as per the discussions on RFC
https://discourse.llvm.org/t/rfc-basic-support-for-spv-ext-replicated-composites-in-mlir-spir-v-compile-time-constant-lowering-only/86987
---------
Signed-off-by: Mohammadreza Ameri Mahabadian <mohammadreza.amerimahabadian@arm.com>
Before this patch, when a reduction exists in the loop, the legality
check of LoopInterchange only verified if there exists a
non-reassociative floating-point instruction in the reduction
calculation. However, it is insufficient, because reordering integer
reductions can also lead to incorrect transformations. Consider the
following example:
```c
int A[2][2] = {
{ INT_MAX, INT_MAX },
{ INT_MIN, INT_MIN },
};
int sum = 0;
for (int i = 0; i < 2; i++)
for (int j = 0; j < 2; j++)
sum += A[j][i];
```
To make this exchange legal, we must drop nuw/nsw flags from the
instructions involved in the reduction operations.
This patch extends the legality check to correctly handle such cases. In
particular, for integer addition and multiplication, it verifies that
the nsw and nuw flags are set on involved instructions, and drop them
when the transformation actually performed. This patch also introduces
explicit checks for the kind of reduction and permits only those that
are known to be safe for interchange. Consequently, some "unknown"
reductions (at the moment, `FindFirst*` and `FindLast*`) are rejected.
Fix#148228
