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.
