[LLVMdev] proposed new rule for getelementptr

[Eli Friedman]

On Thu, Jul 23, 2009 at 1:59 AM, Mark Shannon<marks at dcs.gla.ac.uk> wrote:
> What you are proposing is a major change in the semantics of llvm.

The thing is, it isn't really a big change; it's essentially what we
already implement.

> I notice no mention of bitcasts on pointers here.
>
> Intermediate representations are often full of weird-looking, but
> correct, pointer arithmetic.

A bitcast of a pointer is still the same pointer for the purposes of
this section.

> Lots of C code passes pointers around which might point to the middle of
> an array, say for searching. That means that negative indices could
> still remain within an allocated object.

Umm, right... GEP should be explicitly documented to take signed
indices.  Anyway, this isn't actually saying anything about the given
example, because that's still the same object (the array).

>> With this rule, BasicAliasAnalysis and similar analyses that depend
>> on being able to track a pointer value up to its base value will be
>> able to safely climb through getelementptr definitions without
>> needing any further guarantees.
> So all this breakage is for a few optimisation passes, that I don't even
> use?

If your code is such that BasicAA isn't correct, it's already well
into undefined territory; you're basically redefining your own IR
semantics.

> Add a "strict-GEP", which does what you suggest. This would allow
> front-ends to tell the back-end about what things cannot be aliased,
> and not cause any breakages for code that uses the "old" GEP.

This isn't actually proposing any immediate code changes except adding
a new flag to GEP for strict overflow semantics.

-Eli