[llvm-dev] Opaque pointers and i8 GEPs

[Arthur Eubanks via llvm-dev]

Does this break the inrange specifier for GEPs
<https://llvm.org/docs/LangRef.html#getelementptr-instruction>? I don't see
how we'd be able to use inrange to specify that a GEP can only access a
certain element in an allocated object if we use i8 GEPs. CC'ing Peter for
more thoughts.

Initial inrange proposal:
https://lists.llvm.org/pipermail/llvm-dev/2016-July/102472.html

On Sat, Sep 4, 2021 at 6:08 AM David Chisnall <David.Chisnall at cl.cam.ac.uk>
wrote:

> On 4 Sep 2021, at 10:17, Nikita Popov via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > My proposal here is that in opaque pointers mode, LLVM should consider
> i8 GEPs canonical for GEPs with constant offsets. We should not attempt to
> "guess" a good GEP type to use, and we should not try to generate complex
> GEP structures if a simple one will do. I don't think there's really any
> disadvantages to this, apart from the fact that it makes the discrepancy
> between typed and opaque pointer mode larger.
>
> I completely agree.  Eventually, I’d like GEP to lose the ability to have
> multiple type arguments and I think this is a good first step in that
> direction:
>
> 1. Always generate GEPs with i8 offsets with all address calculation in
> the arithmetic leading up to the operation.
> 2. Canonicalise all other GEPs to this form.
> 3. Remove support for other kinds of GEP.
>
> In the back end, a GEP is just a {PTR} + {expression that evaluates to an
> integer} add operation.  That’s what it looks like in any target and it’s
> the most that we guarantee about memory in the IR, so everything that looks
> as if it supports more than this adds complexity for no benefit.  It also
> means that we sometimes miss optimisation opportunities because GEPs can
> encode complex arithmetic expressions that are not CSE’d because they’re a
> separate and special kind of arithmetic.
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210904/532c9ec3/attachment.html>