llvm dev - Feb 2008 - [LLVMdev] 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.

On Wed, 27 Feb 2008, Duncan Sands wrote:
>>   // 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.
>> 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?
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

-- 
http://nondot.org/sabre/
http://llvm.org/