> Am 27.02.2026 um 17:30 schrieb Jeffrey Law <[email protected]>:
>
>
>
>> On 2/27/2026 7:47 AM, Richard Biener wrote:
>>> On Fri, Feb 27, 2026 at 3:21 PM Jeffrey Law
>>> <[email protected]> wrote:
>>> This is the first of a few patches to fix pr90036.
>>>
>>> I've gone back and forth about whether or not to fix this for gcc-16 or
>>> queue for gcc-17. Ultimately I don't think these opportunities are that
>>> common, so I don't expect widespread code generation changes.
>>>
>>> I'm going to drop the changes in a small series as the changes stand on
>>> their own. This gives us better bisectability.
>>>
>>> --
>>>
>>> The first patch allows refinement of existing equivalences in a case
>>> where we'd missed it before. In particular say we have <res> = <expr>
>>> in the expression hash table. We later use <expr> in a way that creates
>>> a temporary expression equivalence. We'll fail to record that temporary
>>> expression equivalence because of the pre-existing entry in the hash table.
>>>
>>> And just to be clear, the old equivalence will be restored when we leave
>>> the domwalk scope of the newer, more precise, hash table entry.
>>>
>>> This matters for pr90036 as we initially enter a simple equivalence in
>>> the table with the result being an SSA_NAME. Later we have a
>>> conditional that allows us to refine the result to a constant. And
>>> we're going to need that constant result to trigger additional
>>> simplifications and equivalence discovery.
>>>
>>> Bootstrapped and regression tested on x86_64, aarch64, riscv64 and
>>> probably a couple others as well. It's also been tested across the
>>> embedded targets in my tester. Pushing to the trunk. More to come.
>> I'll note that DOM should go away, so I'm not sure it's great to add
>> sth to it that we cannot do elsewhere?
> This fits into one space where DOM may have long term value -- particular
> context sensitive optimizations. THe next best place I see is FRE, but I
> don't really see how to handle the path specific nature of this stuff in FRE.
There is a simple place where it would fit, but ranger somehow doesn’t simplify
the predicate. I had not integrated the ranger patch to FRE yet because ranger
has no way to use a driving passes SSA value lattice not a way to invalidate
parts of it (the ranger cache gets in the way of an optimistic lattice when
iterating).
But it seems the relations oracle isn’t powerful enough for this simple query.
Richard
>
> Jeff
