[PATCH] D64258: [InferFuncAttributes] extend 'dereferenceable' attribute based on loads

[JF Bastien via Phabricator via llvm-commits]

jfb added a comment.

>> Also, would it make sense to separate readable from writable? We currently have this bug where LLVM will promote all const static globals to rodata, and sometimes generate atomic cmpxchg to them (e.g. because we're trying to load a 128-bit value). Similarly, we might want to honor R / W memory protection in general. Right now dereferenceable just means "you can load from this", because we can't speculate most stores.
> 
> I do not understand the problem but I have the feeling this is an orthogonal issue.

`mprotect` can make memory readable but not writable, or writable but not readable... or neither. What does `dereferenceable` mean when faced with this fact? Further, what happens to `dereferenceable` when `mprotect` is called (any opaque function could call it)? I don't think this is an orthogonal problem at all.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64258/new/

https://reviews.llvm.org/D64258