[LLVMdev] Proposal: intp type

[Kenneth Uildriks]

> Well, as far as intp goes (or iptr if you prefer - the naming convention in
> LLVM is i<size>), here's what I would expect:
>
> General rule #1: If an instruction accepts both i32 and i64, then it should
> accept iptr as well. If it only accepts i32, then it can continue to only
> accept i32.
> General rule #2: It should support operations that are commonly used with
> size_t and ptrdiff_t.
> Operations that should work with iptr:
>
> Basic math: add, subtract, multiply, divide, mod.
> Bitwise binary operators: shl, ashr, lshr, and, or, xor, etc.
> Comparison operations.
> alloca - currently doesn't work with i64, should it?

I would say it should work with iptr.  It's the size of a region of
memory after all, and that's one of the things that iptr is *supposed*
to be used for.  For that matter, I was surprised to find that it
didn't work with i64...

> GEP - rules are the same as for using i64 indices.
> memcpy intrinsics
> bit manipulation intrinsics
> overflow arithmetic intrinsics - would be nice
> atomic intrinsics - would be very nice (I assume that atomic iptr works on
> all platforms that support atomics: That is, on 32-bit platforms where iptr
> == i32 I expect atomic i32 to work; on 64-bit platforms where iptr == i64 I
> expect atomic i64 to work).
>
> Operations that don't need to work with iptr - i.e. I don't mind having to
> convert to some other int type first:
>
> switch
> extractelement / insertelement / shufflevector
> extractvalue / insertvalue - not sure about these.
> code generator intrinsics (frameaddress, etc.)
>
> Converting to pointer types: inttoptr and ptrtoint should be no-ops,
> effectively.
> Converting to other integer types: The issue here is that with other integer
> conversions in LLVM, you are required to know whether or not you are
> converting to a larger or smaller size - whether to use an ext or a trunc
> instruction. When converting to pointers, however, the choice of trunc or
> ext is automatic. Ideally, conversion to iptr would work the same way as
> conversion to a pointer type. There's also the issue of signed vs. unsigned
> extension.

The best thing I can think of is for conversions to/from iptr to use
zext/sext, whether or not it's actually extending anything.  I need to
do some digging and see if that would break anything.

>
> Note that some constant-folding operations would need to be deferred until
> the target size is established.
>
> Converting to FP types: Either don't support (i.e. require casting to
> known-width integer first), or map to i32->FP or i64->FP after the size is
> known.
>
> --
> -- Talin
>