Re: [PATCH] backwards threader: handle SSA names occurring in abnormal PHIs

On 8/13/26 02:40, Richard Biener wrote:
> On Thu, 13 Aug 2026, Aldy Hernandez wrote:
>
>> [Andrew: are you OK with the changes to gimple_range_ssa_names and
>> gimple_range_ssa_p, or would you prefer it to be solved a different
>> way?]
>>
>> [Richi/Jeff, are you OK with this, since you've done work in this area?]
>>
>> The backward threader refuses to look at any SSA name occurring in an
>> abnormal PHI, but DOM's threader does, at least for PHIs where the
>> path taken does not include an abnormal edge.  For example:
>>
>>      x_5(ab) = PHI <45(5), y_8(ab)>
>>      ...
>>      if (x_5 == 45)
>>
>> If we're threading a path coming in from BB5, it's perfectly valid to
>> thread this path, even if x_5 itself is AB.
>>
>> This patch adds the functionality to the path solver, and also enables
>> threading computed gotos whose destination occurs in an abnormal PHI,
>> which happens when the goto block is itself one of the goto's targets.
>>
>> I'm adding an abnormal_ok flag to gimple_range_ssa_p and
>> gimple_range_ssa_names, defaulting to false, so path discovery and the
>> solver track names occurring in abnormal PHIs like any other.
>>
>> The flag lives in gimple_range_ssa_p rather than in a path solver
>> local predicate because operand collection must agree with the
>> predicate: gimple_range_ssa_names walks a statement's operands via the
>> range-op handler and filters them with gimple_range_ssa_p.  A
>> path-local version would have to duplicate all this.  I tried it both
>> ways, and the path solver local predicate was fugly.
> Hmm, there's no reason to not perform analysis on SSA names marked
> as abnormal.  You'd not get any useful control expression for the
> edges, but the copy part holds.  What you have to be careful with
> is not disrupting coalescing during transforms because where
> SSA names on abnormal edges (thus in PHI args) are special is that
> you cannot insert a copy there, so we have to allocate the incoming
> value and the PHI result to the same register.
>
> So I wonder why gimple_range_ssa_p cares about abnormals at all.
>
> What can be problematic is duplicating a PHI where the copy
> inherits an abnormal incoming edge - extra copies of abnormally
> marked SSA names are to be avoided.
>
> So I wonder if you can split this up and remove the abnormal
> restriction from range analysis (and see what breaks - I'm curious).

Sure, I was about to suggest the same thing...  I'm sure it was added 
originally for either excessive safety to get things working or some 
vague historical artifact and never revisited once things stabilized.

It might just work... and if it doesn;t, then we'll have a testcase and 
perhaps there is a better solution

Andrew