move increase_alignment from simple to regular ipa pass

Prathamesh Kulkarni
Tue Jun 7 08:34:00 GMT 2016

On 3 June 2016 at 13:35, Jan Hubicka <> 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.

> Honza
>> Richard.

More information about the Gcc-patches mailing list