[PATCH] Add a dereferencable attribute

[Nick Lewycky]

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140710/b0d83a41/attachment.html>