This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bizarrely Poor Code from Bizarre Machine-Generated C Sources


"Barak A. Pearlmutter" <barak@cs.nuim.ie> writes:

>But none of the structures are on the heap (no malloc) and we never
>take any addresses, so in theory they could be held in registers and
>kept in fragmented representations and that sort of thing.  I do not
>know if GCC can do that, or if there's any way to tell it to.

GCC usually (always?) obeys the platform ABI even for static
functions. Some ABIs pass small structs in registers (x86-64 and
SPARC-V9, and others) but older ABIs do not (32-bit x86 in particular).

(For some reason I never understood even the enlightened ABIs are
asymmetrical; they allow more registers for passing arguments than for
return values. Perhaps tradition and the lack of multiple return
values in C are to blame.)

>Right; -O3 didn't make any qualitative difference.  (I certainly tried
>that before posting.)  I do see a whole bunch of inline-related
>parameters in the GCC documentation, but it is not clear which I
>should tweaked.  I tried -O3 -flinline-limit=60000 (default 600) but
>even that doesn't make any qualitative difference.

If you think you know better than the compiler, declare your
functions with __attribute__ ((always_inline)). Example:

static inline __attribute__ ((always_inline)) double square(double x)
{ return x * x; }


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]