This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH, stage1] Move insns without introducing new temporaries in loop2_invariant
- From: "Thomas Preud'homme" <thomas dot preudhomme at arm dot com>
- To: "'Richard Biener'" <richard dot guenther at gmail dot com>
- Cc: "GCC Patches" <gcc-patches at gcc dot gnu dot org>, "Eric Botcazou" <ebotcazou at libertysurf dot fr>
- Date: Fri, 6 Mar 2015 16:59:05 +0800
- Subject: RE: [PATCH, stage1] Move insns without introducing new temporaries in loop2_invariant
- Authentication-results: sourceware.org; auth=none
- References: <000101d0572a$2de1f390$89a5dab0$ at arm dot com> <CAFiYyc2ObviG7tqdQeOUGPGBWDNtnmrDM-_p8dqibmHFi-9vpg at mail dot gmail dot com>
> From: Richard Biener [mailto:richard.guenther@gmail.com]
> Sent: Thursday, March 05, 2015 7:12 PM
> >
> > loop header
> > start of loop body
> > //stuff
> > (set (reg 128) (const_int 0))
> > //other stuff
> > end of loop body
> >
> > becomes:
> >
> > (set (reg 129) (const_int 0))
> > loop header
> > start of loop body
> > //stuff
> > (set (reg 128) (reg 128))
> > //other stuff
> > end of loop body
> >
>
> Why doesn't copy-propagation clean this up? It's run after loop2.
Actually cprop3 is what makes the situation worse in this case as it
will copy the constant that is set outside the loop in the mov that is in
the loop. In the case or PR64616 the constant is a symbol_ref which
makes it a memory access so it propagates the memory access in the
loop, making the load executed many times.
Note that as I said in the intro this bug is also solved by [1] which is
the first thing that goes wrong for this example. That being said,
loop invariant pass ought to simply move instructions if it can safely
do so.
[1] https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00933.html
Best regards,
Thomas