On 07/07/2026 14:02, Richard Sandiford wrote:
Tamar Christina <[email protected]> writes:
+{
+ unsigned int const_vg;
+ if (aarch64_sve_vg.is_constant (&const_vg))
+ {
+ *min_val = val.coeffs[0];
+ *max_val = *min_val;
+ return true;
+ }
This shouldn't be necessary as things stand. We don't use poly_ints
when the VL is known. If at some point in the future we allow the
constant VL to be changed per-function (sounds difficult), we should
probably have hooks specifically for that.
I must admit I didn't check, but I had assumed we could with something
like FMV.
Not that I'm aware. FMV can't do anything that a target attribute
couldn't do.
FMV for specific vector lengths is something we are interested in
adding, this is important for intrinsics such as svmmla_f64 which
require certain vector lengths.
However, I agree that it likely will be challenging...
+
+ *min_val = val.coeffs[0];
+ *max_val = val.coeffs[0] + val.coeffs[1] * 15;
In a ranger context, we need to be careful about overflow. The calculation
should saturate rather than wrap.
Having a hook based on indeterminate ranges rather than poly_int ranges
would leave that up to target-independent code, rather than being something
that AArch64 and RISC-V have to duplicate.
Ok, so just have one hook that returns the indeterminate (N) and move
the logic
into the call site in ranger? So that can just return unsigned
HOST_WIDE_INT with
-1 being VARYING?
Yeah, sounds good. Using -1 as a wildcard matches what we do for
the size/range poly-int.h functions.
But maybe the hook should return a poly_uint64, with coefficient 0 being
ignored. That would cope with multiple indeterminates (which most code
does try to support, even though that hasn't been used yet).
Richard
