[PATCH] D26725: AMDGPU: Add llvm.amdgcn.interp.mov intrinsic

[Marek Olšák via llvm-commits]

mareko added inline comments.


================
Comment at: include/llvm/IR/IntrinsicsAMDGPU.td:481
+            [llvm_i32_ty, llvm_i32_ty, llvm_i32_ty, llvm_i32_ty],
+            [IntrNoMem]>;
+
----------------
arsenm wrote:
> mareko wrote:
> > nhaehnle wrote:
> > > arsenm wrote:
> > > > nhaehnle wrote:
> > > > > tstellarAMD wrote:
> > > > > > arsenm wrote:
> > > > > > > Shouldn't this be IntrReadMem? The doc says it reads parameters in LDS
> > > > > > I think technically, this should be inaccessiblememonly,  because but there is no intrinsic attribute for this yet.
> > > > > And that region of LDS is constant anyway, so IntrNoMem is fine.
> > > > Is that possible? I thought the runtime couldn't ever initialize LDS, so something in the shader has to set it in the first place
> > > The LDS for these instructions is initialized by Primitive Assembly (or possibly the Scan Converter, it's unclear to me where the boundary between those hardware blocks is precisely).
> > LDS is initialized by the SPI block before the pixel shader. ReadNone is fine, because nothing can modify it.
> I don't think it can really prevent writes? I'm betting an out of bounds access will clobber it. BTW D26485 adds the property 
I think you'd have to modify m0 to before writing to it, which can't be done from LLVM IR. Anyway, the same could be said about any other memory. We want v_interp to be 100% movable without restrictions. We want the same for the vast majority of loads and also most stores, because stores with side effects are very rare in graphics, and are usually limited to LDS in compute shaders. I've seen plenty of buffer and image stores used by games, but I've yet to see those with any side effects.


https://reviews.llvm.org/D26725