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

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

[Zbigniew Chamski]

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

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

[Eric Botcazou]

> 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.

Missing "still" here: "the cast code is still replicated at call sites".  The 
patch doesn't change that since, at you pointed out, this is the ABI.

> * 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

Not clear what is this solution.  You still need to extend at the caller site 
as per the ABI, either at the prototype level or at a lower level.  GCC 4.5 
does the former whereas GCC 4.6 will do the latter; the code is identical on 
the caller side, only the caller side change.

> * 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)

This is somewhat orthogonal, but inlining can be tuned indeed.

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

I'm not convinced this would necessary improve things.  SPARC is a 32-bit
architecture, all instructions operate on 32-bit so you'll need to extend
the values at some point.

> 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.

As I already mentioned several times, the code at the caller side is already 
sensible except for the case of volatile objects.  Optimizing this volatile 
case is largely orthogonal to the calling conventions problem, it's a more 
general (and more delicate) problem.

-- 
Eric Botcazou