[LLVMdev] GSoC - Range Analysis

[John Criswell]

On 3/29/12 3:59 PM, Victor Campos wrote:
> Dear LLVMers,
>
>    I have been working on Douglas's range analysis, and today, after
> toiling with it for two years, we have a very mature and robust
> implementation, which is publicly available at
> http://code.google.com/p/range-analysis/. We can, at this point,
> perform range analysis on very large benchmarks in a few seconds. To
> give you an idea, we take less than 10 seconds to globally analyze
> SPEC 2006 gcc benchmark with function inlining enabled. And the
> analysis is fairly precise. We have a gallery of examples at
> http://code.google.com/p/range-analysis/wiki/gallery that will give
> you an idea of what kind of information we can find. Our analysis
> comes together with a dynamic profiler that points the minimum and
> maximum values that each variable assumes during program execution
> too. And it uses a live range splitting strategy to obtain data-flow
> sparsity that is lightning fast. It is more than 100x faster than the
> original implementation of SSI in LLVM 2.7, for instance. There are a
> number of LLVMers, outside my university, that use our analysis.

What version of LLVM does your analysis use currently?

It sounds like your analysis is fast.  Can you show results on how fast 
it is on various programs?  Do you have measurements on how much memory 
it uses?  How large is the largest program you've compiled with it?

>    So, I would like to propose a summer of code that consists in (i)
> integrating our infra-structure in the LLVM main tree, and (ii)
> writing a dead-code elimination pass that uses the analysis as a
> client. So far people have been using our analysis to check for buffer
> overflows, and to eliminate array bound checks.

If possible, I think you should first implement the dead-code 
elimination optimization that uses your analysis to show how much of a 
performance win your analysis provides for LLVM.  If the optimization is 
sufficiently fast and provides enough of a speedup, then it can be 
integrated into LLVM (because you will have proof that it is a 
performance win; that will help convince current developers with commit 
access to review your code for inclusion).

We in the SAFECode project would be interested in trying your analysis 
out for eliminating bounds checks.  We just haven't had the time to do 
that yet (I'm assuming you're the same person that wanted to do Value 
Range analysis last year).

> Yet, I think there is
> a lot of potential to optimizations. Dead code elimination at branches
> would be one such optimization. Given that the analysis is pretty
> mature, I think that it would not be too difficult to integrate it in
> the current infra-structure that LLVM offers, e.g., Lazy Values. As
> for dead-code, we already can flag variables that have impossible
> intervals, in which the lower bound is larger than the upper bound.
> So, it is only a matter of adapting it to remove this code.


Regarding a dead-code elimination algorithm, I can see something like an 
Aggressive Dead Code Elimination pass using your analysis to prove that 
certain branches are never taken.  One thing you could do would be to 
write a pass that looks for icmp instructions and uses your analysis to 
change them to true/false when possible.  SCCP, ADCE, and other 
optimizations would then take care of the rest.

The idea of integrating your pass as a lazy value pass sounds good.  The 
question I have is what optimizations benefit from LazyInfo?  I only see 
one or two transforms that use it in LLVM 3.0.

>
> I would like to hear from you what you think about this Summer of Code
> project. If you think it could be interesting, I will write a proposal
> richer in details.

My interest in range analysis is for using it with SAFECode, but if it 
can be used for standard compiler optimization and gets integrated into 
LLVM, all the better for me.

-- John T.
>
> Sincerely yours,
>
> Victor
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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