[AArch64][SME] Disable tail calls in new ZA/ZT0 functions (#177152)
Allowing this can result in invalid tail calls to shared ZA functions.
It may be possible to limit this to the case where the caller is private
ZA and the callee shares ZA, but for now it is generally disabled.
(cherry picked from commit 10aca26ffffe6a9ee049f479ed7fee9e07421dad)
[LLVM] Update the default value for MaxLargeFPConvertBitWidthSupported to 128 (#176851)
Previously, we can't compile the program which convert 256 bits to
floating points and vice versa(we'll crash). After this, we're able to
compile them.
Fix EXTEND_VECTOR_INREG widening when input > result size (#177095)
This patch fixes an LLVM crash on AMDGPU that occurred when compiling
valid code involving non-power-of-two vector sizes. During type
legalization, LLVM widened an EXTEND_VECTOR_INREG operation by first
widening the input vector, which could make the input larger than the
result and trigger an assertion failure.
The fix changes the logic to widen the result first and then extract the
needed portion so there's no invalid size mismatch. I've added a test
that previously crashed but now doesn't.
fixes #176966.
---------
Co-authored-by: Natalia Kokoromyti <knatalia at yost-cm-01-imme.stanford.edu>
[LoongArch] Remove DAG combination for extractelement (#177083)
Combination for `trunc+extend+extractelement` to a single
`extractelement` may occur error, because the high bits of the extract
index truncated by `trunc` operation are reserved after the combination.
This commit remove this combination and the issue
https://github.com/llvm/llvm-project/issues/176839 will never appear.
(cherry picked from commit f537408bc4fee1b7edc6b703e68792957f85f133)
[CodeGenPrepare] Fix infinite loop with same-type bitcasts (#176694)
OptimizeNoopCopyExpression was sinking same-type bitcasts (e.g. bitcast
i32 to i32) which would then be reintroduced by optimizePhiType, causing
an infinite loop.
Fix by adding a check (PhiTy == ConvertTy) in optimizePhiType to skip
the conversion when types are already identical.
Fixes #176688.
[MC] Explicitly use memcpy in emitBytes() (NFC) (#177187)
We've observed a compile-time regression in LLVM 22 when including large
blobs. The root cause was that emitBytes() was copying bytes one-by-one,
which is much slower than using memcpy for large objects.
Optimization of std::copy to memmove is apparently much less reliable
than one might think. In particular, when using a non-bleeding-edge
libstdc++ (anything older than version 15), this does not happen if the
types of the input and output iterators do not match (like here, where
there is a signed/unsigned mismatch).
As this code is performance sensitive, I think it makes sense to
directly use memcpy.
Previously this code used SmallVector::append, which explicitly uses
memcpy.
[lldb] Change bitfield range character from '-' to ':' in DIL (#173410)
Change the bitfield extraction range character from '-' to a more common
':'.
Add a deprecation error when '-' is used and a release note about it.
[llvm][utils] Remove source owner check from merge-release-pr script (#176949)
This check prevents landing PRs from branches on llvm/llvm-project which
is a thing now.
(cherry picked from commit d9ca7371d663a75364010e4bd0d9032ddea8c1c0)
[TableGen] Make sure ResNo is the same in CheckTypeMatcher::isContradictoryImpl. (#177312)
CheckType can only be contradictory if the same result is being checked.
Noticed while looking at the code. This doesn't affect the output on any
in tree targets.
[clang][cmake] Use llvm-libtool-darwin in clang multi-stage build (#177277)
We are seeing the build system uses the XCode's libtool when building
the 2nd stage of the clang on mac. We should use the llvm-libtool-darwin
from the previous stage clang build instead. This patch makes multi-stage
clang build to use llvm-libtool-darwin from the previous stage when targeting
mac.
[ORC] Fix missing support of deinitialize on ELF platform and execution order by priority (#175981)
This PR fixes
1. issue #175509 about missing support of deinitialize on ELF platform.
2. missing support of execution order by proirity at both initialize and
deinitialize stage.
cc: @tqchen @joker-eph
[Flang][OpenMP][Offload] Modify MapInfoFinalization to handle attach mapping and 6.1's ref_* and attach map keywords
This PR is one of four required to implement the attach mapping semantics in Flang, alongside the
ref_ptr/ref_ptee/ref_ptr_ptee map modifiers and the attach(always/never/auto) modifiers.
This PR is the MapInfoFinalization changes required to support these features, it mainly deals with
applying the correct attach map type and manipulating the descriptor types maps for base address
and descriptor so that when we specify ref_ptr/ref_ptee we emit one of the two maps and when we
emit ref_ptr_ptee we emit our usual default maps. In all cases we add the "glue" of an new
attach map except in cases where a user has provided attach never. In cases where we are
provided an always, we apply the always map type to our attach maps.
It's important to note the runtime has a toggle for the auto map behaviour, which will flip the
attach behaviour to the newer semantics or the older semantics for backwards compatability (outside
the purview of this PR but good to mention).
