public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/39148] -Os increase code size when stack is aligned
  2009-02-10 20:19 [Bug target/39148] New: -Os increase code size when stack is aligned hjl dot tools at gmail dot com
@ 2009-02-10 20:19 ` hjl dot tools at gmail dot com
  2009-02-10 20:46 ` hjl dot tools at gmail dot com
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-02-10 20:19 UTC (permalink / raw)
  To: gcc-bugs



-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/39148]  New: -Os increase code size when stack is aligned
@ 2009-02-10 20:19 hjl dot tools at gmail dot com
  2009-02-10 20:19 ` [Bug target/39148] " hjl dot tools at gmail dot com
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-02-10 20:19 UTC (permalink / raw)
  To: gcc-bugs

[hjl@gnu-6 pr39137]$ cat pr39137-3.i
void foo (unsigned long long *);

void
bar (void)
{
  unsigned long long l __attribute__ ((aligned(32)));
  foo (&l);
}
[hjl@gnu-6 pr39137]$ /export/build/gnu/gcc-work/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-avx/build-x86_64-linux/gcc/ -m32 -Os  pr39137-3.i -S
[hjl@gnu-6 pr39137]$ cat pr39137-3.s
        .file   "pr39137-3.i"
        .text
.globl bar
        .type   bar, @function
bar:
        leal    4(%esp), %ecx
        andl    $-32, %esp
        pushl   -4(%ecx)
        pushl   %ebp
        movl    %esp, %ebp
        pushl   %ecx
        subl    $64, %esp
        leal    -56(%ebp), %eax
        pushl   %eax
        call    foo
        movl    -4(%ebp), %ecx
        addl    $16, %esp
        leave
        leal    -4(%ecx), %esp
        ret
        .size   bar, .-bar
[hjl@gnu-6 pr39137]$ /export/build/gnu/gcc-work/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-avx/build-x86_64-linux/gcc/ -m32 -O  pr39137-3.i -S
[hjl@gnu-6 pr39137]$ cat pr39137-3.s
        .file   "pr39137-3.i"
        .text
.globl bar
        .type   bar, @function
bar:
        pushl   %ebp
        movl    %esp, %ebp
        andl    $-32, %esp
        subl    $48, %esp
        leal    16(%esp), %eax
        movl    %eax, (%esp)
        call    foo
        leave
        ret
        .size   bar, .-bar
[hjl@gnu-6 pr39137]$ 

-Os generates bigger binary.


-- 
           Summary: -Os increase code size when stack is aligned
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/39148] -Os increase code size when stack is aligned
  2009-02-10 20:19 [Bug target/39148] New: -Os increase code size when stack is aligned hjl dot tools at gmail dot com
  2009-02-10 20:19 ` [Bug target/39148] " hjl dot tools at gmail dot com
@ 2009-02-10 20:46 ` hjl dot tools at gmail dot com
  2009-02-11 15:54 ` hjl dot tools at gmail dot com
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-02-10 20:46 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #1 from hjl dot tools at gmail dot com  2009-02-10 20:46 -------
The problem is

static rtx
ix86_get_drap_rtx (void)
{
  if (ix86_force_drap || !ACCUMULATE_OUTGOING_ARGS)
    crtl->need_drap = true; 


-Os turns off ACCUMULATE_OUTGOING_ARGS, which turns on DRAP. Does
ACCUMULATE_OUTGOING_ARGS really increase code size?


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jh at suse dot cz, ubizjak
                   |                            |at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/39148] -Os increase code size when stack is aligned
  2009-02-10 20:19 [Bug target/39148] New: -Os increase code size when stack is aligned hjl dot tools at gmail dot com
  2009-02-10 20:19 ` [Bug target/39148] " hjl dot tools at gmail dot com
  2009-02-10 20:46 ` hjl dot tools at gmail dot com
@ 2009-02-11 15:54 ` hjl dot tools at gmail dot com
  2009-02-11 17:12 ` jakub at gcc dot gnu dot org
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-02-11 15:54 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #2 from hjl dot tools at gmail dot com  2009-02-11 15:54 -------
One way to fix this is to set ACCUMULATE_OUTGOING_ARGS to false
when we need stack alignment.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/39148] -Os increase code size when stack is aligned
  2009-02-10 20:19 [Bug target/39148] New: -Os increase code size when stack is aligned hjl dot tools at gmail dot com
                   ` (2 preceding siblings ...)
  2009-02-11 15:54 ` hjl dot tools at gmail dot com
@ 2009-02-11 17:12 ` jakub at gcc dot gnu dot org
  2009-02-11 17:16 ` hjl dot tools at gmail dot com
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-02-11 17:12 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #3 from jakub at gcc dot gnu dot org  2009-02-11 17:11 -------
If you mean setting ACCUMULATE_OUTGOING_ARGS to true, I bet that could help
very small functions that need dynamic realignment, but certainly for larger
functions !ACCUMULATE_OUTGOING_ARGS results in smaller code, even if
realignment is done.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/39148] -Os increase code size when stack is aligned
  2009-02-10 20:19 [Bug target/39148] New: -Os increase code size when stack is aligned hjl dot tools at gmail dot com
                   ` (3 preceding siblings ...)
  2009-02-11 17:12 ` jakub at gcc dot gnu dot org
