This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: __attribute__((naked) on x86 would be useful
On Mon, Feb 16, 2004 at 09:55:25AM -0500, Mat Hostetter wrote:
> >>>>> "rth" == Richard Henderson <rth@redhat.com> writes:
>
> rth> Certainly the compiler can handle this ---
>
> >> My main use for this is for some small machine-generated assembly
> >> language trampolines that implement multiple inheritance
> >> (e.g. offset a "self" parameter and jump elsewhere)...
>
> rth> all by itself at -O2.
>
> OK, fair question. I tried this:
>
> extern int bar (int x, int y, int z, double q, float r);
> int
> foo (int x, int y, int z, double q, float r)
> {
> return bar (x + 16, y, z, q, r);
> }
>
> gcc -O2 does figure out the tail call, which is nice, but it turns
> what I'd like to be two instructions:
>
> addl $16,4(%esp)
> jmp bar
>
> into seven:
>
> foo:
> pushl %ebp
> movl %esp, %ebp
> movl 8(%ebp), %eax
> addl $16, %eax
> movl %eax, 8(%ebp)
> leave
> jmp bar
>
> I also tried -fomit-frame-pointer, but unfortunately that kills the
> tail call optimization.
-O2 -fomit-frame-pointer compiles this into
movl 4(%esp), %eax
addl $16, %eax
movl %eax, 4(%esp)
jmp bar
on both gcc-3_3-rhl-branch and gcc-3_4-branch.
> Interestingly, that movl/addl/movl in the middle there could just as
> well be one instruction. Perhaps there is a missing peephole
> optimization, or something is missed in the interaction between tail
> calls and peephole optimizations.
Why? You are not optimizing for space, and the 3 insns are faster I think
(contemporary IA-32 CPUs prefer simple instructions).
> Also, is there any chance gcc could "forget" the current asm section
> when it emits user assembly code, since that assembly may change the
> section behind its back? I haven't checked, but that sounds like a
If the __asm changes the section behind GCC's back, it should restore
it back at the end, say:
asm (".section foobar; something; .previous");
Jakub