public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: target/7056: [ARM] zero extend code worse in 3.1 than 3.0
@ 2002-06-17 9:37 Richard Earnshaw
0 siblings, 0 replies; 2+ messages in thread
From: Richard Earnshaw @ 2002-06-17 9:37 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR target/7056; it has been noted by GNATS.
From: Richard Earnshaw <rearnsha@arm.com>
To: pb@nexus.co.uk
Cc: gcc-gnats@gcc.gnu.org, Richard.Earnshaw@arm.com, jakub@gcc.gnu.org,
mark@codesourcery.com
Subject: Re: target/7056: [ARM] zero extend code worse in 3.1 than 3.0
Date: Mon, 17 Jun 2002 16:21:06 +0100
This was caused by Jakub's patch to fix pr/6086, hence the CC list.
I think his patch is papering over a symptom rather than fixing the real
problem in reload. That is, if you are going to allow
(subreg (mem))
at all, then reload must handle it correctly, even if the mem has
side-effects. In this case we should be making reload correctly spill the
mem, rather than preventing the above RTL if the mem has side-effects.
For a RISC architecture, like the PPC, I don't think it makes sense to
allow subreg-mem in the first place. The ARM doesn't and I've generally
found this to lead to better code than allowing it and then letting reload
fix up the problems.
In general these problems seem to come about because register_operand()
allows subreg(reg-or-mem) and that seems daft.
R.
^ permalink raw reply [flat|nested] 2+ messages in thread
* target/7056: [ARM] zero extend code worse in 3.1 than 3.0
@ 2002-06-17 7:00 pb
0 siblings, 0 replies; 2+ messages in thread
From: pb @ 2002-06-17 7:00 UTC (permalink / raw)
To: gcc-gnats
>Number: 7056
>Category: target
>Synopsis: [ARM] zero extend code worse in 3.1 than 3.0
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: pessimizes-code
>Submitter-Id: net
>Arrival-Date: Mon Jun 17 06:16:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator: pb@nexus.co.uk
>Release: gcc-3.1
>Organization:
>Environment:
arm-linux
>Description:
See code below.
With gcc-3.0 -O2, this yields
stmfd sp!, {r4, lr}
ldrb r3, [r0], #1 @ zero_extendqisi2
ldrb r4, [r0, #0] @ zero_extendqisi2
mov r0, r3
bl g
mov r0, r4
@ Sibcall epilogue
ldmfd sp!, {r4, lr}
b g
With gcc-3.1, there is an extra, redundant, AND instruction:
stmfd sp!, {r4, lr}
ldrb r3, [r0], #1
and r3, r3, #255
ldrb r4, [r0, #0] @ zero_extendqisi2
mov r0, r3
bl g
mov r0, r4
@ Sibcall epilogue
ldmfd sp!, {r4, lr}
b g
>How-To-Repeat:
void f(unsigned char *p)
{
unsigned long int a,b;
a = *p++;
b = *p++;
g(a);
g(b);
}
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2002-06-17 15:26 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-06-17 9:37 target/7056: [ARM] zero extend code worse in 3.1 than 3.0 Richard Earnshaw
-- strict thread matches above, loose matches on Subject: below --
2002-06-17 7:00 pb
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).