The current uses of the "dereferenceable" attribute throughout
LLVM/Clang are not consistent in their interpretation of the meaningsemantics.
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
introduced "dereferenceable_in_scope" globally".
Some pros and cons where summarized by @hfinkel .
I think theThe 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?). We also doAgain, this will not break front-ends that produce
produce dereferenceable with the same meaning Clang uses.attributes/metadata, This way forward wasregardless of which (of the
also "suggested" by @rsmith  and @chandlerc two) interpretations they use. The alternativeThis way forward was also "suggested" by
approach,@rsmith  and @chandlerc . which was preferred by people as well ( to name one)The alternative approach, giveswhich was
us "correct" and "better" optimizations but breaks with the IR.
Either waypreferred by people as well ( to highlight only one), it is clear that we need to fix something and introduce agives us
new attribute"correct" and "better" optimizations but defines existing IR as broken.
With this patch we try to settle the discussion one way or another:
- If accepted, the changes clarify the dereferenceable definition and
describe the new attribute.
- If rejectedEither way, we will provide a new patch that does it the other wayit is clear that we need to fix something and introduce a