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

[Jeff Law <jeffreyalaw@gmail.com>]

On 10/21/2021 1:17 AM, Aldy Hernandez wrote:
> On Wed, Oct 20, 2021 at 10:01 PM Jeff Law <jeffreyalaw@gmail.com> wrote:
>>
>>
>> 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.
> Ughh, that's unfortunate.  We're gonna have to come up with
> improvements to the Wuninitialized code, or a different paradigm
> altogether.  I'm afraid this will only get worse.
Well, good luck with a different paradigm :-)  It's a tough little nut.  
As long as we want to reduce false positives, then we're going to be 
dependent on optimization and related analysis.

And as I've noted before, we're generally better off fixing the 
optimizers when we stumble over a false positive from Wuninitialized.  
When that's not possible, we should look to fix the predicate analysis 
code.

>
> It is a bit ironic that jump threading helps reduce Wuninitialized
> false positives, but yet too much of it causes even more false
> positives.
I would expect the latter to be relatively rare for Wuninitialized. I 
think some of the other middle end warnings may be in a different boat 
though.



jeff