[PATCH] D114988: [IR] `GetElementPtrInst`: per-index `inrange` support

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 2 14:18:33 PST 2021


nikic added a comment.

> I think you are missing the whole point there. It is explicitly NOT the point of this patch
> to be able encode that some index must take values in range of [x, y). So if that is your proposal,
> while it may be interesting, it's explicitly inferior, and does not solve the motivational case.

Right, sorry. I thought you wanted to solve the same issue discussed in the llvm-dev thread, but I see that you're more interested in SROA than AA here. I don't think this materially changes my point though. Rather than restricting the range of an offset, you are instead restricting which offsets of the GEP base can be accessed (either through this GEP, or a later one). That's still something that can be expressed in terms of explicit offsets rather than basing it on struct types. One could argue that this is really a "restrict object" operation that is largely independent from the GEP arithematic and could e.g. be represented as an intrinsic returning a restricted pointer. But I understand that encoding this in the GEP makes this more viable.

> Concretely, can you quote anything that says that in the opaque pointer future,
> the only GEP that will remain will only be able to apply a byte offset to the pointer,
> i.e. there won't be GEP's into structs/multiple indices?

See this thread: https://groups.google.com/g/llvm-dev/c/U7D6z7ZnKy8/m/2-xy5zPcBAAJ Under opaque pointers, we are currently representing constant offset GEPs as i8 GEPs, because this makes things a lot simpler -- with opaque pointers type information tends to not be preserved naturally, and you have to go out of your way, and in some cases use heuristics, to preserve type information. And apart from `inrange`, doing so is entirely wasted effort. For example, SROA will just generate i8 GEPs instead of doing a complicated dance trying to find a minimal natural-looking GEP.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114988/new/

https://reviews.llvm.org/D114988



More information about the llvm-commits mailing list