On 12/11/19 11:27 AM, Jason Merrill wrote:
On 12/11/19 2:03 AM, Sandra Loosemore wrote:
[snip]
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.
Thanks for confirming my suspicion that it ought to "just work" to do
that. Unless we're concerned about papering over optimizer bugs, this
would be an easy fix.
I just find it weird that
apparently the middle end still can't optimize LOOP_EXPR properly.
Yeah, this seems weird to me too; you'd think it would all be the same
once it gets converted to a control flow graph, and it would not matter
whether the end test is located at the top or bottom of the loop, etc.
-Sandra