[llvm-dev] Why are GEPs type based? (original) (raw)

Stefanos Baziotis via llvm-dev llvm-dev at lists.llvm.org
Mon Jul 13 15:39:12 PDT 2020

Good to know, thanks for the info.

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>

More information about the llvm-dev mailing list