AMDGPU: Respect target assembler directives over command line
Mutate the global subtarget, using essentially the same code that ARM uses.
The main difference is we need to mutate the actual CPU name in addition
to just flipping the feature bits, so this needs a new setter in
MCSubtargetInfo. Liberalize the triple check so that after #206480,
old assembly files to not break on new assembler invocations.
For some reason we have 2 different assembler directives that indicate the
target, .amdgcn_target for amdhsa and .amd_amdgpu_isa for amdpal. Previously,
we would take the target from the command line and then error if the directive
did not exactly match. In order to move away from depending on the xnack and
sramecc subtarget features, start treating the directives as a change of target,
similar to ARM's .cpu and .arch directives.
Both .amdgcn_target and .amd_amdgpu_isa encode full triples, but unlike
.amdgcn_target, the PAL directive does not include xnack or sramecc. Ideally
we would introduce new independent directives for these.
Co-Authored-By: Claude Opus 4.6 <noreply at anthropic.com>
java/eclipse-ecj: deprecate and expire in 4 months
No maintainer, last update was 2015, does not build with Java 11, only usage in the ports tree (math/scilab) was just deprecated.
Approved-by: no maintainer
BPF: Fix misfolding subregisters (#208244)
This would end up introducing a copy between registers
with mismatched sizes previously. Defends against verifier
failures in a future change.
The actual transform here should be deleted. Optimizations should
not be trying to introduce SUBREG_TO_REG.
math/scilab*: deprecate and expire in 4 months
No maintainer, old version, did not keep up with upstream, does not build with Java 11 or at all.
Please mail the maintainer if you use this.
Reported-by: https://portsfallout.com/fallout?port=math%2Fscilab
Approved-by: no maintainer
[scudo] Small refactor of getTSDXXX functions. (#208127)
Small modification in getTSDAndLock() to have a single shared TSD avoid
the tryLock call. Also, remove some unnecessary comments.
Add a DCHECK in getTSDSlow and only check for == 1 since a 0 number of
shared TSDs is not supported.
AMDGPU/GlobalISel: Switch to extended LLTs
IRtranslator now translates bfloat. Switch tablegen to use extendedLLTs.
Around 300 regression tests fail to inst-select because GIM_SwitchType
does not accept LLT::scalar. Around 100 mir inst select tests had input
updated to i32/f32 and select successfully. Then there are 24 various
crashes, mostly combiner or machine-verifier, those tests are disabled.
Most problems come from mixing s32 with i32/f32 and the way operator==
works with extendedLLTs compared to GIM_SwitchType.
In general, for inst-select fixes, I think it would be best to avoid
explicit use of LLT::scalar in lowering to avoid mixing it with
LLT::integer/LLT::float See inst-select-extendedLLTs.mir and
inst-select-extendedLLTs-err.mir.
Change-Id: I045125c53ee9bb572fa048be739b56e1169600d2
ld.so/sparc64: preserve unaligned relocation byte order
The unaligned relocation path reconstructs the relocation target in
SPARC byte order, but writes the adjusted value back least significant
byte first; this reverses R_SPARC_UA64 results on a big endian target.
Write the value back in target byte order, so relocated function
pointers retain their canonical representation.
Tested by tb@, OK: kettenis@
ld.so/sparc64: fix UA64 relocation mask selection
The relocation mask table is indexed by relocation number; the missing
separator after the R_SPARC_6 entry shifts subsequent initializers, so
R_SPARC_UA64 receives the R_SPARC_UA16 mask. Restore the table layout,
otherwise only the low 16 bits of relocated 64 bit pointers survive.
Tested by tb@, OK: kettenis@
[Clang] Fix crash involving `__attribute__((cleanup))` attributes and improve handling of multiple `cleanup` attributes (#207785)
Clang would previously crash on this code:
```c
#define C(x) __attribute__((cleanup(x)))
void foo(double *x) {}
void bar() { C(foo) C(foo) baz8; }
```
Here, we were trying to query properties of `VD->getType()`, which would
crash because type of the variable declaration is null here (because the
user didn’t write a type); avoid this by bailing out early if the
declaration is invalid.
Additionally, this patch fixes a GCC compatibility issue: in code such
as
```c
#define C(x) __attribute__((cleanup(x)))
void f1(double *x);
void f2(double *x);
[7 lines not shown]
[RISCV] Fix incorrect fixed vector lowering for VECTOR_DEINTERLEAVE (#207254)
Partially address #207136
Previously this part of the logic simply converts each operand into
scalable vector and pass on. This will run into problem when the
scalable vector container is larger than the actual fixed vector.
This patch fixes this issue by storing individual fixed vector operands
directly onto the stack, before loading them back with segmented load
just like its scalable vector counterpart
[clang] Fix crash in DiagnoseMissingSemiAfterTagDefinition for annot_template_id (#208119)
DiagnoseMissingSemiAfterTagDefinition checks whether the token after a
tag definition could be a scope specifier before calling
TryAnnotateCXXScopeToken. It accepted annot_template_id unconditionally,
but TryAnnotateCXXScopeToken asserts that MightBeCXXScopeToken() holds,
which only accepts annot_template_id when followed by ::.
When the token is annot_template_id not followed by :: (e.g. union { }
::foo<int>; where ::foo<int> is annotated as a template-id after a
missing semicolon), the check passes but MightBeCXXScopeToken() returns
false, firing the assertion.
This patch adds the same NextToken().is(tok::coloncolon) guard that
MightBeCXXScopeToken uses for annot_template_id.
Fixes #207992
---------
Co-authored-by: Corentin Jabot <corentinjabot at gmail.com>
[VPlan] Introduce VPlan-based hasTailFolded helper. (NFC) (#208329)
After having dedicated support for modeling the header mask of a region
created for tail-folding, add a new helper to query if a plan has it's
tail folded, i.e. it has a header mask (materialized or not).
Similarly to https://github.com/llvm/llvm-project/pull/207784, it also
adds a wrapper to LoopVectorizationPlanner that asserts that cost model
and VPlan decision agree. The wrapper should be removed after no
divergence are found.
PR: https://github.com/llvm/llvm-project/pull/208329
[SystemZ][z/OS] Move emission of PPA1
There is an interesting restriction during emission: emitting debug information closes the text section. As result, emitting the delayed PPA1 data does not work in the current place together with emitting debug information.
Since the PPA1 information is constant data, the solution is to emit the data in the target strreamer, in `emitConstantPools()`.
[X86] promote f16 `frexp` (#208530)
follow-up to https://github.com/llvm/llvm-project/pull/208462
Using the libcall reduces code size, gives identical output for the full
f16 range, and is apparently quite a bit faster
```
direct f16: 2.067486000 s for 1000 full-range iterations
via f32: 0.714443000 s for 1000 full-range iterations
```
bup: Rename -git to -snapshot
My opinion is that the point is not that bup is developed in git but
that the package is a snapshot of development rather than a release.
That's my story and I'm sticking with it at least all day today! But
seriously, it seems like a good plan in general.
[SampleProfile] Replace std::set with SmallVector in SortedCallTargetSet (NFC) (#208509)
This patch replaces std::set with SmallVector and llvm::sort in
SortedCallTargetSet and sortCallTargets.
Since the keys in CallTargetMap are already guaranteed to be unique,
using std::set for sorting allocates unnecessary tree nodes on the
heap.
This patch also removes unnecessary const from return-by-value types
to enable move semantics.
Assisted-by: Antigravity
runtimes: Don't set CMAKE_SYSTEM_NAME=Android
Cmake requires an NDK for android. Prior to 00b2f814182,
the default system name would be the host system. Take the
normal linux path, which is a more realistic approximation of
the old behavior.
[flang][Lower] Track whether a call to a function is to an intrinsic (#208000)
Add an attribute which indicates that a call is to an intrinsic
function. Intrinsic here means that the function declaration was found
in a module found in the intrinsic path.
This allows us to, when optimizing, make sure that we correctly identify
calls to intrinsic functions whose behaviours we know, and not
user-defined functions whose names happen to match.
