public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/36770] New: PowerPC generated PTR code ineffiency
@ 2008-07-09 14:57 gunnar at greyhound-data dot com
2008-07-09 18:23 ` [Bug middle-end/36770] " pinskia at gcc dot gnu dot org
` (4 more replies)
0 siblings, 5 replies; 7+ messages in thread
From: gunnar at greyhound-data dot com @ 2008-07-09 14:57 UTC (permalink / raw)
To: gcc-bugs
GCC fails to generate efficient code for basic pointer operations.
Please have a look at this example:
***
test.c:
register int * src asm("r15");
int test( ){
src[1]=src[0];
src++;
}
main(){
}
***
compile the above with gcc -S -O3 test.c
shows us the following ASM output:
test:
mr 9,15
addi 15,15,4
lwz 0,0(9)
stw 0,4(9)
blr
compile with gcc -S -Os test.c
Gives this output
test:
mr 9,15
addi 15,15,4
lwz 0,0(9)
stw 0,4(9)
blr
As you can see both -O3 and -Os produce the same output.
The generated output is far from optimal.
GCC generates for the simple pointer operation this code:
mr 9,15
addi 15,15,4
lwz 0,0(9)
stw 0,4(9)
But GCC should rather generate this:
lwz 0,0(15)
stwu 0,4(15)
Two of the four instructions are unneeded.
We've here code with literally thousands of unneeded instructions generated
like this.
I very much hope that this information is helpful to you and that you can fix
this.
Many thanks in advance
Gunnar von Boehn
--
Summary: PowerPC generated PTR code ineffiency
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gunnar at greyhound-data dot com
GCC build triplet: powerpc64-unknown-linux-gnu
GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36770
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/36770] PowerPC generated PTR code ineffiency
2008-07-09 14:57 [Bug c/36770] New: PowerPC generated PTR code ineffiency gunnar at greyhound-data dot com
@ 2008-07-09 18:23 ` pinskia at gcc dot gnu dot org
2008-07-10 9:19 ` [Bug middle-end/36770] PowerPC generated PTR code inefficiency gunnar at greyhound-data dot com
` (3 subsequent siblings)
4 siblings, 0 replies; 7+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2008-07-09 18:23 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-09 18:22 -------
forward-propagate is causing some of the issues as shown by:
int *test(int *a ){
a[1]=a[0];
a++;
return a;
}
But using the register extension is causing the rest :). I would recommend
against using them in real code really, they are not that useful and cause too
many issues in general.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pinskia at gcc dot gnu dot
| |org, bonzini at gnu dot org
Severity|major |normal
Status|UNCONFIRMED |NEW
Component|c |middle-end
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2008-07-09 18:22:19
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36770
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/36770] PowerPC generated PTR code inefficiency
2008-07-09 14:57 [Bug c/36770] New: PowerPC generated PTR code ineffiency gunnar at greyhound-data dot com
2008-07-09 18:23 ` [Bug middle-end/36770] " pinskia at gcc dot gnu dot org
@ 2008-07-10 9:19 ` gunnar at greyhound-data dot com
2008-07-11 11:56 ` [Bug middle-end/36770] PowerPC missed autoincrement opportunity bonzini at gnu dot org
` (2 subsequent siblings)
4 siblings, 0 replies; 7+ messages in thread
From: gunnar at greyhound-data dot com @ 2008-07-10 9:19 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from gunnar at greyhound-data dot com 2008-07-10 09:18 -------
(In reply to comment #1)
> forward-propagate is causing some of the issues as shown by:
> int *test2(int *a ){
> a[1]=a[0];
> a++;
> return a;
> }
Your example creates the following ASM code:
test2:
mr 9,3
addi 3,3,4
lwz 0,0(9)
stw 0,4(9)
blr
Correct would be:
test2:
lwz 0,0(3)
stwu 0,4(3)
blr
Is you can see the created bad code is just the same.
This is independent of the register pinning.
Can I understand you comment a verification that the forward propagation is
broken in GCC/PPC?
Kind regards
Gunnar von Boehn
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36770
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/36770] PowerPC missed autoincrement opportunity
2008-07-09 14:57 [Bug c/36770] New: PowerPC generated PTR code ineffiency gunnar at greyhound-data dot com
2008-07-09 18:23 ` [Bug middle-end/36770] " pinskia at gcc dot gnu dot org
2008-07-10 9:19 ` [Bug middle-end/36770] PowerPC generated PTR code inefficiency gunnar at greyhound-data dot com
@ 2008-07-11 11:56 ` bonzini at gnu dot org
2008-07-18 13:42 ` bonzini at gnu dot org
2008-07-18 14:14 ` bonzini at gnu dot org
4 siblings, 0 replies; 7+ messages in thread
From: bonzini at gnu dot org @ 2008-07-11 11:56 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from bonzini at gnu dot org 2008-07-11 11:56 -------
Yes, the code produced shows that something (probably fwprop, I trust Andrew
though I'd like to see dumps) is turning the GIMPLE code
temp = a[0];
a[1] = temp;
temp++;
into something harder to optimize. It might be also a pass-ordering problem.
--
bonzini at gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
Summary|PowerPC generated PTR code |PowerPC missed autoincrement
|inefficiency |opportunity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36770
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/36770] PowerPC missed autoincrement opportunity
2008-07-09 14:57 [Bug c/36770] New: PowerPC generated PTR code ineffiency gunnar at greyhound-data dot com
` (2 preceding siblings ...)
2008-07-11 11:56 ` [Bug middle-end/36770] PowerPC missed autoincrement opportunity bonzini at gnu dot org
@ 2008-07-18 13:42 ` bonzini at gnu dot org
2008-07-18 14:14 ` bonzini at gnu dot org
4 siblings, 0 replies; 7+ messages in thread
From: bonzini at gnu dot org @ 2008-07-18 13:42 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from bonzini at gnu dot org 2008-07-18 13:41 -------
auto-inc-dec should be taught about transforming
a <- b + c
...
*(b + c)
into
a <- b
...
*(a += c) pre
--
bonzini at gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |zadeck at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36770
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/36770] PowerPC missed autoincrement opportunity
2008-07-09 14:57 [Bug c/36770] New: PowerPC generated PTR code ineffiency gunnar at greyhound-data dot com
` (3 preceding siblings ...)
2008-07-18 13:42 ` bonzini at gnu dot org
@ 2008-07-18 14:14 ` bonzini at gnu dot org
4 siblings, 0 replies; 7+ messages in thread
From: bonzini at gnu dot org @ 2008-07-18 14:14 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from bonzini at gnu dot org 2008-07-18 14:13 -------
Hmm, even that wouldn't restore the optimization. The problem here is that
there is another access via b, like
a <- b + c
*b
*(b + c)
The bad placement of the first assignment (bad because doing it the other way
round would have lower register pressure) in turn happens as soon as
gimplification.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36770
^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <bug-36770-4@http.gcc.gnu.org/bugzilla/>]
* [Bug middle-end/36770] PowerPC missed autoincrement opportunity
[not found] <bug-36770-4@http.gcc.gnu.org/bugzilla/>
@ 2013-12-24 23:13 ` steven at gcc dot gnu.org
0 siblings, 0 replies; 7+ messages in thread
From: steven at gcc dot gnu.org @ 2013-12-24 23:13 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36770
Steven Bosscher <steven at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |steven at gcc dot gnu.org
--- Comment #6 from Steven Bosscher <steven at gcc dot gnu.org> ---
(In reply to Gunnar von Boehn from comment #2)
> Correct would be:
> test2:
> lwz 0,0(3)
> stwu 0,4(3)
> blr
>
> Is you can see the created bad code is just the same.
> This is independent of the register pinning.
At least with gcc 4.7.1 and gcc 4.9.0 (r206195) the register pinning
makes all the difference.
$ cat t.c
register int * src asm("r15");
int test1( ){
src[1]=src[0];
src++;
}
int *test2(int *a ){
a[1]=a[0];
a++;
return a;
}
$ ./cc1 -quiet -O2 t.c
$ cat t.s
...
.L.test1:
lwz 10,0(15)
mr 9,15
addi 15,15,4
stw 10,4(9)
blr
...
.L.test2:
lwz 9,0(3)
stwu 9,4(3)
blr
This is basically the same as bug 44281.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-12-24 23:13 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-07-09 14:57 [Bug c/36770] New: PowerPC generated PTR code ineffiency gunnar at greyhound-data dot com
2008-07-09 18:23 ` [Bug middle-end/36770] " pinskia at gcc dot gnu dot org
2008-07-10 9:19 ` [Bug middle-end/36770] PowerPC generated PTR code inefficiency gunnar at greyhound-data dot com
2008-07-11 11:56 ` [Bug middle-end/36770] PowerPC missed autoincrement opportunity bonzini at gnu dot org
2008-07-18 13:42 ` bonzini at gnu dot org
2008-07-18 14:14 ` bonzini at gnu dot org
[not found] <bug-36770-4@http.gcc.gnu.org/bugzilla/>
2013-12-24 23:13 ` steven at gcc dot gnu.org
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).