[llvm-dev] RFC: Remove inaccessiblememonly from 3.8 branch

[Mehdi Amini via llvm-dev]

> On Feb 10, 2016, at 1:12 PM, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> A while back, we introduced new attributes to model functions which read and wrote from locations not otherwise visible in the IR.  The motivation was to enable much more aggressive aliasing around such calls.
> 
> Since that time, we've reverted the original patch

inaccessiblememonly is still in trunk as of today right? You're referring to the GlobalsAA one right?

> and AFAIK we have no transformation or analysis passes in tree which use this information.  Given this, I don't think it's really fair to say the attribute has baked at all.  We have no reason to believe that we picked the right semantics, and last I remember, there was some legitimate question about that.  Worse, AFAIK, all active development has stopped.  I don't know of any active reviews for this attribute.
> 
> These attributes have not yet shipped in any LLVM release, but this is about to change in 3.8.  Once that changes, we will have accepted a backwards compatibility guarantee with bitcode which is potentially concerning for a new attribute in such a half developed state.

It seems to me that the attribute can be just dropped safely when reading bitcode without correctness issue right? The consequence would be at worse a missing optimization or could it be worse?

> 
> Given the preceding, I'd like to propose that we remove the inaccessiblememonly and inaccessiblemem_or_argmemonly attributes from the 3.8 release branch.  This could be done by either a) actually removing the code, or b) simply disabling it.  If we remove the documentation from the LangRef, disable the LL and bitcode parsing for the attribute, and explicitly document that we are not reserving the attribute index numbers, I think that prevents any assumption of forward compatibility.  Another option would be to mark them experimental, which would have effectively the same effect.

Given it has never shipped and is not used anywhere (other than reader/parser/writer), I agree with you that there is no reason to ship the attribute for 3.8 and we should remove it.

-- 
Mehdi