On 3/30/19 4:21 AM, Uros Bizjak wrote:
> On 3/29/19, Jeff Law <l...@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 <ja...@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
