[llvm-dev] New intrinsic property IntrOnlyWrite

[Philip Reames via llvm-dev]

I'm generally in support of this change.  I haven't looked at the patch 
yet, but the direction seems worthwhile.

Note that we already have a writeonly predicate in a few places in the 
code (BasicAA being one).  If we do introduce the new intrinsic 
property, we should refactor all of these places to use the new 
mechanism.  This could be separate changes, but should be considered 
required as part of adding the new property.

Another way you might consider slicing the problem is to introduce a 
WriteOnlyArg property.  When combined with ArgMemOnly, this would more 
precisely model the pseudo store (right?) and is a better fit for the 
memset/memcpy use case already handled in BasicAA.

Philip

p.s. Inline comments below specific to your use case.

On 03/18/2016 08:16 PM, Nicolai Hähnle via llvm-dev wrote:
> Hi,
>
> I'd like to draw your attention to http://reviews.llvm.org/D18291, in 
> which I propose a new intrinsic property for intrinsics that are 
> lowered to instructions that mayStore, but are neither mayLoad nor 
> hasSideEffects.
>
> This is relevant for AMDGPU, where we have store instructions that 
> don't operate on pointers. The codegen backend understands these 
> perfectly well as stores, and so we can enable better scheduling 
> decisions than if we forced these instruction to hasSideEffects.
Can you give a bit more detail here?  Example, etc..?
>
> In a perfect world, we'd be able to model the behavior of these load 
> and store intrinsics via ReadWriteArgMem, but that would require 
> massive changes in how LLVM thinks about memory locations and how to 
> describe them.
This comments makes me think you might have a much deeper problem. Let's 
see an actual example first though; I might just be misreading your intent.
>
> This comparatively minor addition allows us to move forward with 
> decent scheduling in codegen for the time being.
>
> Cheers,
> Nicolai
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev