[llvm-commits] [llvm] r144580 - in /llvm/trunk: include/llvm/Analysis/CaptureTracking.h include/llvm/Analysis/MemoryDependenceAnalysis.h lib/Analysis/CaptureTracking.cpp lib/Analysis/MemoryDependenceAnalysis.cpp test/Transforms/GVN/rle.ll

[Nick Lewycky]

Eli Friedman wrote:
> On Mon, Nov 14, 2011 at 2:49 PM, Nick Lewycky<nicholas at mxc.ca>  wrote:
>> Author: nicholas
>> Date: Mon Nov 14 16:49:42 2011
>> New Revision: 144580
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=144580&view=rev
>> Log:
>> Refactor capture tracking (which already had a couple flags for whether returns
>> and stores capture) to permit the caller to see each capture point and decide
>> whether to continue looking.
>>
>> Use this inside memdep to do an analysis that basicaa won't do. This lets us
>> solve another devirtualization case, fixing PR8908!
>
> This commit appears to be causing a minor compile-time regression at
> -O3 for SingleSource/Benchmarks/Shootout/objinst (on the order of 5%).
>   Please look if you have a moment.

There isn't any obvious misbehaviour, it would take a moderate amount of 
cleverness to invent a way to speed this case up.

In short this is hitting very nearly the case that this patch is 
intended to help with, but then it doesn't quite. Thanks to loop 
unrolling, there's a large block of continuously repeated code with an 
indirect function call that we fail to devirtualize, but the cost for 
doing the scan is moderately expensive as everything from the malloc to 
the free is in one block necessitating a linear scan instead of using 
the domtree.

As for why the devirtualization is failing, it's because this function:

   Toggle *toggle_activate(Toggle *this) {
     this->state = !this->state;
     return(this);
   }

(yes, that's C code not C++) is called, and returning your own argument 
isn't nocapture. GVN would need to be interlaced with an optimization 
that replaced users of toggle_activate's result with users of its argument.

Nick