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
