[cfe-dev] [analyzer] Summary IPA thoughts

[Artem Dergachev via cfe-dev]

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>