[llvm-dev] Why are GEPs type based?

[Stefanos Baziotis via llvm-dev]

Good to know, thanks for the info.

- Stefanos

On Tue, Jul 14, 2020, 00:35 Nuno Lopes via llvm-dev <llvm-dev at lists.llvm.org>
wrote:

> You are right that it’s mostly a convenience for the front-ends. So they
> don’t have to deal with boring things like padding and sizing things.
>
> Otherwise it adds no semantic value. Object aliasing is not field
> sensitive in LLVM, so it doesn’t matter. Though someone may want to add
> support for that in the future for languages where it’s ok to do so.
>
> FWIW, Alive2’s GEP instruction works over bytes only (pairs of constant *
> %reg). Though I’m not sure I would advocate to change LLVM’s
> representation.
>
>
>
> Nuno
>
>
>
>
>
> *From:* Nikita Popov
> *Sent:* 13 July 2020 21:08
> *To:* llvm-dev <llvm-dev at lists.llvm.org>
> *Subject:* [llvm-dev] Why are GEPs type based?
>
>
>
> 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/20200714/407aa166/attachment.html>