Cmm, signed 16-bit values and the PowerPC

[Simon Marlow]

> Houston, we have a problem: the Cmm datatype doesn't contain enough 
> information for proper PPC code generation.
> 
> On the PowerPC, signed 16-bit-values are usually sign-extended when 
> they are loaded into a register. The Mac OS X calling 
> convention for C 
> mandates this for 'short' parameters passed in registers. Unsigned 
> short parameters must always have their high bits cleared.
> But neither the CmmLoad expression nor the CmmCall statement is 
> annotated with the necessary signed/unsigned flags, so I'm stuck.
> Via-C code generation will probably work because the missing 
> information about signedness/unsignedness can be supplied via 
> function prototypes.
> 
> I'd only need an annotation in one of those two places, but 
> I'm not yet 
> sure which place is better (I haven't yet decided whether it's better 
> to sign-extend earlier or later :-) ). Also, who knows what 
> needs other processors will have...

I think this is ok: the code generator (STG->Cmm) will need to do the
promotion of C call arguments.  You'll see expressions like this: for a
call to a function "f" which takes a 16-bit signed argument:

    CmmCall (Left "f") CCallConv [r] 
     [CmmMachOp (MO_S_Conv I16 I32) [...]]

i.e. the sign extension is explicit.  On many architecture the code
generator can generate a single sign-extending load when it sees a sign
extension around a CmmLoad (eg. see the x86 code gen).  Similarly for
the unsigned I16->I32 conversion.

I think the lack of signedness in MachRep is a win, it's certainly made
things simpler for the x86 code gen, and the backend is now much more
honest about the sizes of things.

Cheers,
	Simon