[PATCH v2 10/14] Support for 64-bit location_t: gimple parts

Richard Biener richard.guenther@gmail.com
Wed Nov 20 09:12:41 GMT 2024


On Tue, Nov 19, 2024 at 4:43 PM Lewis Hyatt <lhyatt@gmail.com> wrote:
>
> On Tue, Nov 19, 2024 at 10:06 AM Richard Biener
> <richard.guenther@gmail.com> wrote:
> >
> > On Sun, Nov 17, 2024 at 4:30 AM Lewis Hyatt <lhyatt@gmail.com> wrote:
> > >
> > > The size of struct gimple increases by 8 bytes with the change in size of
> > > location_t from 32- to 64-bit; adjust the WORD markings in the comments
> > > accordingly. It seems that most of the WORD markings were off by one already,
> > > probably not having been updated after a previous reduction in the size of a
> > > gimple, so they have become retroactively correct again, and only a couple
> > > needed adjustment actually.
> > >
> > > Also move the 32-bit num_ops member of struct gimple to the end; since there
> > > is now 4 bytes of padding after it, this may enable reuse of the tail
> > > padding for some derived structures.
> > >
> > > gcc/ChangeLog:
> > >
> > >         * gimple.h (struct gimple): Update word marking comments to reflect
> > >         the new size of location_t. Move the 32-bit int field to the end.
> > >         (struct gphi): Likewise.
> > > ---
> > >  gcc/gimple.h | 11 ++++++-----
> > >  1 file changed, 6 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/gcc/gimple.h b/gcc/gimple.h
> > > index 4a6e0e97d1e..6929c792dc5 100644
> > > --- a/gcc/gimple.h
> > > +++ b/gcc/gimple.h
> > > @@ -268,9 +268,6 @@ struct GTY((desc ("gimple_statement_structure (&%h)"), tag ("GSS_BASE"),
> > >       Locus information for debug info.  */
> > >    location_t location;
> > >
> > > -  /* Number of operands in this tuple.  */
> > > -  unsigned num_ops;
> > > -
> >
> > Can you instead swap location and num_ops and insert
> >
> >     unsigned int pad : 32;
> >
> > after the bits section?  Or is the intent to allow the tail padding to
> > be re-used?  I guess
> > all the [ WORD 1-n] : base class comments need adjustment?  Since
> > 'gimple' looks POD
> > to me, is tail padding even re-used?
> >
> > Thanks,
> > Richard.
>
> So I was thinking that the tail padding could be reused, but you are
> right, it won't be here since this is the base class. All the classes
> that inherit from gimple are non-POD because they use inheritance, but
> gimple itself is POD. I'll change it how you suggest.

Thanks.  I'm not always 100% sure about the C++ rules here.

Richard.


More information about the Gcc-patches mailing list