Cmm, signed 16-bit values and the PowerPC

[Simon Marlow]

> > 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.
> 
> OK, that solves the problem for PPC.
> It still precludes generating code in the "normal" way, i.e. always 
> sign-extending all 8-and-16-bit values when loading them into a 
> register.

You can still do that - but you might have to search the CmmExpr tree a
bit to find out whether the best choice is to sign-extend on a load or
zero-extend.

You have pointed out an interesting issue, though.  If the lack of sign
information in Cmm turns out to give you trouble, then we might see if
there's anything we can do to help.

Perhaps it's worth thinking about whether adding a signed-vs-unsigned
distinction to MachRep would be a good idea.  Pros:

  - It could be used to simplify the MachOp type (at the expense of some
    redundancy; signed addition is the same as unsigned at all sizes).

  - It would make code generation easier for platforms which only have
    word-sized registers.

  - It would mean that ccall-argument promotion could be left until the
    native code generator, because there is enough sign information to
    do it.

Cons:

  - It would mean some extra pattern matching in some backends.

  - There may be some extra conversions between signed & unsigned which
    clutter up the expressions.

  - More redundancy in the representation.

Simon: what's the C-- story here?  Is it up to the codegen to generate
good code in the absence of sign hints?

If we're to make this change, it would be easier to do it sooner rather
than later.

Cheers,
	Simon