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

[Daniel Berlin via llvm-commits]

Unless i'm missing something, this is not the correct handling. Happy to be
convinced.

The normal behavior (and that specified in the papers) is to treat malloc
as if it output the address of a unique variable.

This is because while it introduces no aliases itself, it does introduce a
variable that can be aliased.
If that variable is reached through other mechanisms, it may be an alias :)

If you say they do *nothing*, as you've done here, nothing will ever alias
the result of malloc, even something that *should*.

Am i missing something?


On Sat, May 28, 2016 at 2:32 PM, Jia Chen via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> grievejia created this revision.
> grievejia added reviewers: george.burgess.iv, hfinkel.
> grievejia added a subscriber: llvm-commits.
>
> Cfl-aa used to bail out and make the most conservative assumption on any
> external library functions (any input or output parameter may alias just
> about anything). This patch tries to make it less conservative when seeing
> an external function that allocate/deallocate heap memory, e.g. malloc(),
> calloc(), and free().
>
> http://reviews.llvm.org/D20776
>
> Files:
>   include/llvm/Analysis/CFLAliasAnalysis.h
>   lib/Analysis/CFLAliasAnalysis.cpp
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160530/2f680d34/attachment.html>