16-bit target problem

Has any one been successful with a 16-bit target? I'm new to LLVM and am having problems. One problem I found stems from code in
lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp: visitRet():

  // If this is an integer return value, we need to promote it ourselves to
  // the full width of a register, since getCopyToParts and Legalize will use
  // ANY_EXTEND rather than sign/zero.
  // FIXME: C calling convention requires the return type to be promoted to
  // at least 32-bit. But this is not necessary for non-C calling conventions.
  if (MVT::isInteger(RetOp.getValueType()) &&
      RetOp.getValueType() < MVT::i64) {
       MVT::ValueType TmpVT;
       if (TLI.getTypeAction(MVT::i32) == TargetLowering::Promote)
         TmpVT = TLI.getTypeToTransformTo(MVT::i32);
       else
         TmpVT = MVT::i32;

This is wrong in at least two ways:
1. First it encodes C semantics in the backend, making other language
    front-ends difficult. The comment indicates that this is to be fixed.
2. But it even gets the C semantics wrong, the promotion is to "int", whatever
    an "int" is on the target machine, not always 32 bits. How soon the PDP-11
    is forgotten!

  // If this is an integer return value, we need to promote it ourselves to
  // the full width of a register, since getCopyToParts and Legalize will use
  // ANY_EXTEND rather than sign/zero.
  // FIXME: C calling convention requires the return type to be promoted to
  // at least 32-bit. But this is not necessary for non-C calling conventions.
  if (MVT::isInteger(RetOp.getValueType()) &&
      RetOp.getValueType() < MVT::i64) {
       MVT::ValueType TmpVT;
       if (TLI.getTypeAction(MVT::i32) == TargetLowering::Promote)
         TmpVT = TLI.getTypeToTransformTo(MVT::i32);
       else
         TmpVT = MVT::i32;

This is wrong in at least two ways:
1. First it encodes C semantics in the backend, making other language
    front-ends difficult. The comment indicates that this is to be fixed.
2. But it even gets the C semantics wrong, the promotion is to "int", whatever
    an "int" is on the target machine, not always 32 bits. How soon the PDP-11
    is forgotten!

Right, why aren't front-ends responsible for using a wide-enough type?

Ciao,

D.

There is no good reason other than historical accident and lack of foresight.

Having the CFE's lower to integer returns to always use the appropriate size of int would expose the sign/zero extends that are happening implicitly, and would be general goodness. It would also let us eliminate the zeroext/signext attributes on the functions.

This sounds like a great project.

-Chris