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

Reply via email to