Re: [RFC] > WIDE_INT_MAX_PREC support in wide_int and widest_int

[Aldy Hernandez <aldyh@redhat.com>]

On 9/29/23 04:37, Jakub Jelinek wrote:
> On Thu, Sep 28, 2023 at 11:53:53AM -0400, Aldy Hernandez wrote:
>>> ipa_bits is even worse, because unlike niter analysis, I think it is very
>>> much desirable to support IPA VRP of all supported _BitInt sizes.  Shall
>>> we perhaps use trailing_wide_int storage in there, or conditionally
>>> rwidest_int vs. INTEGER_CSTs for stuff that doesn't fit, something else?
>>
>> BTW, we already track value/mask pairs in the irange, so I think ipa_bits
>> should ultimately disappear.  Doing so would probably simplify the code
>> base.
> 
> Well, having irange in GC memory would be equally bad, it does have
> non-trivial destructors (plus isn't meant to be space efficient either,
> right?).

Correct, irange is not space efficient by a long shot.  Any GC and long 
term requirements should be stored through the value-range-storage.h 
mechanism.

I already converted the ipa_vr ranges that live in GC memory to 
vrange_storage.  See the ipa_vr class.  So I think you could just nuke 
the ipa_bits and use the ranges already in ipa_vr.

> Though, perhaps we should use value-range-storage.h for that now that it
> can store value/mask pair as well?  Either tweak it on the IPA side
> such that everything is stored together (both the IPA VRP and IPA bit CCP)

Right.

Aldy

> or say use vrange_storage with zero (or one dummy) ranges + the value/mask
> pair.
> 
> 	Jakub
>