Mail Archives: djgpp/1998/10/20/02:01:58
Robert Hoehne wrote:
> Ilya Ryzhenkov wrote :
> >
> > For Robert :
> > Aint' time has came to implement profiles in rhide ?
> > i.e. different set of options/sources for different targets.
> > Or i'm missing something?
>
> Do you have any hints what options should be en-/disabled
> for such targets? Let say the following:
>
> - fastest code
> - smallest code
> - developing code
> - releasing code
>
> Please tell your opinion. Maybe others too (in the hope that
> this thread will not go endless :-)
>
My opinion? Sure:
Fastest code: -O3 -mpentium -fomit-frame-pointer -ffast-math
Smallest code: -O -mpentium -malign-loops=0 -malign-jumps=0
-malign-functions=0
Developing code: -W -Wall -Wno-sign-compare -g -O0
-fno-omit-frame-pointer
Releasing code: <same as fastest code>
Some may argue that O3 is slower than O2. I think that O3 is only faster
if -mpentium is specified. O3 and -m386 will produce reams and reams of
inline code (because a 386 usually has no cache, and has a terrible
branch (taken or not) penalty), but with -mpentium, much less inline
code is produced. The inlining of static functions is also beneficial.
BTW If you *really* want smallest (and fastest) code, add the option
-mrtd and put __attribute__((cdecl)) in your main function declaration.
This will remove a lot of "addl $<constant>,%esp" in the code, that
option (-mrtd) enables stdcall function calls by default. Come to think
of it, I think that would cause problems with the standard library. That
could be fixed by making a __cdecl macro ( #define __cdecl
__attribute((cdecl)) ) and putting __cdecl throughout the standard
headers (like the Borland headers). Or even better, compile a libc with
that option specified and optionally choose it (rather than the stock
libc) when linking by tweaking the specs file, or by manually selecting
it with a command line switch.
- Raw text -