[LLVMdev] proposed new rule for getelementptr

[David Greene]

On Wednesday 22 July 2009 15:05, Dan Gohman wrote:

> The intent is to cover code like this:
>
>      %p = alloca i32
>      %q = inttoptr i64 0123456789 to i32*
>
> Here, %p and %q are assumed to be non-aliasing. This kind of thing
> is used by some JITs; they allocate objects via custom mechanisms
> and then tell LLVM IR about the address of the objects via magic
> integer constants like this. The optimizer is already making this
> assumption today, though implicitly.

But how do you know 0123456789 doesn't point to the same thing %p does?
I understand it's highly unlikely and that we'd like to define that
there's no aliasing.  I just get a little squeemish, especially when
considering embedded devices.

> If the user hand-linearizes addressing using casts to integers,
> it will still be supported -- that's what the broad language for
> inttoptr above is intended to cover.

Right.  I was thinking more along the lines of the user "knowing" where
some global is allocated and computing that address directly, without
using pointers at all.

> > To clarify, the ptrtoint+arithmetic+inttoptr would still be legal?
>
> Yes, subject to constraints in the bullet point quoted at the
> top of this email, which effectively just spelling out rules that
> are already assumed today.

Those rules are ok, I think.  It's the computed-integer problem that
is gnawing at me.

I *think* the C standard says there can't be an alias and I assume the
Fortran standard does as well.  But even so, we all know that users
often ignore standards when convenient.

                               -Dave