[llvm-dev] Why are GEPs type based?

[Stefanos Baziotis via llvm-dev]

Hi,

Although I'm not an expert on the topic, there are at least two reasons:
1) It looks more like C/C++ than computing offsets. This goes hand in hand
with the fact that GEP abstracts
target-specific information. For example, a pointer is 4 bytes in a typical
32-bit system but 8 bytes in a 64-bit system.
If you have a struct like:
struct {
  int *p;
  int v;
};

To get `v`, with a GEP you just say "give me the second member". If you
were to code this with offsets, you would need to
know the target, something that generally front-ends are not good to have a
dependency on (Clang and other front-ends actually
have and that's another big discussion).

2) It's very important for alias analysis. Again, not an expert on that,
but e.g. see the first rule on when a pointer is based on
another (pointer) here: https://llvm.org/docs/LangRef.html#pointeraliasing

Best regards,
Stefanos

Στις Δευ, 13 Ιουλ 2020 στις 11:08 μ.μ., ο/η Nikita Popov via llvm-dev <
llvm-dev at lists.llvm.org> έγραψε:

> Hi,
>
> I've been wondering why LLVMs GEP instructions are based on types, rather
> than encoding the raw address calculation as a base pointer plus some
> scaled offsets (still in the form of a GEP, to retain provenance).
>
> The type information does not seem particularly useful (shouldn't be used
> as an optimization base, because struct layouts lie), but increases the
> non-canonical IR space (there are many ways to encode the same GEP) and
> increases compile-time (optimizations need to constantly decompose GEPs,
> e.g. to get constant offsets).
>
> What am I missing here?
>
> Nikita,
> Regards
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200713/5d1c13a9/attachment.html>