[PATCH] Add peephole2s to improve pr49095.c f{char,short,int,long}minus on ia32 (PR rtl-optimization/89865)

[Jeff Law]

On 3/30/19 4:21 AM, Uros Bizjak wrote:
> On 3/29/19, Jeff Law <law@redhat.com> wrote:
>> On 3/29/19 1:44 PM, Jakub Jelinek wrote:
>>> Hi!
>>>
>>> f{char,short,int,long}minus use a RMW instead of direct memory operation
>>> (regression from 8.3) on ia32.  The problem is an extra register copy,
>>> which
>>> regcprop would fix up, but unfortunately peephole2 runs before regcprop.
>>> Also, in one of the existing peephole2s I've renumbered the operands so
>>> that
>>> we don't overwrite existing operands.
>>>
>>> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>>>
>>> 2019-03-29  Jakub Jelinek  <jakub@redhat.com>
>>>
>>> 	PR rtl-optimization/89865
>>> 	* config/i386/i386.md
>>> 	(SWI12 peephole for mem {+,-,&,|,^}= x; mem != 0): Fix up operand
>>> 	numbers not to clash with the additional operands[4].
>>> 	(peepholes for mem {+,-,&,|,^}= x; mem != 0): New peephole2s
>>> 	with extra register copy in the middle.
>>>
>>> 	* gcc.target/i386/pr49095.c: Adjust number of expected RMW spots
>>> 	on ia32.
>> OK.  One might ask if there's a way to share a bit of code here since
>> there's a fair amount of duplication.  But I'll trust that you've
>> pondered that and decided it wasn't really worth the effort.
> 
> I think that Vladimir n is looking into the PR. So, if RA can avoid
> register copies by itself, then these extra peepholes won't be needed.
> Let's ask Vladimir for his opinion.
I know, but based on my own experience in this space, I suspect it's
unlikely we'll have a clean solution for gcc-9 in the allocator.

If you'd prefer to wait on installing the peepholes to hear from Vlad,
just in case, that's fine with me.

jeff