On Jul 22, 2009, at 12:33 PM, David Greene wrote:> On Wednesday 22 July 2009 13:30, Dan Gohman wrote: > > >> - A pointer value formed by a ptrtoint is associated with all >> address >> >> ranges of all pointer values that contribute (directly or >> >> indirectly) to the computation of the pointer's value. >> > > Do you mean inttoptr here? And that "all pointer values that > contribute > (directly or indirectly) to the computation of the pointer's value" > could > equally mean "all pointer values that contribute (directly or > indirectly) to > the computation of the integer's value?"Yes, I meant inttoptr instead of ptrtoint here.> > >> - An integer value other than zero may be associated with address >> >> ranges allocated through mechanisms other than those provided by >> >> LLVM; such ranges shall not overlap with any ranges of address >> >> allocated by mechanisms provided by LLVM. >> > > What's the intent here? Are you basically saying that memory > regions accessed > through random integer arithmetic can't overlap memory regions > allocated by > alloca, malloc, etc.? If so, my sense is that's too demanding. In > general > one does not know the aliasing properties of addresses computed > entirely by > integer arithmetic. It could be some misguided user trying to > "help" the > compiler by explicitly linearizing addressing or it could be an > embedded > developer computing a memory-mapped I/O address. There's just no > way to > know.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. 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.> > >> Front-ends that do crazy things to pointers may need to use >> >> ptrtoint+arithmetic+inttoptr instead of getelementptr. If the >> >> target-independent properties of getelementptr are needed, the >> >> "getelementptr null" trick may be useful. >> > > 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. Dan
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
On Jul 22, 2009, at 1:13 PM, David Greene wrote:> 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.Without this assumption, much of LLVM would be useless. It's more practical to make LLVM entirely useless to obscure hypothetical users than to make it mostly useless to most current real users.> 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.If anyone comes forward with a real problem that this is causing, we'll consider the problem in context, where there may be alternative solutions. Dan