On 9/17/20 8:32 AM, Jason Merrill wrote: > On 9/9/20 8:20 PM, Sandra Loosemore wrote: >> On 9/9/20 3:13 PM, Jason Merrill wrote: >>> >>> My impression from Jeff's analysis in January and David's in March >>> was that many of the testsuite changes were from the C++ approach >>> actually providing better results, so the reversal here surprises >>> me. Can you talk more about the regressions you're seeing? >> >> I spent most of my time earlier in the summer looking at the 3 >> regressions I originally saw last fall. Unfortunately I could get no >> traction at all on the 2 FSA-related ones. :-( For the >> gcc.dg/tree-ssa/ssa-dce-3.c regression, I tracked it down to some >> code in the cddce1 pass being sensitive to the ordering of basic >> blocks in the input code; I filed PR96487 for that. >> >> I was also having a bunch of problems with -Wimplicit-fallthrough >> failures triggered by the C++ front end loop expansion sometimes >> flipping the sense of the end test conditional (through the use of >> fold_build3_loc to build it). It seemed to me that the code that >> handles COND_EXPRs for those warnings is sensitive to the order of >> blocks as well, and has asymmetric assumptions that the code for the >> "if" branch is emitted inline before the "else" branch. I tried some >> experiments with generalizing it to recognize the branches in either >> order, but that did not fix the regressions, so maybe the problem was >> somewhere else entirely, or a combination of two different bugs. :-( >> >> Anyway it seemed to me that the patches would not be accepted if I >> resubmitted them in a form that still caused regressions, and >> switching back to the C way of expanding to GOTO form directly >> instead of via LOOP_EXPR did that. > > We discussed this in a team meeting the other day, and agreed that > it's probably simpler to switch back to gotos for C++ than fix up all > the optimizers. And that there probably isn't much benefit to the > middle-end to retain the higher level representation longer.
Right. I would expect all of Richi's work through the years in loop discovery and canonicalization to eliminate most, if not all, of the benefit of LOOP_EXPR. Ultimately I think we just pick one style and use it in both places. So I'm not going to object to this patch. > The C++ changes are OK. A C maintainer will need to sign off on the > changes there. And Joseph just signed off on the C bits. > > Jason >
pEpkey.asc
Description: application/pgp-keys
