This is the mail archive of the gcc-patches@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]

Re: [PATCH 0/3] Resubmission of new implementation of SRA


On Sun, Jun 07, 2009 at 06:29:38AM -0700, H.J. Lu wrote:
> 2009/5/29 Martin Jambor <mjambor@suse.cz>:
> > Hi,
> >
> > On Fri, May 29, 2009 at 05:57:34PM +0200, Richard Guenther wrote:
> >> On Fri, 29 May 2009, Martin Jambor wrote:
> >>
> >> > Hi,
> >> >
> >> > This is hopefully the final version of intraprocedural SRA, addressing
> >> > all some ?comments from Richi's (some ?of which were sent ?only to me,
> >> > but they are all minor). ?The previous post is here:
> >> > http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01628.html
> >> >
> >> > The biggest difference is ?that auxiliary statements generated to turn
> >> > complex number and vector ?replacements which are not gimple registers
> >> > into registers are created ?by force_gimple_operand_gsi rather than by
> >> > functions of my own.
> >> >
> >> > Most ?notably, some ?unnecessary ?complex typecasting ?is removed ?and
> >> > complex numbers which ?participate in an assignment into ?one of their
> >> > components are dealt with by simply not making them a gimple register.
> >> >
> >> > The first ?patch is the ?new implementation itself. ?The ?second patch
> >> > removes SRA parameters which are ?no longer used and the third adjusts
> >> > the testsuite and adds new testcases.
> >> >
> >> > The whole ?patch set ?bootstraps on x86_64-linux-gnu ?(including Ada),
> >> > and i586-suse-linux. ? There are no ?new regressions on both ?of these
> >> > platforms.
> >> >
> >> > So, OK for trunk?
> >>
> >> Ok.
> >>
> >
> > Great, committed as revision 147980.
> >
> 
> This caused:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32950
> 

No, it didn't.  Even the previous regression ICEs with -fno-tree-sra.

BTW, new SRA  uncovered this because it did  not scalarize a structure
with  only  a single  scalar  (complex)  field  because it  is  always
accessed as  a structure and never  as a scalar.  I  wonder whether it
would be useful enough to  detect these cases and scalarize them (even
though it would further complicate the code, of course).

Martin


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