search for: writeonlyarg

...gt; 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. That makes a lot of sense. > 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. This is unsufficient for our use case. Let me try to explain with an example (also for your later comments)....

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

...tor 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. > > That makes a lot of sense. > >> 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. > > This is unsufficient for our use case. Let me try to explain with an > example (also for...