* [Bug optimization/11180] [avr-gcc] Optimization decrease performance of struct assignment.
2003-07-06 1:24 [Bug optimization/11180] New: [avr-gcc] Optimization decrease performance of struct assignment pinskia at physics dot uc dot edu
@ 2003-07-06 1:59 ` pinskia at physics dot uc dot edu
2003-07-10 13:38 ` steven at gcc dot gnu dot org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at physics dot uc dot edu @ 2003-07-06 1:59 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11180
pinskia at physics dot uc dot edu changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|3.4 |---
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug optimization/11180] [avr-gcc] Optimization decrease performance of struct assignment.
2003-07-06 1:24 [Bug optimization/11180] New: [avr-gcc] Optimization decrease performance of struct assignment pinskia at physics dot uc dot edu
2003-07-06 1:59 ` [Bug optimization/11180] " pinskia at physics dot uc dot edu
@ 2003-07-10 13:38 ` steven at gcc dot gnu dot org
2003-07-10 21:03 ` pinskia at physics dot uc dot edu
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: steven at gcc dot gnu dot org @ 2003-07-10 13:38 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11180
------- Additional Comments From steven at gcc dot gnu dot org 2003-07-10 13:38 -------
On i686-pc-linux-gnu I get identical asm for -O2 and -O3 and also for -O1 and
-Os. The only difference between -O[23] and -O[1s] is:
< .p2align 2,,3
.file "11180.c"
.text
.p2align 2,,3
.globl foo
.type foo, @function
foo:
pushl %ebp
movl %esp, %ebp
movl 8(%ebp), %eax
movl $1, (%eax)
movl $2, 4(%eax)
leave
ret $4
.size foo, .-foo
.section .note.GNU-stack,"",@progbits
.ident "GCC: (GNU) 3.4 20030710 (experimental)"
So -Os is optimal AFAICT (obviously it gets even smaller with -fomit-frame-pointer).
Apparently this is something target specific. What target is avr-gcc?
Gr.
Steven
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug optimization/11180] [avr-gcc] Optimization decrease performance of struct assignment.
2003-07-06 1:24 [Bug optimization/11180] New: [avr-gcc] Optimization decrease performance of struct assignment pinskia at physics dot uc dot edu
2003-07-06 1:59 ` [Bug optimization/11180] " pinskia at physics dot uc dot edu
2003-07-10 13:38 ` steven at gcc dot gnu dot org
@ 2003-07-10 21:03 ` pinskia at physics dot uc dot edu
2004-01-03 19:00 ` [Bug target/11180] " pinskia at gcc dot gnu dot org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at physics dot uc dot edu @ 2003-07-10 21:03 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11180
pinskia at physics dot uc dot edu changed:
What |Removed |Added
----------------------------------------------------------------------------
GCC target triplet| |avr-elf
------- Additional Comments From pinskia at physics dot uc dot edu 2003-07-10 21:03 -------
I was not the reporter but I was the one who confirmed it; avr-elf is the target, I will post the asm
(or rtl) if you want.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.
2003-07-06 1:24 [Bug optimization/11180] New: [avr-gcc] Optimization decrease performance of struct assignment pinskia at physics dot uc dot edu
` (2 preceding siblings ...)
2003-07-10 21:03 ` pinskia at physics dot uc dot edu
@ 2004-01-03 19:00 ` pinskia at gcc dot gnu dot org
2005-01-09 1:30 ` pinskia at gcc dot gnu dot org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-01-03 19:00 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-01-03 19:00 -------
This is a target problem of not showing how moves are done.
--
What |Removed |Added
----------------------------------------------------------------------------
Severity|minor |enhancement
Component|optimization |target
Last reconfirmed|2003-07-06 01:24:58 |2004-01-03 19:00:25
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11180
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.
2003-07-06 1:24 [Bug optimization/11180] New: [avr-gcc] Optimization decrease performance of struct assignment pinskia at physics dot uc dot edu
` (3 preceding siblings ...)
2004-01-03 19:00 ` [Bug target/11180] " pinskia at gcc dot gnu dot org
@ 2005-01-09 1:30 ` pinskia at gcc dot gnu dot org
2005-03-27 14:33 ` andrewhutchinson at cox dot net
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-01-09 1:30 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 01:30 -------
One issue I find is that avr does not define_insn_and_split (or just define_split) which will greatly
improve the code generation because the hi part of the QI would be zero and you don't need to set it
four times.
ldi r25,hi8(2)
ldi r25,hi8(1)
ldi r26,hlo8(1)
ldi r27,hhi8(1)
The main difference between -Os and -O0 (at least before 4.0.0) is that we use more registers at -Os
which causes the prologue and eplogue to do more so my recommendation will help a lot.
--
What |Removed |Added
----------------------------------------------------------------------------
OtherBugsDependingO| |16996
nThis| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11180
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.
2003-07-06 1:24 [Bug optimization/11180] New: [avr-gcc] Optimization decrease performance of struct assignment pinskia at physics dot uc dot edu
` (4 preceding siblings ...)
2005-01-09 1:30 ` pinskia at gcc dot gnu dot org
@ 2005-03-27 14:33 ` andrewhutchinson at cox dot net
2005-06-26 2:26 ` pinskia at gcc dot gnu dot org
2005-06-26 15:06 ` schlie at comcast dot net
7 siblings, 0 replies; 9+ messages in thread
From: andrewhutchinson at cox dot net @ 2005-03-27 14:33 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From andrewhutchinson at cox dot net 2005-03-27 14:33 -------
The problem here is that gcc is using a DImode register to handle 6 byte
(int+long) structure. Why I have no idea!
Since the target has no insn for DI move, gcc turns this into individual QImode
byte moves (subregs all over the place!).
The 'stacked' 6 byte structure is 'popped' into DI register (6 bytes ). Two
other byte registers are explicitely cleared (making our 8 byte DI register)
What then follows is a large amount of shuffling. i.e. Moving from intermediate
virtual DI register (8 bytes) into correct place for a 6 byte return. Which
seems to surpass the abilities of the register allocator (DI and return
registers overlap).
Smaller structures (<=4 bytes) are optimally handled. Larger structure >8 are
also much better since they are returned in memory.
So in summary, it would appear that the root cause is allocation of a DI mode
register for structures >4 and <=8 bytes.
A secondary factor is the use of QImode moves (when SI,HImode are available and
more efficient)
The problem can be partially alleviated by defining DImode moves (that a hell of
a change though). Poor code still remains - for example clearing unused padding
bytes and extra register usage.
PS -fpack-struct does not change this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11180
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.
2003-07-06 1:24 [Bug optimization/11180] New: [avr-gcc] Optimization decrease performance of struct assignment pinskia at physics dot uc dot edu
` (5 preceding siblings ...)
2005-03-27 14:33 ` andrewhutchinson at cox dot net
@ 2005-06-26 2:26 ` pinskia at gcc dot gnu dot org
2005-06-26 15:06 ` schlie at comcast dot net
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-06-26 2:26 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-26 02:25 -------
(In reply to comment #6)
> The problem here is that gcc is using a DImode register to handle 6 byte
> (int+long) structure. Why I have no idea!
This is so it does not store it on the stack. As I said in comment #5, this is a target issue and have
nothing to do with DImode.
--
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2004-01-03 19:00:25 |2005-06-26 02:25:56
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11180
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.
2003-07-06 1:24 [Bug optimization/11180] New: [avr-gcc] Optimization decrease performance of struct assignment pinskia at physics dot uc dot edu
` (6 preceding siblings ...)
2005-06-26 2:26 ` pinskia at gcc dot gnu dot org
@ 2005-06-26 15:06 ` schlie at comcast dot net
7 siblings, 0 replies; 9+ messages in thread
From: schlie at comcast dot net @ 2005-06-26 15:06 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From schlie at comcast dot net 2005-06-26 15:06 -------
(In reply to comment #7)
> (In reply to comment #6)
> > The problem here is that gcc is using a DImode register to handle 6 byte
> > (int+long) structure. Why I have no idea!
> This is so it does not store it on the stack. As I said in comment #5, this is a target issue and have
> nothing to do with DImode.
It would seem more desireable given the intended purpose to avoid pushing it on the stack
so that it's elements may be more effeciencly accessed, that it's coresponding elements be
allocated within the register file (as opposed to the whole struct remaining packed into an
alllocated DI mode integer), so that it's elements may be effeciently accessed without
needing to rip them out or reassemble them into the otherwise packed monolithic structure?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11180
^ permalink raw reply [flat|nested] 9+ messages in thread