[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