On 10/20/2021 9:15 AM, Aldy Hernandez wrote:
On Wed, Oct 20, 2021 at 4:35 PM Martin Sebor <mse...@gmail.com> wrote:
I appreciate the heads up. I'm happy that the threader has
improved. I'm obviously not pleased that it has led to regressions
in warnings but I understand that in some cases they might be due
to limitations in the warning code. I think the test case you have
xfailed might be one such example. The uninitialized warnings are
exquisitely sensitive to these types of changes. If/when this patch
is applied please reopen PR 89230 and reference this commit.
Having said that, to maintain the quality of diagnostics,
the work that goes into these nice optimizer improvements needs
to be balanced by an effort to either update the warning code
to cope with the IL changes, or the optimizers need to take care
to avoid exposing undefined code that the warnings are designed
to detect. I'm concerned not just that the quality of GCC 12
diagnostics has been eroding, but also that it seems to be not
just acceptable but expected.
You make a very good point. It is certainly not my intention to make
life difficult for the warning maintainers, but I'm afraid I don't
have sufficient knowledge in the area to improve them.
There may be some low hanging fruit though. At least in the warnings
that use the ranger, there's no reason to run these passes so late in
the pipeline. You could run the warning code as early as you want,
insofar as SSA is available and the CFG has been built. Heck, you may
even be able to run at -O0, though we may need some sort of value
numbering. I believe Richi even suggested this a while back.
Running them later in the pipeline is to take advantage of the
optimizers removing dead and unreachable code as much as possible. In
fact, that's critical to -Wuninitialized. Optimizing away unreachable
paths to avoid Wuninitialized false positives has been the major driver
of jump threading improvements for the last 15 years.
jeff
