[Bug optimization/11180] New: [avr-gcc] Optimization decrease performance of struct assignment.

[Bug optimization/11180] New: [avr-gcc] Optimization decrease performance of struct assignment.

[pinskia at physics dot uc dot edu]

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

           Summary: [avr-gcc] Optimization decrease performance of struct
                    assignment.
           Product: gcc
           Version: 3.3.1
            Status: NEW
          Severity: minor
          Priority: P2
         Component: optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dmixm at marine dot febras dot ru
                CC: gcc-bugs at gcc dot gnu dot org

Any optimization level increase size and decrease speed 
for next program: 
 
	typedef struct { long lo; int in; } lo_in; 
	lo_in foo (void) 
	{ 
	    lo_in x; 
	    x.lo = 1; 
	    x.in = 2; 
	    return x; 
	} 
 
"avr-gcc -W -Wall -S -O0" produced: 
	/* File "lo_in.c": code   75 = 0x004b (  40), prologues  18, epilogues  17 */ 
"avr-gcc -W -Wall -S -Os" produced: 
	/* File "lo_in.c": code   80 = 0x0050 (  29), prologues  26, epilogues  25 */ 
"avr-gcc -W -Wall -S -O3" produced: 
	/* File "lo_in.c": code   79 = 0x004f (  28), prologues  26, epilogues  25 */ 
 
Compiler: 
	avr-gcc (GCC) 3.3.1 20030519 (prerelease)
------- Additional Comments From pinskia at physics dot uc dot edu  2003-07-06 01:24 -------
I can confirm this on the mainline (20030706).

[Bug optimization/11180] [avr-gcc] Optimization decrease performance of struct assignment.

[pinskia at physics dot uc dot edu]

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                         |---

[Bug optimization/11180] [avr-gcc] Optimization decrease performance of struct assignment.

[steven at gcc dot gnu dot org]

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

[Bug optimization/11180] [avr-gcc] Optimization decrease performance of struct assignment.

[pinskia at physics dot uc dot edu]

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.

[Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.

[pinskia at gcc dot gnu dot org]

------- 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

[Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.

[pinskia at gcc dot gnu dot org]

------- 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

[Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.

[andrewhutchinson at cox dot net]

------- 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

[Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.

[pinskia at gcc dot gnu dot org]

------- 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

[Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.

[schlie at comcast dot net]

------- 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