<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 9 July 2014 20:19, <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi chandlerc, aschwaighofer, nlewycky, reames, luqmana,<br>
<br>
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.<br>

</blockquote><div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>Nick</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
My primary use case for this is C++ references that are passes as function parameters and used in loops. For example,<br>
<br>
void foo(int * __restrict__ a, int * __restrict__ b, int &c, int n) {<br>
  for (int i = 0; i < n; ++i)<br>
    if (a[i] > 0)<br>
      a[i] = c*b[i];<br>
}<br>
<br>
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.<br>


<br>
(there is a simple companion Clang patch, which I'll also post.)<br>
<br>
<a href="http://reviews.llvm.org/D4449" target="_blank">http://reviews.llvm.org/D4449</a><br>
<br>
Files:<br>
  docs/LangRef.rst<br>
  include/llvm-c/Core.h<br>
  include/llvm/Bitcode/LLVMBitCodes.h<br>
  include/llvm/IR/Argument.h<br>
  include/llvm/IR/Attributes.h<br>
  lib/AsmParser/LLLexer.cpp<br>
  lib/AsmParser/LLParser.cpp<br>
  lib/AsmParser/LLToken.h<br>
  lib/Bitcode/Reader/BitcodeReader.cpp<br>
  lib/Bitcode/Writer/BitcodeWriter.cpp<br>
  lib/IR/Attributes.cpp<br>
  lib/IR/Function.cpp<br>
  lib/IR/Value.cpp<br>
  test/Bitcode/attributes.ll<br>
  test/Transforms/LICM/hoist-deref-load.ll<br>
</blockquote></div><br></div></div>