[llvm-commits] [llvm] r43071 - in /llvm/trunk: include/llvm/CodeGen/SelectionDAG.h include/llvm/Target/TargetLowering.h lib/CodeGen/SelectionDAG/LegalizeDAG.cpp lib/CodeGen/SelectionDAG/LegalizeDAGTypes.cpp lib/CodeGen/SelectionDAG/SelectionDAG.cpp

[Duncan Sands]

Hi Chris,

> > Return Expand from getOperationAction for all extended
> > types.  This is needed for SIGN_EXTEND_INREG at least.
> > It is not clear if this is correct for other operations.
> > On the other hand, for the various load/store actions
> > it seems to correct to return the type action, as is
> > currently done.
> 
> I'm not sure about this change.  It seems to make more sense for an  
> i17 add to return promote, not expand, no?  OTOH, <128 x float> add  
> should return expand.

at this point all return values and operands have been legalized by
LegalizeDAGTypes.  SIGN_EXTEND_INREG also holds the value type to extend,
and this value type may not be legal, in fact most likely it is hardly ever
legal.  The code calls getOperationAction to see what to do.  If this returns
Expand then it turns the node into a series of shifting, masking operations
(and this is what you want for funny sized integers).  As such, here
Expand means: expand into a sequence of code, and has nothing to do with
whether this type is getting bigger or smaller.  As for i17 add,
this is quite different, and will have been dealt with by LegalizeDAGTypes.
That said, returning Expand is most likely wrong for other cases.  But
it will do for the moment and doesn't make things worse.

> More generally, I don't think we want to *ever* call  
> getOperationAction on invalid types, but I know of at least one case  
> where we do, and am not sure how to change it (x86 supports fp to i64  
> even though i64 isn't legal).

In a case like SIGN_EXTEND_INREG it is normal that the type may be
invalid.  The only two actions are: do nothing or expand into shifts.
Now it may be that you should do nothing if and only if the type is
legal.  In that case there is no need to call getOperationAction at
all.  For other operations I can imagine that the legal and illegal
type cases should be treated separately (though perhaps sharing code),
with only the legal case calling getOperationAction.  However there
are also calls to getOperationAction for illegal types in order to
see whether the action is Custom (there are such calls in LegalizeDAGTypes).
Can there be custom actions for illegal types?

Ciao,

Duncan.