[PATCH] Add a dereferencable attribute

[Hal Finkel]

----- Original Message -----
> From: "Philip Reames" <listmail at philipreames.com>
> To: hfinkel at anl.gov, chandlerc at gmail.com, aschwaighofer at apple.com, nlewycky at google.com, me+llvm at luqman.ca,
> listmail at philipreames.com
> Cc: jvoung at chromium.org, jfb at chromium.org, "james molloy" <james.molloy at arm.com>, llvm-commits at cs.uiuc.edu
> Sent: Friday, July 11, 2014 4:27:10 PM
> Subject: Re: [PATCH] Add a dereferencable attribute
> 
> I'm happy with the new encodings.

Good, I like it better too :-)

>  Some of my previous comments still
> stand (naming, comments, etc..), but the overall structure looks
> good.

Alright, I want to be clear about this, because I thought that I had addressed your comments...

 - I will commit separately the AlignAttr -> IntAttr renaming

 - Regarding getDereferenceableBytes -> getBytesKnownSafeToDereference (or similar), I'm not thrilled by the idea of making a long name even longer, and I think that Dereferenceable implies safety. Would getDereferenceableByteCount be better?

 - If there is anything else under "naming", please clarify.

 - There is now some note on every getDereferenceableBytes function stating that zero is returned when the answer is unknown, and the LangRef text has been updated based on your comments.

 - Is there anything else under 'etc.'?

> 
> I am uncomfortable with the coupling of dereferenceable and nonnull.
>  I don't have an actual counter example, but could we separate that
> from the current patch and revisit it separately?

We could, but it would cause a lot of test-case churn (on the Clang side) and I'd rather not. Realistically, the fact that dereferenceablility imples nonnull (only for addrspace(0)) is baked into several pieces of LLVM and specified in the language reference.

Thanks again,
Hal

> 
> Thinking out loud, I wonder about a truly perverse runtime system
> that wanted to use loads from null+offset to represent calls to
> runtime functions.  The signal handler could advance the PC and
> parse the load instruction to "return" a value in the right
> register.  This would be a "dereferenceable" load (very
> indirectly!), but not non-null.  I don't think you could represent
> this in LLVM for other reasons, but it's the best I could do on the
> spot.  :)
> 
> http://reviews.llvm.org/D4449
> 
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory