[LLVMdev] Optimization hints for "constant" loads

[Andrew Trick]

> On Oct 21, 2014, at 4:03 PM, Philip Reames <listmail at philipreames.com> wrote:
> 
> Sanjoy made a good point.  We don't actually need a new variant of "invariant.start".  Simply using an invariant.start with no uses gives us a notion of an invariant region with no end.  (Since the result doesn't escape, there can be no end hidden inside a function call.)   This seems like a simple notion to exploit and is strict step forward from where we are, without a new intrinsic.

I'm coming back to this because it is a sticking point for me in all of the proposals that were floated informally on the commits list. I would really like this to work, but can't prove that it's safe.

Given:

%a = newArray()
%pLen = gep(%a, <length offset>)
invariant.start(<size>, %pLen)
%len = load %pLen

%o = foo() // may deallocate %a
store %something
load %o

I want to claim that the LLVM optimizer cannot do the following (but don't have a complete line of reasoning yet):

%a = newArray()
%pLen = gep(%a, <length offset>)
invariant.start(<size>, %pLen)
%len = load %pLen

%o = foo() // may deallocate %a
if ptrtoint(%o) == ptrtoint(%pLen)
  load %pLen
  store %something // Oops... this might alias
else
  store %something
  load %o

Either we need to make a convincing argument, or bail on most of the tentative proposals for expressing invariance, and resort to generating IR like this:

%a = newArray()
%pLen = gep(%a, <length offset>)
%t = invariant.start(<size>, %pLen)
%len = load %pLen

%o = foo() // may deallocate %a
invariant.end(%t, <size>, %pLen)
store %something
load %o

...which is pretty painful to implement and may be very difficult to optimize.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141201/baf5fec6/attachment.html>