[llvm-dev] Opaque pointers and i8 GEPs

[Nikita Popov via llvm-dev]

On Sat, Sep 4, 2021 at 9:16 PM Arthur Eubanks <aeubanks at google.com> wrote:

> 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
>

Yeah, I don't think inrange is compatible with this. I think we can safely
keep using a typed GEP for the special case of a constexpr GEP based on a
GlobalValue, for the time being. There's a clear type to use in that case.
I suspect that even apart from the inrange specifier some of our
globals-related optimizations currently rely on typed GEPs. We're very good
at treating GEPs as pure offset arithmetic for GEP instructions, but not so
good when it comes to constant expressions.

Regards,
Nikita

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/7ddc02c4/attachment.html>