https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #30 from rguenther at suse dot de <rguenther at suse dot de> --- 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.
