[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