On Tue, Aug 29, 2023 at 09:49:59AM +0000, Richard Biener wrote:
> The simplest way would probably to keep widest_int at
> WIDE_INT_MAX_PRECISION like we have now and assert that this is
> enough at ::to_widest time (we probably do already). And then
> declare uses with more precision need to use GMP.
>
> Not sure if that's not also a viable way for wide_int - we're
> only losing optimization here, no?
No. In lots of places it is essential (constant evaluation), in other
places very much desirable optimization even or especially on _BitInt (e.g.
value range optimizations, ccp, ...) and then sure, spots where just punting
on larger _BitInt for optimization is something we can live with (and yet
other spots which only happen after the lowering and so will never see that
at all).
I think if we go with allowing _BitInt (N) for N >= WIDE_INT_MAX_PRECISION,
the most important thing is we want to slow down the compiler as little as
possible for the common case, no _BitInt at all or _BitInt smaller than that,
and furthermore from maintainance POV, we want most of the code to work as
is. Adding assertion that precision is < WIDE_INT_MAX_PRECISION on
widest_int construction from wide_int/INTEGER_CST etc. wouldn't achieve
those goals. Grepping outside of wide-int.{cc,h} for widest_int, I see
around 450 matches, sure, that doesn't mean 450 places where we'd need to
add some guard to punt for the larger _BitInt (if it is possible to punt at
all), but I'm sure it would be more than hundred of places. And having
similarly say 50% of those 100-200 spots have a fallback using gmp would be
also a maintainance nightmare, because those spots for larger precisions
would be much less tested than normal code. Sure, we can add some guards
in some places and the niter stuff could very well be one of them, or simply
also use there wide_int with carefully chosen precision, say
WIDE_INT_MAX_PRECISION if _BitInt isn't involved or at most 128 bits,
and otherwise something wider. But I'm worried of the maintainance
nightmare etc. if we have to touch hundreds of places and figure out how to
punt or what else to do in each of those spots.
Compared to this, I see only 15 hits for widest2_int, in 2 places,
arith_overflowed_p and operator_mult::wi_fold, that is something that could
very well be done either always using appropriate wider precision wide_int,
or even do it twice, once for < WIDE_INT_MAX_PRECISION input precision and
another time wider.
Jakub
