[PATCH] Exploit dereferenceable_or_null attribute in LICM pass

[Sanjoy Das]

I meant to get to this after your reply, but I somehow forgot.  Sorry for that!

I'd say you should split out the LVI related to changes into a later patch.  That later LVI change should come with test cases that show when it is more powerful than the domtree based approach.  Given our use cases, I suspect LVI won't be necessary.

Other than that, I'm okay with this patch (the domtree part).  There may be some concerns about compile time, but impact on compile time should not affect anyone not generating `dereferenceable_or_null` values.  I don't want to LGTM it at this point only because

  a. I want to have a look at the final version of the patch, without the `getDereferenceableOrNullBytes` accessors or the LVI dependency, before an LGTM
  b. Even after (a), I think we should wait on at least one other review to take a look


================
Comment at: include/llvm/IR/Argument.h:71
@@ -67,1 +70,3 @@
+  /// dereferenceable. Otherwise, zero is returned.
+  uint64_t getDereferenceableOrNullBytes() const;
 
----------------
Given that these are simple getters and are basically extensions of r235132, I think they can go in without further review.  Same applies to changes in `CallSite.h`, `Function.h` and `Instructions.h`.  One way to do this would be to split these out as a separate review (and remove them from this one) and we can independently LGTM that one and check it in.

http://reviews.llvm.org/D9253

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/