> > 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. Honza > > Richard.
