On 2019-03-30 8:37 a.m., Jeff Law wrote:
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.
Yes, it is tricky. All these costs changes affect many targets and need
a lot of testing.
If you'd prefer to wait on installing the peepholes to hear from Vlad,
just in case, that's fine with me.
After several tries. I have a candidate patch. I'll test it on
x86/ppc64/arm64. If everything is ok, I'll commit it.
In any case, I report the results on Monday or Tuesday at worst.
