On Thu, 2 Jun 2016, Jan Hubicka wrote: > > On Thu, 2 Jun 2016, David Edelsohn wrote: > > > > > >>>>> Richard Biener wrote: > > > > > > >> "This would mean the pass should get its own non-Optimization flag > > > >> initialized by targets where section anchors are usually used" > > > >> IIUC should we add a new option -fno-increase_alignment and gate the > > > >> pass on it ? Um sorry I didn't understand why targets > > > >> with section anchors (arm, aarch64, ppc) should initialize this option > > > >> ? > > > > > > > > Currently the pass is only run for targets with section anchors (and > > > > there > > > > by default if they are enabled by default). So it makes sense to > > > > run on those by default and the pass is not necessary on targets w/o > > > > section anchors as the vectorizer can easily adjust alignment itself on > > > > those. > > > > > > PPC does not always enable section anchors -- it depends on the code > > > model. Shouldn't this be tied to use of section anchors? > > > > It effectively is with the patch by walking all functions to see if they > > have section anchors enabled. That is unnecessary work for targets that > > 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. > 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 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. Richard.
