This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [EXT] Re: Questions about initialization data during LTO

On Thu, Sep 12, 2019 at 9:09 PM Gary Oblock <> wrote:
> On 9/12/19 3:12 AM, Richard Biener wrote:
> > External Email
> >
> > ----------------------------------------------------------------------
> > On Thu, Sep 12, 2019 at 1:28 AM Gary Oblock <> wrote:
> >> I'm trying to do a set of optimizations that drastically transform the
> >> layout of arrays of structures. For obvious reasons they will need to
> >> run at LTO time. I'm running into some difficulties comprehending how
> >> the initialization data is stored. Also, I'm seeing DECL_INITIALs
> >> being set to NULL and that is worrisome since it would throw a monkey
> >> wrench into what I'm doing. That is, because for my optimizations to
> >> work they will need to either disqualify an array with initialization
> >> data or transform said data.
> >>
> >> So, is the initialization data being hidden at LTO time?
> >> If not what's its format and how do I best manipulate it?
> > You probably have to do at least part of the work at WPA time where
> > DECL_INITIAL should be appropriately set.  Initializers are generally only
> > shipped to / output in one LTRANS unit unless they can be used for
> > constant folding.
> First, I thought WHOPR was deprecated??

On the contrary, it's the default.

> Second, if the initializations
> are stripped is there any indication that it's occurred? Third, is it
> possible
> to selectively disable the stripping for arrays of structures and
> structures?

As said, you need to view the whole program anyways so work at WPA
time.  That means all initializers are still present.

> Note, this optimization is a lot harder to do as bits and pieces here and
> there and perhaps totally unfeasible. I have to be able to examine all the
> uses of of all the structures and all the variables of these types to in
> order
> to qualify the optimization. Then I have to do the same thing all over
> again
> to apply the transformations.

Yes, indeed you have.  Ideally you'd do function-level analysis
at pre-WPA compile-time, then combine and decide how to transform
at WPA time and actually apply the transform to the function bodies
(and initializers) at LTRANS.

> >> Any insight into how to deal with these problem would be most helpful.
> >> These are some really interesting optimizations and will greatly speed
> >> up code that uses large arrays of structures.
> > Usually hinting the programmer is way easier here since a compiler has
> > to give up too easily for data layout optimizations.  Unless you only
> > target specific benchmarks...
> I don't follow you about hinting... Are you saying the programmer
> would need to supply hints in the code enabling the optimizations?
> I want to be as general as possible and improve "dusty decks" too.
> Admittedly the first cut of these optimizations will be quite limited.
> My plan is to get the framework to function and then extend it.

No, the compiler should hint the programmer at "hey, if you'd reorder
this performance would go up!" and have the programmer do the


> Gary
> >
> > Richard.
> >
> >> Thanks,
> >>
> >> Gary Oblock

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]