[AArch64][SME] Split FP8 FTMOPA intrinsics (#203310)
Introduce separate FP8 FTMOPA intrinsics for ZA16 and ZA32:
llvm.aarch64.sme.fp8.ftmopa.za16
llvm.aarch64.sme.fp8.ftmopa.za32
The FP8 FTMOPA forms need to model their FPMR dependency, so they should
not share the same intrinsic definitions as the non-FP8 FTMOPA forms.
Update the Clang SME builtin definitions and AArch64 instruction
patterns to use the new intrinsics, and add AutoUpgrade support for the
previous FP8-shaped llvm.aarch64.sme.ftmopa.* spellings so existing IR
and bitcode continue to work.
This was split out from #154144 because the intrinsic upgrade needs to
be handled separately to avoid breaking existing bitcode.
sysutils/mdfried: Update to 0.22.2
- Add option PDF (default ON) to enable support for PDF files
- Add a list of mdfried features to pkg-descr
Reported by: "github-actions[bot]" <notifications at github.com>
[CIR][AArch64] Lower NEON laneq FMA builtins (#202337)
Lower additional AArch64 NEON laneq fused multiply-accumulate builtins
in CIR.
This covers:
- `BI__builtin_neon_vfmaq_laneq_v`
- `vfmaq_laneq_f16`
- `vfmaq_laneq_f32`
- `vfmaq_laneq_f64`
- `BI__builtin_neon_vfmad_laneq_f64`
- `vfmad_laneq_f64`
For `vfmaq_laneq_v`, the lowering bitcasts the operands, splats the
selected lane source, and emits the `llvm.fma` intrinsic with the
operand order matching classic AArch64 CodeGen.
For `vfmad_laneq_f64`, the lowering extracts the selected lane from the
`float64x2_t` source and emits scalar `llvm.fma.f64`.
[7 lines not shown]
[CIR][AArch64] Lower NEON subtraction intrinsics (#202857)
### summary
part of : https://github.com/llvm/llvm-project/issues/185382
- Add CIR lowering for the scalar AArch64 NEON subtraction builtins
`vsubd_s64` and `vsubd_u64`.
- Verify that the remaining signed, unsigned, and floating-point
`vsub/vsubq` intrinsics are correctly expanded through arm_neon.h and
emitted as `cir.sub`.
Convert kmip plugin to typesafe pattern
This commit adds changes to convert the kmip plugin from the legacy dict-based ConfigService/CompoundService to the typesafe GenericConfigService pattern, with a ConfigServicePart, Pydantic models, and the internal ZFS/SED key-management machinery extracted into plain functions backed by an in-memory KMIPKeyStore. Since kmip.config now returns a model, in-process consumers in failover, the pykmip mako, pool encryption and the kmip pseudo-service are switched to attribute access, and the KMIP port delegate hands the base a dict so port validation keeps working.
[Dexter] Add condition check to state nodes
This patch enables the ability for state nodes to check conditions, meaning
they will be active only if the condition is met.
Condition evaluation is somewhat language specific; we directly check
whether the value of the evaluated expression is "true" (case-insensitive),
which works for the languages we actually use Dexter with, but may require
generalizing in future.
We also cache conditions as they are evaluated; each time we step, we clear
all cached conditions for the current frame and any expired frames, but we
keep the cached conditions for any frames rootwards from the current frame;
this prevents us from unexpectedly exiting out of a callee frame because of
debug info not surviving a stack unwind; if the early exit is desired, an
!and{at_frame_idx, condition} under the lower frame may suffice.
[Dexter] Enable after_hit_count for state nodes
The after_hit_count attribute for a state node causes it to become active
only after it would have become active N times. This uses the existing logic
for incrementing hit counts, i.e. after the node becomes "active", we will
not add another hit count until it stops being active for at least one step.
Since state nodes with after_hit_count do not become active before reaching
the required hit count, this requires us to keep track of an "early" set of
state nodes, meaning nodes that would be active if not for their
after_hit_count.
[Dexter] Add support for writing !step values
Following from the previous patch, this patch adds support to Dexter for
generating expected values for !step nodes. This is relatively limited:
the kind of !step which this is most well-suited to this is !step exactly,
as the !step order of ignoring extra lines is redundant (all lines are added
as expected values), and !step never can't know what lines could have been
stepped on but weren't without some extra work (e.g. finding viable
breakpoint locations in the enclosing state node).
[Dexter] Add !step node for testing stepping behaviour
This patch adds a node for generating metrics based on lines stepped on. The
new node has 3 versions: !step exactly, !step order, and !step never, which
check an expected list of line numbers against the actual line numbers seen
while the expect is active.
[tools] Register analyses correctly (#203808)
- Analyses with custom parameter must be registered before
register*Analyses, otherwise it will be skipped.
- Remove redundant LibcallLoweringModuleAnalysis, pass builder will
register it automatically.
