Re: move increase_alignment from simple to regular ipa pass

[Jan Hubicka <hubicka@ucw.cz>]

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

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.

I dunno what is the desired behaviour for LTOint together different code models.

Honza

> do not support section anchors at all, of course.
> 
> Richard.