[PATCH] D27586: AMDGPU/SI: Add llvm.amdgcn.s.buffer.load intrinsic

Marek Olšák via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 1 11:21:09 PST 2017


mareko added a comment.

In https://reviews.llvm.org/D27586#663420, @tstellarAMD wrote:

> In https://reviews.llvm.org/D27586#663090, @mareko wrote:
>
> > Would you please describe the purpose of this patch? It's not obvious why it's useful.
>
>
> The main reason it is useful is because it tells the compiler that this is a load from a constant value without neededing any more analysis.  It's also useful because s_buffer_load_* instructions have a much more simplified resource descriptor, so if then do end up getting selected to MUBUF you don't have to worry about swizzled addressing.  It is true however, that you could just use a single llvm.amdgcn.buffer.load.i32 intrinsic for everything, but you may end up with worse code if you are unable to do the analysis required to select it to SMRD instructions.


For OpenGL, we'll also need to support non-constant SGPR offsets. And for those, moveToVALU needs to have the corresponding lowering. I don't think having an intrinsic that only accepts constant nodes for the offset is useful.

Also for OpenGL, llvm.amdgcn.buffer.load for SMRD might not be the best choice, because Mesa also needs to determine whether SMRD can be selected with regard to SQC https://reviews.llvm.org/L1 coherency. Therefore, I'd define llvm.amdgcn.s.buffer.load as: "do llvm.amdgcn.buffer.load, but allow SMRD selection for constant and non-constant offsets, and also the referenced memory is immutable (which is why we can use SMRD)". I don't think any other definition is useful for Mesa. Do we agree?

> 
> 
>> What is the behavior of the constant address space in LLVM? Note that vertex buffers and 'restrict' read-only buffers use immutable memory too, so those are also 'constant' and selecting SMEM for those is desirable if it's possible.
> 
> Constant address space just means that the memory is unchanged for the life of the program.

Yes, but what effect on the compiler does it have? Will it allow code sinking and arbitrary scheduling?


https://reviews.llvm.org/D27586





More information about the llvm-commits mailing list