[VPlan] Use subpattern-m_VPValue in simplifyRecipe (NFC) (#213268)
Use the subpattern variant of m_VPValue introduced in 8db13de ([VPlan]
Remove redundant x && (y && x) -> x && y combine, #213219) to improve
code in simplifyRecipe.
[RISCV] Fix incorrect lowering of VECTOR_INTERLEAVE on fixed vectors (#212642)
This is the sibling patch of #207254, as it turns out VECTOR_INTERLEAVE
has the same problem on fixed vectors as well.
Instead of converting individual operands into scalable vectors, this
patch puts each of the operands directly onto stack using the fixed
vector version of segmented store intrinsics, before loading them back.
---------
Co-authored-by: Luke Lau <luke at igalia.com>
[libc] Fix math failures for fmod on NVPTX (#213168)
Summary:
Fixes some failing tests. Fmod's builtin has improper handling in the
NVPTX instruction so we should just use the generic version for now. The
Float128 implementation seems to have had some undefined behavior for
out of range behavior that only showed up now. Hopefully someone can
tell me if this is fixed correctly.
[CIR] Accept _BitInt up to 128 bits in x86_64 callconv lowering (#212668)
The x86_64 bridge in `CallConvLoweringPass.cpp` rejected every
`_BitInt`, so a function taking or returning one reported NYI even
though the ABI library already classifies these types. The classifier
has to be told the integer is bit-precise, and `mapCIRType` was dropping
that flag, which its two-eightbyte handling keys on. With the flag
forwarded, accepting widths up to 128 is mostly a matter of letting the
classifier's answer through. Wider widths stay rejected, for the reason
on the accept check.
Relaxing that check alone was not enough. `convertABIArgInfo` discarded
the classifier's coerce for every non-aggregate, which would have left a
`_BitInt(33)` as i33 where classic CodeGen passes i64. It now takes the
coercion path for a multi-register tuple coerce and for one wider than
the natural type. A narrower or equal coerce still means unchanged,
which is what preserves a `_BitInt(128)`'s 8-byte alignment.
Two `noundef` gaps against classic CodeGen remain. Neither mechanism is
[3 lines not shown]
[HashRecognize] Prevent values other than `ComputedValue` from exiting loop (#213080)
A check exists to prevent recurrences from having stray uses, but this
is only applied when a simple recurrence exists, and does not apply to
other values such as the induction variable. Since the loop is in LCSSA
form, check the incoming value from the loop on each of the exit block
PHIs and bail if any of them are not `ComputedValue`.
This replaces the existing check requiring `ComputedValue` to be used in
the exit block. Note that this no longer covers the case where the exit
block has no PHIs, and therefore does not use `ComputedValue`. In this
case, the loop is dead and will be cleaned up by DCE anyway.
AMDGPU: Add missing mqsad-insts to gfx13 frontend feature map (#213292)
fillAMDGCNFeatureMap omitted mqsad-insts for gfx1310/gfx13-generic, so
clang wrongly rejected __builtin_amdgcn_mqsad_u32_u8 on those targets
even though the backend enables the feature. Add it to the gfx13 case.
Co-authored-by: Claude (Claude-Opus-4.8)
[libc] Add SIGPOLL si_code values. (#212873)
This is a follow-up to efc78d2029b9f716de4546ed88571616d91e826c, which
adds `si_code` values for the `SIGPOLL` signal on Linux.
[AllocToken] Merge !alloc_token metadata across optimization passes (#211516)
Previously, optimization transforms like DeadStoreElimination (folding
malloc to calloc), SimplifyLibCalls (folding realloc(null, n) to
malloc), and combineMetadata (merging equivalent allocations in
GVN/SimplifyCFG) dropped !alloc_token metadata or stripped it when type
names differed. This caused allocation sites of pointer-containing types
to lose their metadata.
Fix it by implementing MDNode::getMergedAllocTokenMetadata() to merge
!alloc_token metadata by ORing the pointer-containing boolean flag and
concatenating type names with a pipe separator, updating combineMetadata
to use it, and preserving !alloc_token metadata when folding allocation
libcalls in DSE and SimplifyLibCalls.
Assisted-by: Antigravity:gemini
AMDGPU: Export the TargetParser feature bitset
Previously this bitset was only used to populate the feature
name string map used by clang. Eventually this will replace
the current bitmask integer. AArch64 already has a similar
interface.
Co-authored-by: Claude (Claude-Opus-4.8)
AMDGPU: Tablegenerate TargetParser feature sets
Traditionally we maintained 2 parallel feature mechanisms,
one in clang (later moved to TargetParser), with largely
mirrored subtarget features defined in the backend. Start
directly taking feature information from the backend and putting
it into TargetParser. This is still in a compromise mid-migration
state. We still have both the legacy "ArchAttr" bitfield integer,
plus a new AMDGPUFeatureBitset field stored in the table, which
isn't yet exported.
For the moment, the new bitset is only used to populate the
feature string name map, which is the big maintainability win.
This also lists an explicit subset of exported features to
avoid churn.
Co-authored-by: Claude (Claude-Opus-4.8)
[clang][DependencyScanning] Relocate CompilerInstanceWithContext to DependencyScanningWorker.cpp (#211407)
This PR relocates all `CompilerInstanceWithContext` code to
`DependencyScanningWorker.cpp` and hides them as implementation details,
since no public APIs should use `CompilerInstanceWithContext` directly.
---
<sub>Stack created with <a
href="https://github.com/github/gh-stack">GitHub Stacks CLI</a> • <a
href="https://gh.io/stacks-feedback">Give Feedback 💬</a></sub>
[clang][DependencyScanning] Implement the Streaming Style By-name Scanning API (#211406)
This PR implements a streaming stype by-name scanning API. The new API
takes a `DependencyConsumer`, a `DiagnosticsConsumer` and a
`getNextName` lambda. Any diagnositcs flow to the `DependencyConsumer`,
and the results flows to to `DependencyConsumer`. The `getNextName`
lambda is allows the client to stream names into the API, and the API
keeps scanning dependencies for input names until `getNextName` does not
return more names.
rdar://178088113
---
<sub>Stack created with <a
href="https://github.com/github/gh-stack">GitHub Stacks CLI</a> • <a
href="https://gh.io/stacks-feedback">Give Feedback 💬</a></sub>
[SSAF] Close unsafe-buffer reachability over override families
An unsafe pointer reaching one override's parameter is equally unsafe in every
sibling and base override of that method, because the call site picks the
target dynamically. Without closing over the families, reachability depended
on which override the extractor happened to see the flow through, so a fix
suggested for the base could be contradicted by a derived override.
Mirroring is level-preserving: families relate slot entities, so a reachable
EPL propagates only to the same pointer level on its family members.
The closure runs after the pointer-flow DFS has converged and does not feed
its own output back in, so a flow edge out of a newly discovered EPL is still
missed. FamilyClosureDoesNotRerunDFS pins that gap.
§4 of rdar://179151603
[SSAF] Serialize virtual method summaries and families
Per-TU summaries and whole-program results cross process boundaries, and the
JSON layer refuses to write a summary kind it has no format for. Register both
sides so --ssaf-extract-summaries=VirtualMethod becomes usable and the family
result survives a round trip.
Deserialization tolerates a missing override list, since a root virtual method
legitimately has none.
§3 of rdar://179151603
[SSAF] Group virtual method slots into override families
A virtual call site can dispatch to any override, so the parameter and return
slots that occupy the same vtable slot across an override chain are
indistinguishable to a caller. Whole-program consumers therefore have to treat
them as one unit or they will reason about a slot that a call never actually
reaches.
Compute those units up front, keyed per slot, so consumers only need a map
lookup rather than their own traversal of the override relation. Overloads
occupy distinct vtable slots and stay in distinct families.
The family representative is the smallest EntityId in the class, which keeps
the result stable across runs.
§2 of rdar://179151603
[SSAF] Extract the virtual method override relation per TU
A virtual call may dispatch to any override of its callee, so a whole-program
analysis cannot reason about a method's parameters and return value in
isolation. It needs to know which method overrides which, and which slots
that relates. Collect this per TU, so a later pass can join the related
slots into families.
JSON serialization lands separately, so the summary is not writable via
--ssaf-extract-summaries yet.
§1 of rdar://179151603
[LoopIdiom] Use costing to determine CRC strategy (#211040)
The CRC loop clmul optimization currently only runs under optsize,
despite being significantly faster than the Sarwate table optimization
in many cases. Model the costs of each approach and weigh them against
each other to determine which optimization should be used. Since the
benefits of clmul are unclear for optsize, simply bail in that case
instead.
Assisted-by: Claude Opus 4.8
[Webkit Checkers][SaferCpp] Detect implicit `id`-to-specific-type casts in MemoryUnsafeCastChecker (#213113)
Flag arguments of type `id` implicitly converted to a specific
Objective-C pointer type at a call, message send, or constructor call
(e.g. passing `id` where an `NSString *` parameter is expected). These
conversions compile without a visible cast but throw at runtime if the
object is not actually of that type.
rdar://148708396
AMDGPU: Add missing mqsad-insts to gfx13 frontend feature map
fillAMDGCNFeatureMap omitted mqsad-insts for gfx1310/gfx13-generic, so
clang wrongly rejected __builtin_amdgcn_mqsad_u32_u8 on those targets even
though the backend enables the feature. Add it to the gfx13 case.
Co-authored-by: Claude (Claude-Opus-4.8)
AMDGPU: Separate image_msaa_load from bvh-ray-tracing-insts
Add a separate msaa-load-insts feature so image_msaa_load is available on
gfx13, which has it but not the BVH intersect-ray instructions. These were
assumed to be the same feature previously, but gfx13 does not have the bvh
instructions, but does have image_msaa_load.
Co-authored-by: Claude (Claude-Opus-4.8)
AMDGPU: Do not give gfx12.5 bvh-ray-tracing-insts (#213246)
bvh-ray-tracing-insts was listed in the FeatureGFX12 generation, so
gfx1250/gfx1251/gfx12-5-generic inherited it even though they have no
BVH. Move the feature out of the common base and into FeatureISAVersion12.
This stops clang from wrongly accepting __builtin_amdgcn_image_bvh_intersect_ray*
on gfx1250.
Co-authored-by: Claude (Claude-Opus-4.8)
