Re: [PATCH][RFC] Fix PR61473, inline small memcpy/memmove during tree opts

[Richard Biener <rguenther@suse.de>]

On Fri, 27 Jun 2014, Jakub Jelinek wrote:

> On Fri, Jun 27, 2014 at 01:49:38PM +0200, Richard Biener wrote:
> > I'm going to go for a single load/store and MOVE_MAX for now - I
> > have quite some fallout to deal with anyway (analyzed strlenopt-1.c
> > FAIL only, the other strlenopt cases are probably similar)
> > 
> > FAIL: gcc.dg/strlenopt-1.c scan-tree-dump-times strlen "strlen \\\\(" 2
> > FAIL: gcc.dg/strlenopt-1.c scan-tree-dump-times strlen "memcpy \\\\(" 4
> 
> But is it really desirable to do this kind of expansion so early on GIMPLE?
> Doing it during folding is e.g. very much harmful to offloading, the
> offloading target might have different preferences from the host.
> So, if it is really beneficial (do you have some benchmark that shows
> that?), can it be done e.g. in the strlen pass or even somewhat later?

strlen pass now runs very very late, for PR61619 it is important
before some constant propagation happening before vectorization.

But yes, it's not necessary doing that on GENERIC (nor is any of
those foldings - but as said, it's not the objective of the patch
to change where we do such optimizations).

Oh, and offloading targets always will have the issue facing
IL optimized for another target (LOGICAL_OP_NON_SHORT_CIRCUIT
for example).

Richard.