On 3 June 2016 at 13:35, Jan Hubicka <hubi...@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.
Thanks, Prathamesh > > Honza >> >> Richard.
