[cfe-dev] [analyzer] Summary IPA thoughts

Artem Dergachev via cfe-dev cfe-dev at lists.llvm.org
Thu Mar 31 10:26:27 PDT 2016

On 31.03.2016 20:20, Gábor Horváth wrote:
>     Yeah, i guess it works pretty much as expected. In the
>     out-of-context analysis, we have two branches for foo(), depending
>     on range constraints for symbol 'reg_$0<x> == reg_$0<y>' - in one
>     branch it's [0, 0], in the other branch it's [1, something like
>     BOOL_MAX]. When calling foo(&a, &a) from bar(), reg_$0<x> gets
>     renamed to &a (as integer), reg_$0<y> gets renamed to &a (as
>     integer) (i don't remember if we still keep the
>     SymbolRegionAddress thing around, because i wanted to replace it
>     with the correct nonloc::LocAsInteger eventually, as it seems more
>     correct; it is more difficult to work with, but imho it is "the"
>     correct actualization), and finally the whole symbol gets renamed
>     to '&a (as integer) != &a (as integer)' and collapses to 0 during
>     evalBinOp, but because range [0, 0] of 0 does not intersect with
>     [1, something like BOOL_MAX], this branch is discarded as
>     unreachable. So when applying summary in-context we have only one
>     branch.
> That is great!
> What I wanted to emphasize here, do we still get only one branch for 
> `if (b == &a) {}`? Because that condition can be decided regardless of 
> the context.

Yeah, sure, the out-of-context analysis for summary construction is, in 
most senses, just your normal analysis; we may just record stuff along 
the way, but not make significantly different decisions. If the 
condition is resolvable without context, it will be resolved without 
context, just like during normal analysis. So the function in your 
example has exactly two branches.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160331/17b46b11/attachment.html>

More information about the cfe-dev mailing list