This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/63679] [5 Regression][AArch64] Failure to constant fold.


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679

--- Comment #28 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 #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).

> and that's one of the cost functions that affects scalarization. Also, 
> isn't it difficult to decide scalarization of aggregates based on how it 
> might be optimized in the future passes as accurately predicting the 
> transformations it could go through in subsequent passes is not easy?

Of course.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]