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

Jordan Rose jordan_rose at apple.com
Fri Jun 20 18:05:19 PDT 2014


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.)

Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140620/a197eca6/attachment.html>


More information about the cfe-dev mailing list