[cfe-dev] Inlining temporary destructor calls...

[Manuel Klimek]

On Mon, Jun 23, 2014 at 6:39 PM, Jordan Rose <jordan_rose at apple.com> wrote:

>
> On Jun 21, 2014, at 2:10 , Manuel Klimek <klimek at google.com> wrote:
>
> On Sat, Jun 21, 2014 at 3:05 AM, Jordan Rose <jordan_rose at apple.com>
> wrote:
>
>>
>> On Jun 20, 2014, at 13:25 , Manuel Klimek <klimek at google.com> wrote:
>>
>> On Fri, Jun 20, 2014 at 7:17 PM, Jordan Rose <jordan_rose at apple.com>
>> wrote:
>>
>>>
>>> On Jun 18, 2014, at 9:08 , Manuel Klimek <klimek at google.com> wrote:
>>>
>>> > Hi Jordan,
>>> >
>>> > I've started to look into inlining temporary destructors, but I'm
>>> hitting a wall.
>>> > Specifically, I think I fail at finding the right MemRegion in
>>> ProcessTemporaryDtor (there is a comment in there, that says we need the
>>> region for the VisitCXXDestructor call).
>>> >
>>> > Any help / pointers / brain-dumps on how to do it would be highly
>>> appreciated.
>>>
>>> Hm. I haven't thought about it enough to give you a fool-proof plan, but
>>> one possibility could be to store the MemRegion in the state at the point
>>> of the CXXBindTemporaryExpr, rather than just a boolean flag. I don't quite
>>> know what the ramifications of that would be, though.
>>>
>>> (By the time we get to the destructor, the value of the
>>> CXXBindTemporaryExpr is almost certainly no longer in the Environment.)
>>>
>>
>> Are there other cases in which we store the MemRegion so we make sure it
>> doesn't get expunged from the Environment, so I can take a look at similar
>> code?
>>
>>
>> It's not a "so it doesn't get purged from the Environment"—it's most
>> likely leaving the Environment no matter what. Instead, you just keep a
>> reference to the MemRegion. CStringChecker does something a bit like this.
>>
>> ...but wait, we need the contents of the region to not be cleaned out of
>> the state either. So maybe there's a better way to go: change the
>> LiveVariables analysis to not consider the CXXBindTemporaryExpr dead until
>> the end of the whole full-expression. (And then do, uh, something about
>> lifetime extension, which isn't quite handled correctly right now anyway.)
>>
>
> How does this currently work for normal variables?
> I expect in:
> {
>   A a;
>   ...
> }
> the MemRegion for 'a' is still available at the end of the block? At
> least, if I look into the handing of all other types of destructors in
> ExprEngine.cpp, it looks like they just unconditionally conjure up the
> MemRegion for the destructed object.
>
>
> That's also handled by LiveVariables. That analysis tracks which
> expressions and which variables are live at a given statement, and then
> those can be used as roots when deciding what regions and symbols are still
> reachable. Checkers can also mark symbols and regions reachable explicitly
> (see the SymbolReaper class). We somehow need to keep the object region
> alive until we can run the destructor.
>
> Since CFGTemporaryDtor knows which CXXBindTemporaryExpr it uses, it might
> be possible to just mark that expression live at that point. It looks like
> we're already doing basically the same thing for local variable
> destructors; see LiveVariablesImpl::runOnBlock.
>

Thanks, that helps a lot.


>
> Also, do you have any tips on how to effectively debug those issues? I'm
> basically trying to dump the state etc, but for temporaries it's quite hard
> to see which part of the state belongs to them (I'll probably need to write
> a patch to make that better? :)
>
>
> Checkers can augment how the state is dumped to include information from
> the GDM (or any information, really). Maybe a new debug checker?
>
> Jordan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140623/319703eb/attachment.html>