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

Jeff Law law@redhat.com
Fri Jun 27 15:44:00 GMT 2014


On 06/27/14 05:56, 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?
You want to do it early enough in the pipeline to expose those to the 
bulk of the gimple optimizers.  My recollection was that was the biggest 
win for the customer case I looked at -- suddenly we can expose those 
objects to CSE, DSE & friends and lots of crud just starts to go away.

Jeff



More information about the Gcc-patches mailing list