[Bug target/46208] Sparc calling conventions (and overheads) in the embedded context

[Zbigniew Chamski <zbigniew dot chamski at gmail dot com>]

Dear Eric,

I'm picking up on the thread related to caller/caller side casting on
Sparc, your patch to target/46208, your comments in
http://gcc.gnu.org/ml/gcc-bugs/2010-10/msg02390.html and the ABI
issues in the embedded context.

To be compliant with the existing ABI, we clearly need to pass char
and short values as reg-wide ints.  With your (revised) patch for
46208, this is taken care of at the caller side only, meaning that the
cast code is replicated at call sites.

In the embedded world, where a lot of calls to small (usually leaf)
functions use subword arguments, this becomes a severe penalty.  It
can be reduced in three main ways:

* solution 1 (partial): by optimizing the generation of type promotion
code, cf. your comments in
http://gcc.gnu.org/ml/gcc-bugs/2010-10/msg02390.html
* solution 2 (partial): by reviewing and optimizing the inlining
settings to enable the inlining of  very small functions (there's a
lead in http://gcc.gnu.org/ml/gcc-help/2010-11/msg00170.html)

* solution 3 (radical): by consciously creating an ABI which would be
more friendly to the embedded world.

Solution 1 could significantly reduce the per-call-site overhead,
without eliminating it completely.  As you point out, it will require
work on the expand and emit code to make sure that in the end the
compiler emits sensible sequences of insns at each call site.

Solution 2 may lead to improvement, but only for (very) small
functions. On the other hand it would benefit a much wider audience -
at least the other embedded/embeddable GCC targets.

Solution 3 is a holistic approach...  As you put it in
http://gcc.gnu.org/ml/gcc-help/2010-10/msg00394.html, after 15 yers
it's hard to change the official "desktop"/"performance" ABI, but
maybe it's time to take into account the new reality: Sparc is now
deeply embeddable (and I mean deeply: it can run on the battery of a
cellphone or even on the energy from an induction loop).  This means
that a new application field with new constraints appeared for Sparc,
with code density and efficient RAM usage being the key to success
(defined as making the system use less memory resources and consume
less energy).  A well designed "embedded Sparc" ABI would help a lot
in this domain.  Sure it will affect the complete development
toolchain (compiler, binutils, debug), but properly designed it would
truly give a boost to the Sparc architecture in the embedded area.

Pragmatically: I'm ready to start on solution 1 and 2, in that order,
and to help with recommendations for solution 3.  Any suggestions and
comments are highly welcome.

Cheers,

    Zbigniew

--
dr Zbigniew Chamski - Infrasoft IT Solutions
ul. Oskara Kolberga 33, 09-407 PŁOCK, Poland
mobile: +48 668 773 916, phone: +48 24 262 0166
NIP 526-286-69-21, REGON: 141082454