This is an archive of the discontinued LLVM Phabricator instance.

Inline allocator call when c++-allocator-inlining is specified as true
ClosedPublic

Authored by karthikthecool on Jan 28 2014, 11:24 PM.

Details

Reviewers
jordan_rose
Summary

Hi Jordan,
As suggessted by you i have broken down the patch discussed at http://llvm-reviews.chandlerc.com/D2616.
As our first step in this patch we inline cxx allocator call corresponding to a call to new.
By default this feature is disabled as we still need to model deallocator call.
Analyzer config flag c++-allocator-inlining enables inlining of allocator call when specified as true.
Please let me know if this patch looks good to commit. Thanks alot for your input and time.
Regards
Karthik Bhat

Diff Detail

Event Timeline

This looks good to me, except that I wouldn't bother turning on allocators in NewDelete-custom.cpp until we're using the new-region for construction. (Otherwise we'd get a leak whether or not there actually is one, wouldn't we?) Do you have any opinion on that, though?

lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
340–342

I would move this up before the CallEvent creation, just in case that crashes. We can use the CXXNewExpr's location instead.

karthikthecool updated this revision to Unknown Object (????).Jan 30 2014, 5:18 AM

Hi Jordan,
Yah it seems reasonable to turn off allocator in NewDelete-custom.cpp as it is not implemented completly yet.
Removed changes done in NewDelete-custom.cpp and implemented review comments. Also i'm calling VisitCXXNewAllocatorCall only in case we inline allocators. Once we have completly modelled allocator we can call VisitCXXNewAllocatorCall for all cases.
Please let me know if this looks good.
Thanks for the inputs and time.
Regards
Karthik Bhat

Uh, we should always be evaluating the call even if we can't inline it. In fact, if we are evaluating it, we can probably drop the part of VisitCXXNewExpr that calls invalidateRegions for the allocator, even when inlining is off.

karthikthecool updated this revision to Unknown Object (????).Feb 9 2014, 10:33 PM

Hi Jordan,
As discussed over the mail last week we are not evaluating allocators in all cases just yet as we're not handling the return value correctly in few cases when alpha.cplusplus.NewDeleteLeaks is turned on resulting in false alarms.
Added a TODO and a comment in code as suggested. Please let me know if it is ok for commit?
Thanks for suggessions and inputs.
Regards
Karthik Bhat

jordan_rose accepted this revision.Feb 10 2014, 9:59 AM

Looks good to me! Will commit soon.

lib/StaticAnalyzer/Core/ExprEngine.cpp
559–561

I would rephrase this as "we're not handling the return value correctly, which causes false positives when the alpha.cplusplus.NewDeleteLeaks check is on". The return value isn't ever handled correctly; that's just the easiest way to get it to turn into a bug.

jordan_rose closed this revision.Feb 10 2014, 6:27 PM

Committed in r201122, with the comment change.