On Mon, Nov 25, 2024 at 09:57:16AM +0100, Richard Biener wrote:
> On Sun, Nov 24, 2024 at 7:22 PM Hans-Peter Nilsson <h...@bitrange.com> wrote:
> >
> > On Sat, 16 Nov 2024, Lewis Hyatt wrote:
> > > The size of struct gimple increases by 8 bytes with the change in size of
> > > location_t from 32- to 64-bit
> >
> > Half-way scrolling through the patches, this seems a good time
> > for a possibly disruptive comment from the side-line: ;-)
> >
> > For the size-critical types containing and, affected by
> > enlarging location_t to 64 bits, would it be feasible to instead
> > express the location as an index into a (new) array elsewhere
> > that contains the location_t? If that idea was discarded early
> > or pursued and discarded, I missed that.
>
> The issue with that is that at least during "build" time we'd likely
> need a way to reverse lookup from this index. It also feels like
> if this is possible then libcpp should do this itself (it basically
> can do this by having all locations being ad-hoc locations).
I think at least for the parsing we really need 64-bit location_t, libcpp
already tries hard to compress stuff and the FE generally sees far more
different locations than middle-end.
So, location_t needs to be 64-bit and GENERIC needs to use 64-bit location_t
as well.
Whether we could get away with 32-bit locus in gimple_location by always
assuming ad hoc location is a question, perhaps without LTO, but I thought
with LTO we already run into not enough location cases in larger builds.
But it would be wasteful, because we'd need ad hoc locations without BLOCK
from gimplification until gimple lowering and different ad hoc locations
with BLOCK.
Jakub
