Just in case I misinterpreted something: I'm waiting for a final LG (or !LG) ...
On Fri, Jun 20, 2014 at 7:02 AM, Manuel Klimek <[email protected]> wrote: > On Fri, Jun 20, 2014 at 5:28 AM, Jordan Rose <[email protected]> > wrote: > >> >> On Jun 19, 2014, at 14:19 , Manuel Klimek <[email protected]> wrote: >> >> On Thu, Jun 19, 2014 at 6:30 PM, Jordan Rose <[email protected]> >> wrote: >> >>> I think the algorithm makes sense. I'm not sure it's different, though, >>> than just passing up the first (or last) CXXBindTemporaryExpr visited for a >>> given expression, which would look like this: >>> >>> // For a logical expression... >>> VisitForTemporaryDtors(E->getLHS(), false, &LastBTE); >>> const CXXBindTemporaryExpr *InnerBTE = nullptr; >>> VisitForTemporaryDtors(E->getRHS(), false, &InnerBTE); >>> InsertTempDtorDecisionBlock(InnerBTE); >>> >>> Are there any cases that wouldn't cover? >>> >> >> Well, the problem is what to do if we don't have a BTE yet; if we only >> wanted to pass one pointer, the semantics on function exit would need to be: >> if (BTE) { we have already found a BTE, no need to insert a new block >> when we encounter the next } >> else { we have not yet found a BTE, so we need to insert a new block when >> we find one } >> >> The "unconditional" branch would only fit with the first part, so we >> would need to somehow conjure non-null BTE for all unconditional entries, >> and then afterwards know that this is a special value, because since we >> didn't add an extra block (as we were running an unconditional case), we >> don't need a decision block. >> I'd say that's a pretty strong argument that we at least need to pass the >> CXXBindTemporaryExpr* and a bool IsConditional. >> >> Now it's right that we don't need to remember the Succ when we hit the >> conditional, and instead we could just always store the Succ when we enter >> a recursive visitation for a conditional branch (we need to store the Succ >> because we can have nested conditionals), but that seems to me like it >> would distribute the logic through even more places, and thus undesirable. >> >> >> My observation is that only certain expressions cause conditional >> branching, and that for these expressions you *always* need to introduce >> a new block if you find any destructors, say, in the RHS of a logical >> expression. So >> >> 1. if you're in a non-conditional sub-expression, it doesn't matter >> whether there are temporaries or not; you don't need to insert a decision >> branch, >> 2. if you're in a conditional sub-expression and there are no >> temporaries, you don't need to insert a decision branch, >> 3. if you're in a conditional sub-expression and there are temporaries, >> you can use any temporary from that subexpression as the guard. >> > > That is exactly the algorithm. > > >> So it looks to me like the only information you have to pass up from >> traversing the sub-expressions is a BTE from that subexpression. Everything >> else can be handled at the point where you start processing that >> subexpression. >> > > We have to pass the information down whether we are in a conditional part, > so we know whether we have to start a new block when we hit the temporary. > > If you're asking why we cannot start the block at the conditional point, > the reason is that we cannot add it before we do the subexpression > traversal (because we don't know yet whether there will be temporaries, and > we don't want to add a block if there are no temporaries), and if we want > to do it after the subexpression traversal, we'd somehow need to split > blocks (as there can be nested conditionals, and multiple temporaries). > > Cheers, > /Manuel > > >> >> What am I missing? >> Jordan >> > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
