Re: dangerous cleverness? ppc int<->float conversions, subreg

[Joern Rennecke <amylaar at onetel dot net dot uk>]

Zack Weinberg wrote:
> 
> On Sat, Oct 27, 2001 at 02:25:12AM +0100, Joern Rennecke wrote:
> ...
> > OTOH, if you can get the compiler to understand the varargs call sites enough
> > to determine if fp is used or not, you'll get more milage by having two
> > entry points for varargs functions: one that does fp regs varargs setup
> > and register saves where appropriate, and one that elides them.
> 
> This sounds sort of like what PPC turns out to do already: if bit 6 of
> the condition register is set, the caller passed floating point
> arguments; otherwise not.
> 
> I could probably recycle the code to do this for other targets with
> the same problem.  The main one that Wind River's interested in is
> SH.  I've been having trouble finding coherent docs of its ABI and
> floating point model; maybe you can shed some light?

The incoherence that you perceive may be because there are really four
different ABIs that the FSF gcc uses (multiply by two for big / little
endian).
-m1, -m2, -m3 and -m4-nofpu share one ABI with software floating point.
-m3e and -m4-single-only use an ABI which uses 32 bit hardware floating
point, defining double as 32 bit floating point.
-m4 and -m4-single each use a different ABI which has 32 and 64 bit hardware
floating point; they differ in the function entry / exit setting of the
floating point control register.

> I am concerned about breaking compatibility with other compilers for
> VxWorks if I start mucking with the calling convention like this -
> there's another (proprietary) compiler used, and they have to
> interoperate down to function call level.  They do have the ability to
> modify that compiler, though.

You can just leave the floating-point supporting entry point for varargs
callees with the old name, and use some name mangling into implementation
name space for the new fp-eliding entry point.
The generation of the new entry point could be option and/or attribute
controlled to avoid bloat for functions where you would never use them.

The generation of callers of the new entry point can be made dependent
on a new optimization option, to avoid backwards compatibility issues,
and you can probably use the format attributes that are currently used
for warnings to provide you with information on when floating point
arguments are passed, for those functions that can be described that way.

-- 
Joern Rennecke                  |            gcc expert for hire
amylaar@onetel.net.uk           |  send enquiries to: jwr_jobs@onetel.net.uk