[PATCH] D13973: CFG: Delay creating Dtors for CompoundStmts which end in ReturnStmt
Matthias Gehre via cfe-commits
cfe-commits at lists.llvm.org
Mon Nov 2 13:32:56 PST 2015
mgehre added a comment.
Basically, there are the following cases:
A)
void f() {
S s;
}
Everything OK, only one (reachable) destructor is generated
B)
int f() {
S s;
return 1;
}
In current trunk, this first generates dtor in a block when visiting the CompoundStmt,
and then abandons that block when visiting the ReturnStmt. Thus we have one unreachable block just containing the dtor.
C)
int f() {
S s;
return 1;
int i = 1;
}
Like B), but the unreachable block also contains "int i = 1".
D)
int f(bool b) {
S s;
if(b)
return 1;
else
return 17;
}
Like B), but not fixed by this patch.
E)
Any combination of B) or D) with "throw" or a noreturn function instead of "return". Not fixed by the current patch.
I think that case B) is a common thing, and thus it's handled by this patch. Handling case B) with a 'throw' instead of 'return'
should be easy enough, too.
C) is a bit unusual due to the unreachable statement, thus I think that we should not optimize for that corner case.
D) more usual, but not easy to fix.
I currently see the following ways forward:
1. Extend this patch to cover also "throw", fixing case B)
2. Do 1) plus loop over the whole body to also fix case C)
3. Drop this patch and instead remove unreachable blocks after the whole CFG has been generated (by mark-and-sweep), fixing B), C) and D)
The following comment at the beginning of VisitReturnStmt() indicates that this was planned
// NOTE: If a "return" appears in the middle of a block, this means that the
// code afterwards is DEAD (unreachable). We still keep a basic block
// for that code; a simple "mark-and-sweep" from the entry block will be
// able to report such dead blocks.
I'm not sure if that is actually done.
http://reviews.llvm.org/D13973
More information about the cfe-commits
mailing list