The current uses of the "dereferenceable" attribute throughout
LLVM/Clang are not consistent in their interpretation of the semantics.
Clang, and some parts of LLVM, assume the annotated pointer value to be
dereferenceable "now", thus at the program point where the annotation is
(which happens to be the definition of the value).
LLVM optimizations and high-level front-ends tend to interpret the
dereferenceable attribute as a persistent property for the pointer.
Now having different interpretations is obviously problematic .
There has been ample discussion about which definition we should use and
which one should get its very own attribute [1,2]. (That we need both
seems to be unanimously accepted.)
With this patch we limit the meaning of "dereferenceable" to
"dereferenceable at the definition of the value".
For dereferenceability stretching the whole lifetime of a pointer value,
or at least all program points where the SSA value can be accessed, we
Some pros and cons where summarized by @hfinkel .
The most important reason why we should go this way is that this
change is conservatively correct with regards to existing/currently
produced IR. This is especially important because auto-update is not
applicable when we keep the original dereferenceable name around (what
was updated what wasn't?). Again, this will not break front-ends that
produce dereferenceable attributes/metadata, regardless of which (of the
two) interpretations they use. This way forward was also "suggested" by
@rsmith  and @chandlerc . The alternative approach, which was
preferred by people as well ( to highlight only one), gives us
"correct" and "better" optimizations but defines existing IR as broken.
Either way, it is clear that we need to fix something and introduce a