On 12/11/19 2:03 AM, 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.
If this is an important optimization, it would certainly be good to make
it work for C++. And now that constexpr works on the pre-generic form
of the function, it doesn't care how we lower loops. So C++ could
revert to the C way without much trouble. I just find it weird that
apparently the middle end still can't optimize LOOP_EXPR properly.
Jason
