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

[Eric Botcazou <ebotcazou@adacore.com>]

> 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