[LLVMdev] Proposal: intp type

[Kenneth Uildriks]

Simply put, it's a pointer-sized integer.  I'm blatantly stealing this
idea from .NET, where IntPtr (a pointer-sized integer) is a basic
type.

In my front end, I had considered just using a pointer for intp
behind-the-scenes and doing conversion to/from int64 when I wanted to
do arithmetic on them, but pointers and integers don't always align
the same way.  So what I really want is a way to represent in IR that
a certain parameter/struct member is a pointer-sized integer.

Now that optimizations work without target data, I think we're
tantalizingly close to a situation where useful, target-independent IR
files are a real possibility.  intp is one of the remaining pieces of
that puzzle; lots of native code expects an integer parameter/struct
member sized the same as a pointer.  It makes sense for sizes and
offsets to be represented this way, and in a lot of cases, they are
represented this way, and in IR a lot more would be represented this
way if such a type existed.

Also, having this type present will tend over time to reduce the
number of casts to/from int64 appearing in bitcode that have to be
stripped out, slightly speeding up optimizations and codegen.

The ramifications that I see:

1. Conversions to/from other integer types: right now, integer type
conversions are always explicity specified as either a trunc, a sext,
or a zext.  Since the size of intp is not known at IR generation time,
you can't know whether a conversion to/from intp truncates or extends.

2. The usual ramifications of adding a new type: IR
generation/analysis, optimizations, and codegen all have to be updated
to deal with the existence of the new type.  The changes should be
minor; it's an integer type with all of the supported operations of
integer types, with the only difference being that its size cannot be
determined without target data.