[PATCH] D158529: [InferAlignment] Implement InferAlignmentPass

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 22 13:12:26 PDT 2023


nikic added a comment.

In D158529#4607917 <https://reviews.llvm.org/D158529#4607917>, @efriedma wrote:

> Alignment information is most useful in the backend, yes. But it's also relevant for alias analysis and cost modeling, so there could be some impact to delaying the computation.  We might need both an early pass and a late pass.  We might not need to do it every instcombine run, though.

Hm, where does alias analysis use alignment? I don't remember seeing that anywhere.

> Do we want the late run to be after unrolling?

In theory, yes. In practice, computeKnownBits() only looks through phi nodes to a very limited degree, so it doesn't cope with the more complex structure of unrolled code well.

> A pointer-specific computePointerAlign() might be faster to compute than computeKnownBits(); I mean, the basic logic is the same, but the KnownBits datastructure is a lot more complicated than an "int".

That sounds plausible. I think if we're going with a separate pass, we might want to (later) switch to using dataflow analysis to infer alignment, rather than recursive queries. I wouldn't want to reimplement all of KnownBits in that way, but for alignment a lot less instructions are relevant (basically just root instructions + gep/select/phi). That would fix the phi problem while possibly being faster overall. And people have been complaining about that phi limitation (the GPU folks in particular, I think?)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158529



More information about the llvm-commits mailing list