[LLVMdev] Proposal: intp type

Chris Lattner clattner at apple.com
Fri Nov 13 08:24:27 PST 2009


On Nov 12, 2009, at 11:29 PM, John McCall wrote:

>> sext/zext/trunc are very nice for the optimizer, we should keep  
>> them.  It means that the optimizer doesn't have to check that the  
>> input to a sext is bigger or smaller than the result, for example.   
>> Code that cares (e.g. instcombine) really likes this.
>
> We could just say that code has undefined behavior or is invalid if  
> the 'sext', 'zext', or 'trunc' is inappropriate for the actual size  
> of intptr.  I think this is reasonable;  if the frontend emits a  
> zext intptr to i32, and the pointer side is i64, that *should* be  
> invalid.  This way the optimizer gets to keep its assumptions and it  
> becomes the client's responsibility to ensure that its "target- 
> neutral" bitcode really is neutral for the range of platforms it  
> actually cares about.  Portable code can't be truncating arbitrary  
> pointers to some smaller type anyway;  if the client just wants to  
> munge the bottom bits, it can zext and trunc to and from i8/i12/ 
> whatever.

The optimizer assumes that the input and output of (e.g.) zext are  
both IntegerType's (which intptr won't be) and that the input is  
smaller (and thus non-equal to) the result type.  We really don't want  
to break these invariants,

-Chris



More information about the llvm-dev mailing list