[LLVMdev] proposed new rule for getelementptr
dag at cray.com
Wed Jul 22 13:13:48 PDT 2009
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.
More information about the llvm-dev