[PATCH] D46240: [llvm] Removing writeonly and readnone incompatibility.

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D46240#1083669, @reames wrote:

> In https://reviews.llvm.org/D46240#1083286, @homerdin wrote:
>
> > I am working to enable functions that only write to memory to be hoisted out of loops and to combined by EarlyCSE, more specifically I am working to mark the math functions that only write to errno as writeonly then have them handled as writeonly functions.
>
>
> You'll need something a bit stronger than an aliasing property.  You're going to specifically need to model *what* is written to errno.  At the moment, we don't have a good way to model a function which writes only to one specific global (errno) or to model what those writes are.


I'm not sure that's true. If a function only writes, then what it writes must always be a function only of its arguments. So if I have:

  foo(int, int*) writeonly;
  
  foo(a, b);
  foo(a, b);

then, I think, we can CSE these calls to foo. foo might write to its second argument somewhere, and might write to globals, but since the arguments are the same (and it doesn't read any state otherwise), it must write the same thing each time.

> One thing you could explore is to build in "DSE" for builtin functions.  Once you got a basic design worked out in rough patch form, we could look to see what attributes might make sense to extract.
> 
>> It seems I was mislead by the name readnone, when it is intended as read none and write no visible state.
> 
> readnone is intended to be the intersection of readonly and writeonly.   Naming wise, readnone pre-existed the existence of writeonly.
> 
>> I will abandon this change and look to see why functions are being marked as both writeonly and readnone with my changes when the function writes.

Yea, readnone also means non-writing. I suppose the naming is now a bit unfortunate.

>> Any thoughts on how we can enable the changes I am working towards would be appreciated.
> 
> See above.  I'd start this by working with builtin's via TLI and DSE, then go from there.




https://reviews.llvm.org/D46240