[LLVMdev] Proposal: intp type

[John McCall]

Chris Lattner wrote:
> 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,

I didn't realize that an identity zext was actually invalid IR.  That 
seems like it probably causes more trouble than it's worth.

Anyway, I suspect the question is whether you would rather break these 
invariants (which are probably not critical for most optimizations) or 
slowly accumulate duplicate code paths in every pass that looks at zexts 
and truncs.

John.