[PATCH] Add a dereferencable attribute

[Hal Finkel]

----- Original Message -----
> From: "Nick Lewycky" <nlewycky at google.com>
> To: reviews+D4449+public+728896e6e6399a87 at reviews.llvm.org
> Cc: "Hal Finkel" <hfinkel at anl.gov>, "Chandler Carruth" <chandlerc at gmail.com>, aschwaighofer at apple.com, "Philip
> Reames" <listmail at philipreames.com>, me+llvm at luqman.ca, "Commit Messages and Patches for LLVM"
> <llvm-commits at cs.uiuc.edu>
> Sent: Thursday, July 10, 2014 3:50:54 AM
> Subject: Re: [PATCH] Add a dereferencable attribute
> 
> 
> 
> 
> On 9 July 2014 20:19, hfinkel at anl.gov < hfinkel at anl.gov > wrote:
> 
> 
> Hi chandlerc, aschwaighofer, nlewycky, reames, luqmana,
> 
> This patch adds a dereferencable attribute. In some sense, this is a
> companion to the nonnull attribute, but specifies that the pointer
> is known to be dereferencable in the same sense as a pointer
> generated by alloca is known to be dereferencable.
> 
> 
> 
> Please don't make it rely on the llvm type like this. We pick llvm
> types to cause ABI decisions in the backend, we may pad them out to
> a multiple of alignment just because we happen to know they're on
> the stack, we do all manner of silliness with llvm types. I do
> understand how Value::isDereferenceablePointer works, but it doesn't
> have to deal with the language splice; that the C++ language (or
> other language) may have a spec that guarantees different bytes are
> dereferenceable than the type would imply. It sees an alloca tied to
> an llvm type and knows it's okay, not just because of the type and
> not just because of the alloca.
> 
> 
> Instead, there is really nifty support for llvm attributes which
> contain values, either as integers or as strings. Please make the
> frontend encode the number of bytes dereferenceable into the
> attribute and make llvm look at that value. Combined with DataLayout
> we may show that it covers the whole llvm type as passed in, but
> even if it doesn't we can analyze offsetting GEPs and such
> individually.

Good point. I'll do that!

 -Hal

> 
> 
> Nick
> 
> 
> 
> 
> My primary use case for this is C++ references that are passes as
> function parameters and used in loops. For example,
> 
> void foo(int * __restrict__ a, int * __restrict__ b, int &c, int n) {
> for (int i = 0; i < n; ++i)
> if (a[i] > 0)
> a[i] = c*b[i];
> }
> 
> Currently, we generate a load of 'c' in every loop iteration because
> we can't prove that there is no control dependence on the
> dereferencability of 'c' from the if condition. But because 'c' is a
> reference, we know it must point to something, and since nothing
> else in the loop can alias it, it is safe to load it in the
> preheader.
> 
> (there is a simple companion Clang patch, which I'll also post.)
> 
> http://reviews.llvm.org/D4449
> 
> Files:
> docs/LangRef.rst
> include/llvm-c/Core.h
> include/llvm/Bitcode/LLVMBitCodes.h
> include/llvm/IR/Argument.h
> include/llvm/IR/Attributes.h
> lib/AsmParser/LLLexer.cpp
> lib/AsmParser/LLParser.cpp
> lib/AsmParser/LLToken.h
> lib/Bitcode/Reader/BitcodeReader.cpp
> lib/Bitcode/Writer/BitcodeWriter.cpp
> lib/IR/Attributes.cpp
> lib/IR/Function.cpp
> lib/IR/Value.cpp
> test/Bitcode/attributes.ll
> test/Transforms/LICM/hoist-deref-load.ll
> 
> 

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