[LLVMdev] Expressing ambiguous points-to info in AliasAnalysis::alias(...) results?

Christian Convey christian.convey at gmail.com
Mon Jun 15 16:22:11 PDT 2015


On Mon, Jun 15, 2015 at 7:14 PM, Daniel Berlin <dberlin at dberlin.org> wrote:

> > Another reason is that in past work, I've sometimes worked on code where
> I'd
> > gladly accept a 10-day compilation time, if it bought me an extra 10% in
> > performance.  So I sometimes wonder what's involved in making such
> > optimization passes available, even though people wouldn't want to use
> them
> > on a day-to-day basis.
>
> FWIW:
> I've explored this before. I built a large-scale distributed
> completely precise context-sensitive alias-analysis and ran it on
> about 100k machines.  It was brute-force and took no shortcuts, etc.
> It was run on some apps that are very large, and took many terabytes
> of memory and disk :)
>
> My result:
> Certainly there are some apps it may buy you 10%.
> But most, it won't, and where it does, there are often cheaper
> techniques (like runtime  tests, etc) that will get you 9%.
>

Wow.  I'll consider my curiosity to have been vicariously satisfied by your
experiment.  Thanks for freeing up six months of my life :)


> Even in a 64 bit world, you will run out of memory quickly. I don't
> think you realize how many edges/variables/etc you are talking about
> for large programs.
> People had cases with structures with thousands of fields,  nested
> these, and instantiate them into tens of thousands of variables.
> It was billions of variables  :)
> Having only-used ranges got it down to tens of millions.
> Now GCC just punts on some sane size.
>

Thanks, I'm going to guess you're right that I'm failing to appreciate the
numbers of things involved.  I appreciate the warning.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150615/1a773f04/attachment.html>


More information about the llvm-dev mailing list