NIOS C compilation and optimization issue

Perhaps you are calling the function with compile-time known constants - so the compiler is optimising away a lot of the code.

If the function isn't 'static' that shouldn't happen.

Or pass the parameters from statically initialised global variables - which the compiler can't know aren't changed before the call.

There is also the possibility that the compiler optimisations are enabled for one file, but not the other - unlikely if you are rebuilding these with the IDE.

If all else fails you'll need to look at the object code - that tends to show up what is actually happenning.

--- Quote Start ---

Perhaps you are calling the function with compile-time known constants - so the compiler is optimising away a lot of the code.

If the function isn't 'static' that shouldn't happen.

Or pass the parameters from statically initialised global variables - which the compiler can't know aren't changed before the call.

AlphaKha> Let me provide some more detail:

In both cases, the global variables are declared and initialized in main file mainsource.c to provide an easy to use list of test vectors. The values are passed to the Routine using pointers in both cases. The only difference is that in trial 2 the routine code from the mainsource.c is cut and pasted to another source file for the purpose of clarity and program organization. I am not clear how this produces the difference that in one case compiler knows about constants but in the other not. This may be the clue to this problem. Could you please comment on this.

There is also the possibility that the compiler optimisations are enabled for one file, but not the other - unlikely if you are rebuilding these with the IDE.

AlphaKh> Its ensured that compiler optimizations are enabled for all files.

If all else fails you'll need to look at the object code - that tends to show up what is actually happenning.

--- Quote End ---

AlphaKh > The obj dump file shows the same size of code in both cases and though I haven't checked the instructions line by line, however, seems the instructions are identical with one exception that address offsets are different.

No need to quote all the post ....

If the object code is the same, then maybe the difference is caused by additional instruction cache loads because code is now sharing instruction cache lines (the overall address map will probably have changed).

The data addresses are unlikely to be significantly different - but might be.

Running code from tightly coupled instruction/data memory (and with the dynamic branch prediction disabled) I got consistent timings that match the expected values.

You'll probably have to work it out yourself.

Might be worth simplifying the test to see what makes a big difference.

Sometimes repeating a code fragment can help identify which bits are slower than expected.