BTW, I don't know if it got lost in all my patches, but we already have an irange allocator that given an irange, returns a chunk of memory holding a clone of that irange squished into its minimum representable pairs (see vrange_allocator and friends). So we won't ever be storing 255 or something equally absurd like I had proposed years ago :). We'll be storing the smallest representable range inside a trailing_wide_int.
Aldy On Fri, Jul 1, 2022 at 10:31 PM Aldy Hernandez <al...@redhat.com> wrote: > > On Fri, Jul 1, 2022 at 8:53 PM Jakub Jelinek <ja...@redhat.com> wrote: > > > > On Fri, Jul 01, 2022 at 07:43:28PM +0200, Aldy Hernandez wrote: > > > You can still say N=255 and things continue to work as they do now, since > > > m_len[] is still statically determined. The only difference is that > > > before, > > > the size of the structure would be 2+1+255+sizeof(int) whereas now it > > > would > > > be 1 more because of the byte I'm using for num_elements. > > > > So, what N do you want to use for SSA_NAME_RANGE_INFO? > > N=255 wouldn't be very space efficient especially if the common case is a > > single range or two. > > For such cases making e.g. m_len not an embedded array, but pointer to > > somewhere after the HOST_WIDE_INT array in the same allocation would be > > better. > > As I mentioned in my original post, 12. This means that I'm taking > the 4 bytes that are left over from the current padding plus 8 > (64-bits). My trailing wide int structure for SSA_NAME_RANGE_INFO > will be one word larger than what is currently there. But we'll be > able to store up to 5 pairs plus one for the nonzero bits plus one for > future development (5*2 + 1 + 1 = 12), all without going over the 64 > bit alignment. > > This is a theoretical max, in reality as I mentioned, 99% of ranges > calculated in infinite precision by the ranger fit into 3-4 pairs. > > Aldy
