top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Function Parameters vs. Prologue (fastcall + O1 + -fschedule-insns2)

0 votes
331 views

I'm curious about what is causing this reordering (prologue with the function parameters):

# gcc structs.c -o structs -m32 -O1 -fschedule-insns2

(gdb) disas main
Dump of assembler code for function main:
 0x0804868c : push %ebp
 0x0804868d : mov $0x3,%edx
 0x08048692 : mov %esp,%ebp
 0x08048694 : mov $0x2,%ecx
 0x08048699 : and $0xfffffff0,%esp
 0x0804869c : call 0x804845c

The code:

__attribute__((fastcall)) void funcao(int i, int a) {
...
int main() {

 int i, a;
 i = 2;
 i = 3;

 funcao(i, a);
...

When I remove one of them (fastcall or schedule-insns2), the binary is generated in logic order:

(gdb) disas main
Dump of assembler code for function main:
 0x08048340 : push %ebp
 0x08048341 : mov %esp,%ebp
 0x08048343 : and $0xfffffff0,%esp
 0x08048346 : sub $0x10,%esp
 0x08048349 : movl $0x3,0x4(%esp)
 0x08048351 : movl $0x2,(%esp)
 0x08048358 : call 0x8048450 

... or

(gdb) disas main
Dump of assembler code for function main:
 0x0804868c : push %ebp
 0x0804868d : mov %esp,%ebp
 0x0804868f : and $0xfffffff0,%esp
 0x08048692 : mov $0x3,%edx
 0x08048697 : mov $0x2,%ecx
 0x0804869c : call 0x804845c

Someone knows something about the combined use of the fastcall attribute and schedule-insns2 option? Is there an issue?

posted Jun 18, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

0 votes

I know that -fschedule-insns2 reorder the instructions to avoid bubble, but I did a benchmark that resulted in a more fast code without this reordering.

answer Jun 19, 2013 by anonymous
File a missed-optimization bug report?
I'm not really sure what you are asking.
commented Jun 19, 2013 by anonymous
Similar Questions
0 votes
gcc: difference -g -O1 vs. -O1

If I compile my embedded program with options "-g -O1" I obtain an elf file with debug information. I can objcopy the elf file to a binary or hex file that can be loaded to flash, effectively striping out the debug
information leaving only the optimized code in ROM.

But if I re-build with options the same except omit the -g option, obviously I will have no symbols in the elf file making debugging impossible or at least more difficult. However, when I object copy this elf to a binary or hex file they are different somewhat than the binary or hex produced with options -g present. At least with 4.7.3 the main difference, as seen with objdump, is in the prologue to certain function calls with only a few bytes different in total code length on a fairly large embedded application (arm). So -g has some effect on the actual code produced it appears.

Is this difference expected? Should -g cause changes in the actual code generated and not just add debug symbols to the elf? Possibly it is related to the optimization level? I have not checked to see if the
results differ with higher or lower levels than -O1.

I have seen several opinions regarding this but no authoritative answer. The gcc manual also does not really answer this.

+1 vote
Function cast leads to gcc abort command?

in the following code func.c :

 int Myfunc1(int i, int z)
 {
 return i;
 }

 int main()
 {
 int ans;

 /* casting the function into an 'int (int)' function */
 ans = ((int(*)(int))(Myfunc1))(5);

 printf("ans: %dnn", ans);

 return 0;
 }

I tried to cast an int(int,int) function into an int(int) function an got the gcc warning and note:

 func.c:13:32: warning: function called through a non-compatible type [enabled by default]
 func.c:13:32: note: if this code is reached, the program will abort

and when trying to run I get:

 Illegal instruction (core dumped)

But if i compile this file with a .cpp ending with the gcc compiler it works OK.

+5 votes
How a function can access value of local variable of another function whose stack is already gone?

Even I have similar problem:

int (*pfun)(void);
int *pInt = 0;
void fun1()
{
    int i = 5; /* Local to fun1*/

    printf("Outer function");
    pInt = &i; /* As I know address of local variable is valid till function execution */

    int fun2()
    {
      printf("innerfunction");
      printf("%d", *pInt);
    }
    /* fun2 address assign to pfun so that It can be called even after completion of fun1 */
    pfun = fun2;
}

int main()
{
    fun1();
    pfun();
    return 0;
}

Can someone please explain ? I am getting *pInt value 5.

0 votes
Extending the core language via a gcc plugin possible?

is it possible to add a private extension to the core language (C/C++) by writing a gcc plugin?

The extension in mind is something like this

[variable_definitions;]

Later I want this be possible also inside statement headers, for example

for ([double d = 1.0; bool f = false;] size_t i = 0; i < vec.size(); ++i)
 ...

The scope of the so-defined variables shall be the same scope they are in, ie. in the for-loop case just the scope of the for-loop itself, much like the case with i.

...