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?
Jason
