On Mon, 2020-01-13 at 13:32 -0500, Jason Merrill wrote: > On 12/12/19 3:44 PM, Jason Merrill wrote: > > On Wed, Dec 11, 2019 at 1:37 PM Jeff Law <l...@redhat.com > > <mailto:l...@redhat.com>> wrote: > > On Wed, 2019-12-11 at 00:03 -0700, Sandra Loosemore wrote: > > > On 12/6/19 3:41 PM, Jeff Law wrote: > > > > On Wed, 2019-11-13 at 09:27 -0700, Sandra Loosemore wrote: > > > > > I bootstrapped and regression-tested this on x86_64-linux- > > > > > gnu. There > > > > > are a few regressions involving these tests: > > > > > > > > > > gcc.dg/tree-ssa/pr77445-2.c > > > > I believe tihs is another instance of the FSA optimization. I'd > > > > need > > > > to see the before/after dumps to know if it's regressed. The main > > > > purpose of the test was to verify that we didn't muck up the > > > > profile > > > > estimation after the FSA optimization. > > > > > > > > > > > > > gcc.dg/tree-ssa/ssa-dce-3.c > > > > So I think this one is supposed to collapse into a trivial infinite > > > > loop. Anything else would be a regression. > > > > > > > > > > > > > gcc.dg/tree-ssa/ssa-dom-thread-7.c > > > > This is the FSA optimization. Unfortunately checking for it being > > > > done > > > > right is exceedingly painful. If you pass along the before/after > > > > dumps > > > > I can probably help determine whether or not we just need an update > > > > to > > > > the scanned bits. > > > > > > > > Given how much pressure there was to handle the FSA optimization, > > > > I'd > > > > prefer to make sure we're still doing it before moving forward. > > > > > > I poked at these 3 test cases some more. FWIW, it appears that if > > > you > > > use an unmodified build to compile them as C++ instead of C, the > > > same > > > problems appear. So I guess it is an existing bug in > > > something-or-another that we are not presently optimizing code output > > > by > > > the C++ front end as well as that from the C front end. :-S (At > > > least, > > > the ssa-dce-3.c optimization failure is a bug; the other two might > > > be > > > fragile test cases.) > > > > > > The C++ front end used to lower loops in exactly the same way as the > > > C > > > front end. This is the patch that changed it: > > > > > > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01994.html > > > > > > There wasn't much discussion about how this affected optimization > > > beyond > > > noting a slight decrease in code size for a single benchmark, and no > > > consideration at all of whether it wouldn't be better to have the C > > > and > > > C++ front ends use the same lowering strategy for loops, whichever > > > way > > > produced better code, so that the optimizers can better recognize > > > the > > > common patterns from both languages. > > > > > > Anyway, I'm no longer expecting to get this front end patch into GCC > > > 10, > > > but it would be helpful to get some guidance on how to proceed for > > > resubmission when stage 1 re-opens. E.g. from where I'm sitting > > > now, > > > fixing the C++ constexpr evaluator to handle gotos (if it doesn't > > > already?) and reverting to the C way of lowering loops seems like a > > > much > > > more bounded problem than fixing optimizers and trying to benchmark > > > their effectiveness. :-S OTOH, somebody more familiar with these > > > optimizations might see easy fixes. Or I could re-jigger my patches > > > to > > > continue to use different loop lowering strategies for C and C++ so > > > it > > > at least wouldn't make things any worse for either language than it > > > already is. > > Well, I'm happy to look at the before/after dumps if you pass them > > along. I'd certainly like to see the two front-ends sharing these > > bits. > > > > Here are the dumps from ssa-dom-thread-7.c made to compile as C++; > > cx-current is the dumps with current trunk; cx-old is changed to use the > > old goto-based lowering like C. > > Have you had a chance to look at these at all? Does it make sense to > check in my patch to revert C++ loop lowering to be like C again? Sorry, I haven't. Too much time prepping Fedora for LTO...
jeff
