On Mon, Aug 03, 2026 at 11:21:06PM +0200, Aldy Hernandez wrote:
> On Mon, Aug 03, 2026 at 11:59:13AM +0200, Jakub Jelinek wrote:
>
> > I'm surprised float_widen_lhs_range hasn't been changed for this.
> > When we support 2 pairs, I think we need to widen each pair individually
> > and then combine them in case the widening would now cause overlap etc.
>
> Probably cause it didn't show up in any missing optimizations for the
> DOM audit I did :-P. But TBH, I didn't convert any range-ops operators to
> multi-range.
>
> However, float_widen_lhs_range seems simple enough. If we refactor
> the bounds logic out, the change seems very simple. See attached two
> patches.
>
> I'm flying blind here (i.e. I have no clue), so I'm *NOT* committing
> this.
>
> I've tested on ppc64le, but will only push if you review and approve
> it :).
Both patches LGTM, ok for trunk.
Thanks.
As for ops, guess the easiest would to change range_operator::fold_range
to iterate over the pairs with rv_fold first, that would cover quite a lot,
but then we have tons of ops which don't use that (especially reverse ones).
Something I've been touching recently are e.g. the int -> float casts,
there I think having more than one pair would be quite frequent (if the
integer range has more than one pair).
Jakub
