[flang] Add policy-driven allocation-placement pass
Introduce a new function-level pass, allocation-placement, that unifies the
stack/heap placement decisions currently split between the stack-arrays and
memory-allocation-opt passes. For each array allocation it consults a policy
to decide whether it should live on the stack (fir.alloca) or the heap
(fir.allocmem) and rewrites it accordingly, reusing fir::replaceAllocas for
stack-to-heap and the StackArrays analysis/rewrite for heap-to-stack (so
heap-to-stack only happens where it is provably safe).
The default policy (AllocationPlacementPolicy.h) is threshold-driven:
- small constant-size arrays go on the stack within a per-function stack
budget, otherwise on the heap;
- big constant-size arrays: user variables stay on the stack, temporaries
go on the heap;
- runtime-sized arrays go on the heap;
- an aggressive mode places all arrays on the stack (best effort).
User variables are distinguished from compiler temporaries via the presence
of a uniqued name. A hook lets downstream users override the thresholds per
[4 lines not shown]
AMDGPU: Reland: Codegen for v_dual_dot2acc_f32_f16/bf16 from VOP3
For V_DOT2_F32_F16 and V_DOT2_F32_BF16 add their VOPDName and mark
them with usesCustomInserter which will be used to add pre-RA register
allocation hints to preferably assign dst and src2 to the same physical
register. When the hint is satisfied, canMapVOP3PToVOPD recognises the
instruction as eligible for VOPD pairing by checking if it is VOP2 like:
dst==src2, no source modifiers, no clamp, and src1 is a register.
Mark both instructions as commutable to allow a literal in src1 to be
moved to src0, since VOPD only permits a literal in src0.
Original patch had a bug where it did not check if physical src
registers match register class of appropriate operand in fullVOPD
instructions, check is now done via isValidVOPDSrc.
AMDGPU: Validate VOPD/VOPD3 physical source registers against operand RC
Replace isVGPR checks with isValidVOPDSrc that validates physical source
registers against the actual combined VOPD/VOPD3 instruction's operand
register classes. Now we also validate operands for VOPD instructions.
[SCEV] Derive element size from the access's own pointer address space (#209824)
ScalarEvolution::getElementSize always derived the element-size SCEV
using a generic address-space-0 pointer index type. On targets whose
data layout uses different pointer index widths per address space (for
example, where some address spaces use 32-bit pointers and others
64-bit), a load/store through a narrow address space produced an access
function SCEV of one width but an element-size SCEV of another.
Delinearization then called SCEVDivision::divide with numerator and
denominator of mismatched types, tripping the assertion added in
a9d295d615a8 once the implicit sign-extension was removed in
23a32bcedb91.
Derive the index type from the memory access's actual pointer operand
address space so the element-size SCEV matches the width of the access
function's SCEV.
[flang] Fold reads of fir.create_box components (#210388)
Fold fir.box_addr and constant-dimension fir.box_dims of a descriptor
built by fir.create_box back to the operands that built it, so the
create_box can die when nothing consumes it as a real descriptor.
fir.array_coor is intentionally not folded through create_box, since
that would drop its explicit byte strides.
Assisted-by: Cursor
mk: stop passing relro linker flags to compiler
The relro flags are added to LDFLAGS, and that should be sufficient.
Packages not honoring LDFLAGS need to be fixed anyway, and clang
complains about the flags on the compiler command line.
On second thought, don't use __mc68010__ throughout as a proxy for
"is a Sun-2"; it's too easy to glance-misread #ifdef vs #ifndef.
Instead, define IS_SUN2 and IS_SUN3 macros that statically evaluate
to the right thing and use them throughout.
Re-commit: [GVN] Remove the "private" `llvm::gvn` namespace (NFC) (#210712)
Re-commit of https://github.com/llvm/llvm-project/pull/210323 after
adding
a forward declaration for GVNLegacyPass class to work around GCC
compilation
failure.
Move `AvailableValue` and `AvailableValueInBlock` into GVNPass, similar
to other helper types.
Retain `llvm::gvn::GVNLegacyPass` as just `llvm::GVNLegacyPass` -
"legacy" is already a sufficent hint and it is not going to become more
"private" by stacking "gvn" prefixes to the name.
Ideally, `GVNLegacyPass` should be defined in an anonymous namespace,
but
that is not possible because it is declared as a friend of GVNPass.
[NVPTX] Clear unsafe kill flags in NVPTXProxyRegErasure (#198143)
Fixes #198142
After replacing regsiter, stale `killed` flags my leave on non-terminal
uses, breaking liveness and triggering MachineVerifier errors.
Fix this by conservatively dropping the `killed` flag on `ToReg`.
Accept a pydantic model or dict in pylibvirt_vm/pylibvirt_container
## Context
Every lifecycle and delete caller had to hand-dump its model before calling these helpers, and for VMs that dump had to pass `expose_secrets=True` or the display device's `Secret` password would be silently redacted and a broken domain shipped. Leaking that invariant to each call site was repetitive and easy to get wrong.
## Solution
`pylibvirt_vm` and `pylibvirt_container` now accept either a pydantic model or a dict and do the `model_dump` internally — VMs with `expose_secrets=True`, containers with a plain dump. Callers pass the model directly, so the secret-exposure rule lives in one place. The state-gathering factories in `extend_context_sync` keep passing their raw pre-extend rows through the dict branch, since no full model exists yet at that point.
Ensure that we properly propagate template decl attributes to redecls (#209873)
Variable and class templates weren't forwarding their declaration
attributes that were attached directly to them (at the moment, the only
one I could find that had this issue is the no_specialization attr). The
result was that intermediate redeclarations would prevent the
diagnostics from happening.
This patch ensures we propagate them properly for variable and class
templates. It seems our function templates already do the right thing.
Fixes: #209812
