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. >> >> + >> >> + *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
