[AArch64][DAG] Use getSetCCResultType in PromoteSETCC (#198320)
During the promotion of a v16bf16 vector setcc with 256 bit sve, a
v16i16 setcc(v16f32) is created, that gets legalized to a v8i16
setcc(v8f32), which trips up an assert in the aarch64 custom lowering to
vector registers. It could be solved elsewhere but this addresses it by
making sure that when the f32 setcc is created, the result type matches
getSetCCResultType.
The mvn+xtn vs xtn+mvn is mostly benign, and should both probably be a
subhn if it can be done without causing regressions.
[clang] fix getTemplateInstantiationArgs
This implements a new strategy for collecting the template arguments, by
relying on the qualifiers and template parameter lists to navigate the template
context of out-of-line definitions.
This greatly simplifies the signature of that function, by removing a bunch
of workarounds, and simpliffying a couple that weren't removed yet.
Since this now relies on qualifiers and template parameter lists,
this patch expends most of its effort making sure these are placed,
transformed and propagated to template instantiations.
Also makes the explicit specialization AST nodes stop abusing the template
parameter lists by storing it's own template parameter list, creating a
dedicated field for them, similar to partial specializations.
[lld][macho] Restructure thunk generation algorithm (#193367)
Refactor the algorithm that generates thunks for Mach-O. Prior to this
PR, sections were finalized as early as possible while still leaving
enough room (`slopScale * thunkSize`) for new thunks to be created.
There was also additional bookkeeping
(`estimateBranchTargetThresholdVA()`) so that once all sections were
finalized, we could estimate the end of the stubs sections. This avoided
new thunks to stubs sections in some cases.
In this PR, I've restructured the algorithm to avoid eagerly finalizing
sections. Instead, I maintain a `branchesToProcess` queue to hold
branches that could need to use a thunk. I avoid processing this branch
until its target has been finalized, or if finalizing another section
not leave enough room for new thunks (computed using `slopScale`). This
increases the likelihood that a branch will be direct, rather than use a
thunk, as reflected in the test change. Once all sections are finalized,
we can compute an upper bound on the number of thunks that need to be
created. We use this to estimate the end of the stubs section, allowing
[10 lines not shown]
[GlobalsModRef] Don't erase while iterating (#199656)
The loop erases from AllocsForIndirectGlobals while walking it, which
now hits the iterator invalidation assert in DenseMap::erase. Use
remove_if instead.
Started with https://github.com/llvm/llvm-project/pull/199369.
[ORC] Avoid iterator invalidation when erasing image info symbols (#199655)
processObjCImageInfo iterated the section's DenseSet of symbols while
calling removeDefinedSymbol, which erases from that same set. Re-fetch
begin() each iteration so the iterator is always fresh.
Started with https://github.com/llvm/llvm-project/pull/199369.
NAS-140925 / 26.0.0-RC.1 / fix HA validation error (by yocalebo) (#19014)
## Fix DHCP/IPv6-auto validation misfire on fresh HA installs
The HA validation in `interface.update` (network.py line 1253) was
reading
`new.get('ipv4_dhcp')` and `new.get('ipv6_auto')`. Because
`iface_extend`
synthesises `True` for these fields when no interface has a datastore
config yet (the first interface configured on a fresh install), the
merged `new` dict carries that synthetic True forward and fires the
"Enabling DHCPv4/v6 on HA systems is unsupported" error even when the
API caller never touched those keys.
Switched the check to `data.get(...)` so it only fires when the caller
is explicitly setting either field to a truthy value, which matches the
wording of the error message.
### Behavioral change
[12 lines not shown]
NAS-140925 / 26.0.0-BETA.2 / fix HA validation error (by yocalebo) (#19013)
## Fix DHCP/IPv6-auto validation misfire on fresh HA installs
The HA validation in `interface.update` (network.py line 1253) was
reading
`new.get('ipv4_dhcp')` and `new.get('ipv6_auto')`. Because
`iface_extend`
synthesises `True` for these fields when no interface has a datastore
config yet (the first interface configured on a fresh install), the
merged `new` dict carries that synthetic True forward and fires the
"Enabling DHCPv4/v6 on HA systems is unsupported" error even when the
API caller never touched those keys.
Switched the check to `data.get(...)` so it only fires when the caller
is explicitly setting either field to a truthy value, which matches the
wording of the error message.
### Behavioral change
[12 lines not shown]
NAS-140925 / 25.10.4 / fix HA validation error (by yocalebo) (#19012)
## Fix DHCP/IPv6-auto validation misfire on fresh HA installs
The HA validation in `interface.update` (network.py line 1253) was
reading
`new.get('ipv4_dhcp')` and `new.get('ipv6_auto')`. Because
`iface_extend`
synthesises `True` for these fields when no interface has a datastore
config yet (the first interface configured on a fresh install), the
merged `new` dict carries that synthetic True forward and fires the
"Enabling DHCPv4/v6 on HA systems is unsupported" error even when the
API caller never touched those keys.
Switched the check to `data.get(...)` so it only fires when the caller
is explicitly setting either field to a truthy value, which matches the
wording of the error message.
### Behavioral change
[12 lines not shown]
NAS-140925 / 27.0.0-BETA.1 / fix HA validation error (#19010)
## Fix DHCP/IPv6-auto validation misfire on fresh HA installs
The HA validation in `interface.update` (network.py line 1253) was
reading
`new.get('ipv4_dhcp')` and `new.get('ipv6_auto')`. Because
`iface_extend`
synthesises `True` for these fields when no interface has a datastore
config yet (the first interface configured on a fresh install), the
merged `new` dict carries that synthetic True forward and fires the
"Enabling DHCPv4/v6 on HA systems is unsupported" error even when the
API caller never touched those keys.
Switched the check to `data.get(...)` so it only fires when the caller
is explicitly setting either field to a truthy value, which matches the
wording of the error message.
### Behavioral change
[8 lines not shown]
[MLIR][XeGPU] Clone trivial operations with multiple consumers in layout propagation to avoid layout conflict (#197514)
In XeGPU layout propagation, when a trivially rematerializable producer
(e.g. a CSE-merged vector.step) has multiple uses demanding distinct
layouts, clone the producer once per required layout so each def retains
a single well-defined layout. This avoids inserting a bridging
xegpu.convert_layout whose WG-to-SG lowering would otherwise force a
costly SLM round-trip to redistribute data across subgroups.
[clang] fix getTemplateInstantiationArgs
This implements a new strategy for collecting the template arguments, by
relying on the qualifiers and template parameter lists to navigate the template
context of out-of-line definitions.
This greatly simplifies the signature of that function, by removing a bunch
of workarounds, and simpliffying a couple that weren't removed yet.
Since this now relies on qualifiers and template parameter lists,
this patch expends most of its effort making sure these are placed,
transformed and propagated to template instantiations.
Also makes the explicit specialization AST nodes stop abusing the template
parameter lists by storing it's own template parameter list, creating a
dedicated field for them, similar to partial specializations.
