This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: move increase_alignment from simple to regular ipa pass
- From: Richard Biener <rguenther at suse dot de>
- To: Prathamesh Kulkarni <prathamesh dot kulkarni at linaro dot org>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, David Edelsohn <dje dot gcc at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, "William J. Schmidt" <wschmidt at linux dot vnet dot ibm dot com>, Segher Boessenkool <segher at kernel dot crashing dot org>
- Date: Wed, 8 Jun 2016 16:15:37 +0200 (CEST)
- Subject: Re: move increase_alignment from simple to regular ipa pass
- Authentication-results: sourceware.org; auth=none
- References: <CAGWvnyn7pre5tSfZixxPZhVxqmJxXEfpTRw+t0+ouQcwvV2i7g at mail dot gmail dot com> <alpine dot LSU dot 2 dot 11 dot 1606021454320 dot 1493 at t29 dot fhfr dot qr> <20160602150106 dot GA48112 at kam dot mff dot cuni dot cz> <alpine dot LSU dot 2 dot 11 dot 1606030954520 dot 1493 at t29 dot fhfr dot qr> <20160603080543 dot GA78035 at kam dot mff dot cuni dot cz> <CAAgBjMn4R5pZEmDYWRp6ewN1GsL5dhsOqb6LMG=Ev7YaUtjAbw at mail dot gmail dot com>
On Tue, 7 Jun 2016, Prathamesh Kulkarni wrote:
> On 3 June 2016 at 13:35, Jan Hubicka <hubicka@ucw.cz> wrote:
> >> > fsection-anchors
> >> > Common Report Var(flag_section_anchors)
> >> > Access data in the same section from shared anchor points.
> >>
> >> Funny. I see the following on trunk:
> >>
> >> fsection-anchors
> >> Common Report Var(flag_section_anchors) Optimization
> >> Access data in the same section from shared anchor points.
> >
> > Aha, my local change from last year still inmy tree. Sorry.
> > Yep, having it as Optimization makes sense, but we need to be sure it works as intended.
> >>
> >> > flag_section_anchors is not declared as Optimiation, so it can't be function
> >> > specific right now. It probably should because it is an optimization. This
> >> > makes me wonder what happens when one function have anchors enabled and other
> >> > doesn't? Probably anchroing or not anchoring the var will then depend on what
> >> > function comes first in the compilation order and then we will need to make
> >> > backend grok the case where static var is anchored but flag_section_anchors is
> >> > off.
> >>
> >> This is because we represent the anchor with DECL_RTL, right? Maybe
> >> DECL_RTL of globals needs to be re-computed for each function...
> >
> > I would rather anchor variable if it is used by at least one function that is compiled
> > with anchors. Accessing anchors is IMO no slower than accessing symbols. But I am not
> > that familiar witht his code...
> >>
> >> > I dunno what is the desired behaviour for LTOint together different code
> >> > models.
> >>
> >> Good question. There's always the choice to remove 'Optimization' and
> >> enforce same setting for all TUs we LTO in lto-wrapper.
> >
> > Yep. Not sure what is better - I did not really think of targets that use both
> > models.
> Um I am not really sure what to do next to convert increase_alignment
> to regular pass, I would be grateful
> for suggestions.
I think it would be nice to work towards transitioning
flag_section_anchors to a flag on varpool nodes, thereby removing
the Optimization flag from common.opt:fsection-anchors
That would simplify the walk over varpool candidates.
Richard.
> Thanks,
> Prathamesh
> >
> > Honza
> >>
> >> Richard.
>
>
--
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)