<div dir="ltr">Does this break the inrange specifier for <a href="https://llvm.org/docs/LangRef.html#getelementptr-instruction">GEPs</a>? 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.<div><br><div>Initial inrange proposal: <a href="https://lists.llvm.org/pipermail/llvm-dev/2016-July/102472.html">https://lists.llvm.org/pipermail/llvm-dev/2016-July/102472.html</a><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 4, 2021 at 6:08 AM David Chisnall <<a href="mailto:David.Chisnall@cl.cam.ac.uk">David.Chisnall@cl.cam.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 4 Sep 2021, at 10:17, Nikita Popov via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> <br>
> 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.<br>
<br>
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:<br>
<br>
1. Always generate GEPs with i8 offsets with all address calculation in the arithmetic leading up to the operation.<br>
2. Canonicalise all other GEPs to this form.<br>
3. Remove support for other kinds of GEP.<br>
<br>
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.<br>
<br>
David<br>
<br>
</blockquote></div>