This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PING][PATCH 2/3] retire mem_signal_fence pattern
Hi,
On 5 September 2017 at 13:40, Uros Bizjak <ubizjak@gmail.com> wrote:
> On Tue, Sep 5, 2017 at 12:28 PM, Alexander Monakov <amonakov@ispras.ru> wrote:
>> On Mon, 4 Sep 2017, Uros Bizjak wrote:
>>> introduced a couple of regressions on x86 (-m32, 32bit) testsuite:
>>>
>>> New failures:
>>> FAIL: gcc.target/i386/pr71245-1.c scan-assembler-not (fistp|fild)
>>> FAIL: gcc.target/i386/pr71245-2.c scan-assembler-not movlps
>>
>> Sorry. I suggest that the tests be XFAIL'ed, the peepholes introduced in the
>> fix for PR 71245 removed, and the PR reopened (it's a missed-optimization PR).
>> I can do all of the above if you agree.
>>
>> I think RTL peepholes are a poor way of fixing the original problem, which
>> actually exists on all targets with separate int/fp registers. For instance,
>> trunk (without my patch) still gets a far simpler testcase wrong (-O2, 64-bit):
>
> Please note that 32bit x86 implements atomic DImode access with
> fild/fistp combination, so the mentioned peephole avoids quite costly
> instruction sequence.
>
> For reference, attached patch implements additional peephole2 patterns
> that also handle sequences with blockages.
>
> Uros.
On arm, we also have a similar regression:
FAIL: gcc.target/arm/stl-cond.c scan-assembler stlne
Before the patch, we generated:
ldr r3, [r0]
cmp r3, #0
addne r3, r0, #4
movne r2, #0
stlne r2, [r3]
bx lr
and now:
ldr r3, [r0]
cmp r3, #0
bxeq lr
mov r2, #0
add r3, r0, #4
stl r2, [r3]
bx lr
Christophe