Re: [PATCH 1/2] [frange] Enable sub-ranges.

On Mon, Aug 03, 2026 at 09:14:44AM +0200, Aldy Hernandez wrote:
> Raise MAX_PAIRS from 1 to 2, enabling sub-ranges.  This will allow us
> to represent non-zero and other inequalities in a follow-up patch.
> 
> I tested how many sub-ranges would give us the most bang for the buck,
> by allowing 10 sub-ranges, and seeing how many we created and used.
> Even though 1 sub-range caught 91.29% of what we encountered in real
> life (well, in a corpus of Fortran files from the LAPACK package), we
> couldn't represent non-zero, which caused DOM to get a bunch of cases
> we missed.  With 2 subranges, we caught 99.63% of ranges generated,
> and anything past this was useless, cause we either didn't generate
> them in real life, or there was no change in generated code by having
> more sub-ranges.  For instance, from 3631 files, going from 2 to 3
> sub-ranges caused code generation changes in 4 files (all rotmg*).
> Going past 3, produced zero effect.
> 
> I also benchmarked LAPACK and the GSL package for jump threading
> changes as well as VRP constant propagation.  For LAPACK, we got 0.31%
> more jump threading opportunities, and for GSL 1.10%.  For VRP it was
> the opposite, LAPACK got 0.48% more constants propagated, whereas GSL
> got a mere 0.26% boost.
> 
> This may not seem like much, but just being able to represent the
> inverse of a constant (e.g. nonzero) closes the gap with the DOM
> internal tables.  With this work, we get 100% of what DOM threading
> was getting with its internal tables for the LAPACK corpus.  We nuked
> 58 of the regressions, and I believe this will fix a few PRs we had
> open for nonzero folding, as well as some signed zero missed
> optimizations.
> 
> Oh, and with this patch we cause code generation differences in 2.2%
> of LAPACK, and 5.48% of GSL files.  I didn't dig into any of these,
> but it seems other passes benefit as well.  Either way, we needed a
> way to represent != 0.0, which seemed like a big limitation in the
> initial frange implementation, and was causing me to lose sleep in my
> self-imposed break from hacking.

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.

	Jakub