[cfe-dev] Consumed analysis resets its state in between CFG blocks

[Manuel Klimek]

On Mon, May 5, 2014 at 6:49 PM, Jordan Rose <jordan_rose at apple.com> wrote:

> Neither of these are part of the analyzer; they're part of the
> analysis-based warnings in Clang. libClangAnalysis is the common base
> between the two, which is why we have to be careful about the CFG, but the
> full analyzer infrastructure isn't going to be the answer.
>

What would be "full analyzer infrastructure" here? The
REGISTER_MAP_WITH_PROGRAMSTATE
part?


> "A new block may only be started if there is control flow" probably is not
> enforced, but I'm not sure why we wouldn't do that. ("control flow" doesn't
> have to mean a C/C++ notion of control flow; it can be something like the
> static variable DeclStmt that clients of the CFG can use to decide where
> execution goes next.)
>

I'm aware control flow doesn't necessarily mean C/C++ control flow.
Here's my reasons why we might not want to have that invariant.
1. if I remember correctly I have already seen blocks that don't have
terminators that just flow into a single other block (I'll try to fish one
out if you're curious); so I was surprised to see other places basically
assert in a comment that this is an assumed invariant
2. it seems that sometimes having the CFG be more uniform regarding
different related patterns might be nice (although I see that it is a very
very weak argument)
3. it might just be too hard to assert the invariant, in which case I'd say
it's better to explicitly say it's *not* an invariant than to let checks or
cfg-based compiler checks rely on it

Thoughts?
/Manuel


>
> Jordan
>
>
> On May 5, 2014, at 5:51 , Manuel Klimek <klimek at google.com> wrote:
>
> Btw, I see a similar problem with the ReachableCode analysis:
> lib/Analysis/ReachableCode.cpp:61 static bool isDeadReturn(...)
> seems to rely on the invariant:
> "A new block may only be started if there is control flow"
> Is the analyzer actually trying to enforce this invariant?
>
> Thanks!
> /Manuel
>
>
>
>
> On Sat, May 3, 2014 at 5:38 PM, Manuel Klimek <klimek at google.com> wrote:
>
>> Heya,
>>
>> I am currently playing around with how the CFG looks in the face of
>> temporary destructors; one interesting tidbit is that temporary destructors
>> insert CFG blocks in places where one might not have expected them - for
>> example, before the call to an arbitrary destructor at the end of a full
>> expression.
>>
>> Now the consumed analysis kills it state unconditionally at the end of
>> each block:
>>
>> http://reviews.llvm.org/diffusion/L/browse/cfe/trunk/lib/Analysis/Consumed.cpp;207914$1400
>> This leads to missed warnings when we leave a CFG block in the middle of
>> an expression, and in general feels very brittle regarding future changes
>> to the CFG's layout.
>>
>> I was wondering whether there are already mechanisms in the CFG to deal
>> with issues like this (I'd have expected a consumed analysis to work on the
>> scope of a variable instead of arbitrary block boundaries - for example,
>> could we use REGISTER_MAP_WITH_PROGRAMSTATE?).
>>
>> Thoughts?
>> /Manuel
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140505/567317df/attachment.html>