https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ramana at gcc dot gnu.org
Target Milestone|5.0 |6.0
Summary|[5 Regression][AArch64] |[5 / 6 Regression][AArch64]
|Failure to constant fold. |Failure to constant fold.
--- Comment #31 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to rguent...@suse.de from comment #30)
> On Mon, 9 Feb 2015, belagod at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
> >
> > --- Comment #29 from Tejas Belagod <belagod at gcc dot gnu.org> ---
> > (In reply to rguent...@suse.de from comment #28)
> > > On Mon, 9 Feb 2015, belagod at gcc dot gnu.org wrote:
> > >
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
> > > >
> > > > --- Comment #27 from Tejas Belagod <belagod at gcc dot gnu.org> ---
> > > > We'd want to scalarize this early preferably in SRA as it gives a
> > > > chance to
> > > > passes like vectorization to vectorize more loops. I checked that
> > > > sra-max-scalarization-Osize{-Ospeed} had no effect on scalarizing 'a =
> > > > *.LC0'
> > >
> > > because SRA can't scalarize 'a = *.LC0'. But yes, ideally we'd change
> > > gimplification to never decompose initializers but have SRA do it.
> > > But that's of course not a GCC 5 thing.
> > >
> > > It has the advantage of splitting the initialization only when it is
> > > (likely) profitable and otherwise leave it to the target to decide
> > > how to expand the initialization (and it opens up the possibility
> > > to directly use a constant-pool entry if the data is readonly).
> >
> > Which cost function(s) control this profitability of early splitting?
>
> See gimplify_init_constructor and callees.
Given all the comments above this sounds like a 6.0 fix - I'm just making this
a 6.0 target - we can always change it back if someone can fix it in time for 5
Ramana