@ 2009-02-11 17:16 ` hjl dot tools at gmail dot com
  2009-02-12  0:45 ` hjl dot tools at gmail dot com
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-02-11 17:16 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #4 from hjl dot tools at gmail dot com  2009-02-11 17:16 -------
(In reply to comment #3)
> If you mean setting ACCUMULATE_OUTGOING_ARGS to true, I bet that could help

Oops. Yes, I meant setting ACCUMULATE_OUTGOING_ARGS to true when stack
alignment is needed.

> very small functions that need dynamic realignment, but certainly for larger
> functions !ACCUMULATE_OUTGOING_ARGS results in smaller code, even if
> realignment is done.
> 

Joey and Xuepeng are running

http://www.inf.u-szeged.hu/csibe/

to see how ACCUMULATE_OUTGOING_ARGS affects code size.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/39148] -Os increase code size when stack is aligned
  2009-02-10 20:19 [Bug target/39148] New: -Os increase code size when stack is aligned hjl dot tools at gmail dot com
                   ` (4 preceding siblings ...)
  2009-02-11 17:16 ` hjl dot tools at gmail dot com
@ 2009-02-12  0:45 ` hjl dot tools at gmail dot com
  2009-02-12  2:33 ` Joey dot ye at intel dot com
  2009-02-12  2:37 ` hjl dot tools at gmail dot com
  7 siblings, 0 replies; 9+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-02-12  0:45 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #5 from hjl dot tools at gmail dot com  2009-02-12 00:44 -------
I tried -maccumulate-outgoing-args on 2.6 kernel:

   text    data     bss     dec     hex filename
5136786  600084 1003520 6740390  66d9a6 vmlinux
5086759  600084 1003520 6690363  66163b /tmp/vmlinux.old

It does increase binary size. Should we consider to
turn on ACCUMULATE_OUTGOING_ARGS when stack is aligned?
If ACCUMULATE_OUTGOING_ARGS is off, ECX will be used
for stack alignment and it may lead to code size
increase due to register spill since ia32 has very
few registers.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/39148] -Os increase code size when stack is aligned
  2009-02-10 20:19 [Bug target/39148] New: -Os increase code size when stack is aligned hjl dot tools at gmail dot com
                   ` (5 preceding siblings ...)
  2009-02-12  0:45 ` hjl dot tools at gmail dot com
@ 2009-02-12  2:33 ` Joey dot ye at intel dot com
  2009-02-12  2:37 ` hjl dot tools at gmail dot com
  7 siblings, 0 replies; 9+ messages in thread
From: Joey dot ye at intel dot com @ 2009-02-12  2:33 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #6 from Joey dot ye at intel dot com  2009-02-12 02:33 -------
(In reply to comment #5)
> If ACCUMULATE_OUTGOING_ARGS is off, ECX will be used
> for stack alignment and it may lead to code size
> increase due to register spill since ia32 has very
> few registers.
The code increase resulted from stack realign are mainly from prologue
increase. ECX is only used as hard register in prologue/epilogue and the impact
to function body is low.

If ACCUMULATE_OUTGOING_ARGS does increase code size, then for big functions,
benefit of !ACCUMULATE_OUTGOING_ARGS will offset increase of prologue/epilogue.

So simply enable ACCUMULATE_OUTGOING_ARGS for stack realign isn't be the best
option for all cases either.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/39148] -Os increase code size when stack is aligned
  2009-02-10 20:19 [Bug target/39148] New: -Os increase code size when stack is aligned hjl dot tools at gmail dot com
                   ` (6 preceding siblings ...)
  2009-02-12  2:33 ` Joey dot ye at intel dot com
@ 2009-02-12  2:37 ` hjl dot tools at gmail dot com
  7 siblings, 0 replies; 9+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-02-12  2:37 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #7 from hjl dot tools at gmail dot com  2009-02-12 02:37 -------
(In reply to comment #6)
> So simply enable ACCUMULATE_OUTGOING_ARGS for stack realign isn't be the best
> option for all cases either.
> 

OK. I am closing as WONTFIX.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2009-02-12  2:37 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-02-10 20:19 [Bug target/39148] New: -Os increase code size when stack is aligned hjl dot tools at gmail dot com
2009-02-10 20:19 ` [Bug target/39148] " hjl dot tools at gmail dot com
2009-02-10 20:46 ` hjl dot tools at gmail dot com
2009-02-11 15:54 ` hjl dot tools at gmail dot com
2009-02-11 17:12 ` jakub at gcc dot gnu dot org
2009-02-11 17:16 ` hjl dot tools at gmail dot com
2009-02-12  0:45 ` hjl dot tools at gmail dot com
2009-02-12  2:33 ` Joey dot ye at intel dot com
2009-02-12  2:37 ` hjl dot tools at gmail dot com

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