Re: gcc/sdbout.c and char parameters

[Jim Wilson <wilson@cygnus.com>]

	> I also believe that gcc will say the parameter has type `int' when optimizing,
	> but that there is no practical way to fix this in the sdbout format.  Is
	> this the only thing you are complaining about?

	Yes, but I always compile with optimization :).

Unfortunately, the sdbout format was not designed for compilers that can
both optimize and emit debug info at the same time.  And because it is
unextensible, this problem can't be easily fixed.

	> If you look at the RTL dumps, you can see that the parameter is an int, that
	> gets truncated to a char, and then sign-extended to a short.  Gcc believes
	> that the value being passed in is an int, it just isn't taking advantage of
	> this fact to generate faster code.

	No, Gcc knows that the value passed is a char, but padded to fit the size of
	an int.

No, what I said was correct, but the distinction is a subtle one.  For the port
that you are using, we really are passing an int and converting it to char.
This always happens for old-style function declarations.  This happens for
prototyped function declarations only if PROMOTE_PROTOTYPES is defined, and
this is defined for your port.  This can be seen if you look at the tree
structures that gcc is using.  Look at parm->decl.initial, and note that
it is int.  This is the type that gcc is using the value passed in and this
has nothing to do with padding.  If you undefine PROMOTE_PROTOTYPES, then this
type will be char.  This distinction is easier to see on a 64 bit machine
with 32 bit ints, where the incoming rtl will be SImode even though stack
slots and registers are DImode.

	> Gcc is instead generating more portable
	> code.

	Gcc generates the right code.  If it did not truncate the pseudo-int,
	the result would be wrong.

Perhaps, but what I said was still true, gcc is generating the most
conservative calling convention code for best portability.  The gcc m68k port
promotes a char argument to int before a call, so that the callee will
work regardless of whether the callee was expecting an int or char.  Also,
the gcc m68k port truncates a char parameter from a passed int in the
prologue, which will always work regardless of whether the caller passed an
int or a char.  This is not the most efficient code, but it is the most
portable.  For the most efficient code, we can eliminate one or both of these
conversions.  Whether or not this will work depends on how other compilers
work, and whether you have any hand written assembly routines that make
different assumptions than the compilers.

Jim