On Jul 29, 2009, at 9:41 AM, David Greene wrote:> On Wednesday 29 July 2009 11:25, Dan Gohman wrote: > > >> Getelementptr now has an optional flag: inbounds. WIth this flag, >> >> if the result of a getelementptr is not in bounds of an allocated >> >> object, >> >> the result value is undefined. Note the the new getelementptr rule >> >> applies regardless of whether the keyword is present. >> > > How do the semantics of "inbounds" differ from the new GEP rules?In summary: The new GEP rule says that you can't dereference a pointer within an object if it was computed from a GEP based on a different object. The optional inbounds flag further constrains a GEP by saying that the integer arithmetic implied by a GEP won't overflow. Dan
On Wednesday 29 July 2009 13:25, Dan Gohman wrote:> The new GEP rule says that you can't dereference a pointer within an > object if it was computed from a GEP based on a different object.Ok.> The optional inbounds flag further constrains a GEP by saying that > the integer arithmetic implied by a GEP won't overflow.Then maybe it should be renamed. As I understand this, I could compute an overflowing GEP so that the end result os an address that is within the bounds of the object. That's still "in bounds" but is not "inbounds." -Dave
On Jul 29, 2009, at 12:47 PM, David Greene wrote:> On Wednesday 29 July 2009 13:25, Dan Gohman wrote: > >> The optional inbounds flag further constrains a GEP by saying that >> >> the integer arithmetic implied by a GEP won't overflow. >> > > Then maybe it should be renamed. As I understand this, I could > compute > an overflowing GEP so that the end result os an address that is > within the > bounds of the object. That's still "in bounds" but is not "inbounds."Aha, good catch! I'll rename the keyword and reword the documentation in terms of integer overflow. Dan