Re: [PATCH 0/2] Make C front end share the C++ tree representation of loops and switches

[Jeff Law <law at redhat dot com>]

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 <law@redhat.com 
> > <mailto:law@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