Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Codegen] Set alignment attributes over vectorized memory accessed #20267

Open
kuhar opened this issue Mar 16, 2025 · 5 comments
Open

[Codegen] Set alignment attributes over vectorized memory accessed #20267

kuhar opened this issue Mar 16, 2025 · 5 comments
Labels
codegen/llvm LLVM code generation compiler backend codegen Shared code generation infrastructure and dialects performance ⚡ Performance/optimization related work across the compiler and runtime

Comments

@kuhar
Copy link
Member

kuhar commented Mar 16, 2025

Hardware like amdgpu generally prefers wide memory accesses (e.g., dwordx4 or b128) but these only get selected by the llvm backend when the alignment is known and sufficiently large. LLVM is able to infer the alignment in some cases, but it's not guaranteed to always do the best job possible.

For example, consider this pseudo-IR:

%lds = memref.alloc() : memref<2x10xf16, #gpu.address_space<workgroup>>>
%x = vector.load %lds[%a, %b] : memref<2x10xf16, #gpu.address_space<workgroup>>>, vector<8xf16>

Ideally, we would like to assume 16-byte alignment (8 * 2 bytes), but this requires knowing:

  1. That the alignment of the allocation itself is at least 16
  2. That memory access pattern guarantees %b to be a multiple of 8

Just because the accessed type is vector<8xf16> is not enough to infer that the alignment is 16.

We can already accomplish 1. with the alignment attribute supported by memref.alloc op, but we have no way of expressing known alignment over memory accesses across memref/vector load/store ops. Similar with inbounds attributes, the most general representation would be per-dimension, but allowing it over 1-d vector types makes things simpler.

I think the following implementation should work:

  • Add alignment attribute to memref/vector memory access ops. To keep it simple, require this to be a single byte value (instead of number of elements) wrt the first element accessed only.
  • Propagate these alignment attributes when converting from memref/vector to llvm/spirv.
  • Flatten the memory accesses in IREE, so that we don't have to worry about any n-d cases.
  • Set known alignment values in IREE codegen, e.g., for shared memory.
@kuhar kuhar added codegen Shared code generation infrastructure and dialects codegen/llvm LLVM code generation compiler backend performance ⚡ Performance/optimization related work across the compiler and runtime labels Mar 16, 2025
@kuhar
Copy link
Member Author

kuhar commented Mar 16, 2025

cc: @krzysz00 @MaheshRavishankar

Feel free to comment / edit if I missed something that we discussed when we talked about it at the end of Feb.

@krzysz00
Copy link
Contributor

Memref flattening is #20226

And I figure that's a reasonable definition of alignment for the base operators, though I claim something like transfer_read might want per-dimension alignments that get lowered to the relevant low-level operations since they've already got the higher-level inbounds

... Might be overkill though

@kuhar
Copy link
Member Author

kuhar commented Mar 20, 2025

I've learned that there's a dedicated op for alignment: https://mlir.llvm.org/docs/Dialects/MemRef/#memrefassume_alignment-memrefassumealignmentop

So there's probably no need to go and add alignment attributes to all the memory access ops?

@krzysz00
Copy link
Contributor

@kuhar That isn't sufficient. That's for declaring the assumed alignment of the base pointer of the memtef. It very much doesn't declare the alignment of individual loads, which can't always be inferred - especially since vector.load and store are often too conservative with their alignment values

@kuhar
Copy link
Member Author

kuhar commented Mar 21, 2025

Well, it depends if you can infer the alignment from the indexing math. But +1 that all this seems fragile.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
codegen/llvm LLVM code generation compiler backend codegen Shared code generation infrastructure and dialects performance ⚡ Performance/optimization related work across the compiler and runtime
Projects
None yet
Development

No branches or pull requests

2 participants