[PATCH] Try to resolve paths in threader without looking further back.

[Jeff Law]

On 10/20/2021 9:15 AM, Aldy Hernandez wrote:
> On Wed, Oct 20, 2021 at 4:35 PM Martin Sebor <msebor@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