[PATCH] D20776: [CFLAA] Teach cfl-aa to understand heap memory allocation

Daniel Berlin via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 1 11:28:02 PDT 2016


On Wed, Jun 1, 2016 at 11:11 AM, Jia Chen <grievejia at gmail.com> wrote:

> On Wed, Jun 1, 2016 at 12:38 PM, Daniel Berlin <dberlin at dberlin.org>
> wrote:
> > Sure, and FWIW, it depends on the definition of unused.
> > GCC's andersen's analysis eliminates variables (ie prior to solving) that
> > are not treated like pointers.
> > That is, if they are not dereferenced, etc, it simply ignores them.  You
> can
> > prove this is correct, and is common (see
> >
> https://www.lib.utexas.edu/etd/d/2009/hardekopfb48332/hardekopfb48332.pdf
> > and http://aria.cs.vt.edu/refs/docs/pldi00.ps for non-pointer
> elimination)
>
> I agree that it is possible. However, the current cfl-aa
> implementation is not doing something that gcc does (it is even less
> precise than Andersen's analysis at this point!).


Unless you use one of the CFL versions of the  inclusion  algorithms (which
i don't believe are amenable to stratified sets), it will always be less
precises.

It just looks at
> instructions, translates them to edges, and add edges to
> StratifiedSets. What bothers me here is why we must explicitly add
> assign edges for things like unused allocas, e.g. malloc() return
> values, and free() argument. In other words, the suspicion is on the
> implementation, not the underlying approach.
>

If you want to rearchitect or rework parts of it, i'm sure george would be
supportive.

Like any other software project, the thing that tends to be the reason
stuff got done the way it is is lack of time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160601/453092d8/attachment.html>


More information about the llvm-commits mailing list