[SPIR-V] Avoid crash on malformed mangled builtin name length (#207939)
Replace the assert on invalid length parsing with a graceful bail-out
since malformed names can potentially come from outside, it is not
necessarily always an error
All usages of `getOclOrSpirvBuiltinDemangledName` are being checked for
emptiness where it is needed anyway
[Clang] Fix null-pointer assertion reading CtorClosureDefaultArgs (#207917)
BuildCtorClosureDefaultArgs deliberately leaves the first default-arg
slot null for MS ABI copy-constructor closures (the closure itself
supplies that argument), and ASTWriterDecl.cpp serializes the null. But
e7924d50db0a deserialized it with cast<>, which asserts on null. This
only triggers under the MS C++ ABI, e.g. when throwing a class with a
non-trivial copy constructor by value across a PCH boundary, as in test
https://github.com/intel/llvm/blob/cb9b7b7/clang-tools-extra/clangd/test/sycl.test
Assisted by: Claude
AMDGPU: Replace tgsplit subtarget feature with attribute (#204216)
This is a per-entrypoint property and has a corresponding
assembler directive, so it should not be baked into the
subtarget. I couldn't find much documentation on what this
actually does, so the description isn't great.
Fixes #204149
Co-authored-by: Claude Opus 4.6 <noreply at anthropic.com>
[clang][bytecode] Add more checks for pseudo dtors (#207959)
Rename the `EndLifetimePop` op (which was only used for pseudo dtors) to
`PseudoDtor` and call `checkDestructor()` in there, so we get the full
suite of checks.
[libc] Implement if_nametoindex and if_indextoname (#206082)
This patch implements if_nametoindex and if_indextoname for Linux.
Both functions work by creating a temporary AF_UNIX socket and issuing
ioctl calls (SIOCGIFINDEX and SIOCGIFNAME, respectively).
The main implementation details:
- for if_nametoindex, I check that the interface name fits within
IF_NAMESIZE before issuing the ioctl
- for if_indextoname, if the kernel returns ENODEV for an unknown index,
I map it to ENXIO to comply with POSIX requirements
- added the definition of struct ifreq to support these operations.
Similar to the other net structure definitions, I'm using an anonymous
union to avoid #defining members.
Assisted by Gemini.
[clang][bytecode] Fix getting typeid pointers of struct fields (#207946)
`getDeclPtr()` will return the declaration pointer, which might be
unrelated to the pointer we actually care about.
[NFC][mlir][bufferization] Align alloc/memcpy/cast options hooks to the rest (#206966)
There are three hooks that have a different, more complicated API than
the other ones: allocationFn, memCpyFn, castFn. All three are called via
"helper" functions that check whether the hooks are set to call them and
fall back to default implementations otherwise.
Other hooks (e.g. unknownTypeConverterFn) in the bufferization options
have a different "API": they are always set to some default
implementation and can be overwritten by the user. This is a simpler API
overall and seems it can be universal.
Note for LLVM integration: BufferizationOptions::{createAlloc,
createMemCpy, createCast} functions are "replaced" with direct calls to
the underlying std::function objects. At any call-site that relied on
any of the removed APIs, a call to the respective hook should now be
used instead. The exception is the `allocationFn` hook which needs an
explicit "bufferAlignment" parameter. Beforehand, it was implicitly
taken from BufferizationOptions::bufferAlignment field, so a
[3 lines not shown]
[libc] Add inet_ntop (#204143)
The function converts from IPv4/6 addresses to their string forms. The
complication comes from the v6 part due to address compression and
v4-mapping.
The traditional implementation of this is to sprintf the address into a
temporary buffer. We cannot do that here due to the ban on calling other
entry points. Using the lower-level constructs is possible, but a
straight forward application of IntegerToString does not result in
particularly impressive performance: 50%-100% slower than what's in this
patch (and slower than glibc). It also doesn't make the code much
smaller as the majority of it is dedicated to v6 compression.
The IPv6 implementation uses a temporary buffer, but it also has a
fast-path which skips the buffer if its size is guaranteed to be
sufficient. The IPv4 implementation also has a fast path, but the
fallback here is to compute the precise length of the string instead
(the buffer option was slower and IPv4 makes it easier to compute the
[10 lines not shown]
[AArch64][llvm] Restrict luti6 (4 regs, 8-bit) to 0 <= Zn <= 7
The `luti6` instruction (table, four registers, 8-bit) should only
allow `0 <= Zn <= 7`, since there's only 3 bits. It actually allows:
```
luti6 { z0.b - z3.b }, zt0, { z8 - z10 }
```
which produces a duplicate encoding to the following:
```
luti6 { z0.b - z3.b }, zt0, { z0 - z2 }
```
Fix tablegen to ensure Zn is only allowed in correct range of 0 to 7.
[AMDGPU] Save entry EXEC in whole-wave prologue with no WWM spills (#207924)
PR #207781 replaced the prologue S_XOR_SAVEEXEC (which set EXEC to
~entryEXEC) with a plain S_MOV EXEC, -1, but dropped the save of the
entry EXEC that the return restores from, leaving an undefined register
read
se S_OR_SAVEEXEC to both save entry EXEC and set EXEC to -1
[AArch64] llvm-mca C1-Ultra tests: SVE instructions added by SME when not streaming [NFC] (#207948)
In the C1-Ultra llvm-mca test, moves some instructions that were
incorrectly in the test file for "Instructions available with no SME but
will be sent to CME when in streaming SVE mode" into a file specifically
for instruction that are "SVE instructions added by SME and available
when not in Streaming SVE mode".
This is in preparation for forthcoming C1-Nano SME support to the
scheduling model that currently has no information about these
instruction due to lack of information in the C1-Nano SWOG.
This change is currently NFC because the C1-Ultra is still running the
the same tests, just from different test files.
AMDGPU: Migrate unittests to subarch triples
Replace specifying a processor name with the triple
subarch.
The register-limit helpers in AMDGPUUnitTests.cpp that enumerate every
valid CPU via fillValidArchListAMDGCN still pass the CPU explicitly, as
does the MC Disassembler smoke test (its C disassembler API derives the
subtarget from the CPU, not the triple subarch).
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
clang: Start using new amdgpu subarch triples
Fixup invocations using --target=amdgcn + -mcpu to introduce
the subarch in the triple.
For offload toolchains, a single toolchain is constructed for the
top level amdgpu architecture, and the effective triple is used for
target specific tool invocations.
The specifics of the resource directory layout are tbd. This does
try to find resources in the subarch named directory. The paths
are searched at toolchain creation time, so that does not work
when there are multiple subarches.
Fixes #154925
clang/AMDGPU: Validate -target-cpu in cc1 is valid for the subarch
Restrict the reported list of valid target-cpus based on the triple's
subarch. This is more consistent with how other targets validate the
target CPU name. Currently we have split handling validating the target
name for the triple in both the driver and here. The driver based diagnostic
seems to be an amdgpu-ism in 2 different places (though there is one arm
validation emitting the same diagnostic). In the future we could probably
drop those.
clang/AMDGPU: Stop passing redundant -target-cpu to cc1
Now that the exact target is encoded in the triple's subarch field,
-target-cpu is redundant. This avoids polluting the resultant IR with
unwanted "target-cpu" attributes. The net result is the desired codegen
when compiling libraries for a major subarch and linking it into a
program compiled for a specific arch. e.g., compiling for "gfx9-generic"
would pollute the IR with "target-cpu"="gfx9-generic", so codegen
would ultimately be performed for the generic target even after
linking into the concrete gfx9 cpu. The specialization will now be
achieved by merging the triples without the linker or optimization
passes needing to fixup function attributes.
AMDGPU: Introduce amdgpu triple arch
Move towards using the triple for representing incompatible
ISA changes. Use the subarch field to represent the various
incompatible cases. Previously we pretended a single triple arch
was universally compatible, and only distinguished by function
level subtargets. Move towards using distinct triples to enable
more sophisticated toolchain handling in the future, like proper
runtime library linking.
Introduce a new subarch per unique ISA, but also introduce
"major subarches" which are compatible by a set of covered
minor ISA versions. These map to the existing generic targets.
There are a few placeholder subarch entries, which currently
have missing backing generic arches for codegen.
This should be the preferred triple arch name going forward,
but is treated as an alias of amdgcn. This does not yet change
clang to emit the new triples.
[2 lines not shown]