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

Johannes Doerfert via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jul 10 13:23:35 PDT 2019


jdoerfert added a comment.

In D64258#1579146 <https://reviews.llvm.org/D64258#1579146>, @jfb wrote:

> Are there ever cases where you know something is always dereferenceable based on where the memory lives? For example, globals can always be dereferenced, so can the stack (but I don't think the stack exists here). Are there other locations?


Probably, and the Attributor implementation can do deduction of that (also the stack case). However, `dereferenceable_globally` is not available yet (D61652 <https://reviews.llvm.org/D61652>). For now, we cannot distinguish between "globally dereferenceable" and "locally dereferenceable".

> How do you deal with address spaces? Should you only infer this attribute for address space 0?

I do think all address spaces are fine. Must accesses should always imply dereferenceability, afaik, except if they are volatile.

> 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.


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

https://reviews.llvm.org/D64258





More information about the llvm-commits mailing list