On Tue, Feb 24, 2026 at 08:59:14PM +0100, Robin Dapp wrote: > >> Would it make sense to pull the check into get_equiv_with_elimination(), > >> i.e., let the function look through the subreg and deal with invalid > >> substitutions? Then the check would also apply at another call side in > >> loc_equivalence_change_p() where we also deal with subregs and potential > >> invalid substitutions. > > > > Yep, good idea. One issue I saw before, though, is that it wasn't enough > > to > > just set subst = old (what the check in get_equiv_with_elimination would > > do) > > but I needed to explicitly "continue", otherwise simplify_operand_subreg(?) > > would kick in and still perform a wrong substitution. > > > > One could argue that then simplify_operand_subreg simply needs to be fixed > > as > > well ;) but I was a bit hesitant to change more than what was immediately > > obvious to me. > > > > I'll re-run with your suggestion and report back. > > Looking at it more closely, I think the idea is worthwhile but right now > maybe > too invasive for stage 4? At both call sites I checked we have subreg > handling outside of get_equiv_with_elimination that would also need to be > touched. So my gut feeling is to rather stick with the current approach for > now and rework later.
Yea, giving this a second thought, this doesn't integrate is nicely as I was hoping for. It is less invasive if the validation happens outside of get_equiv_with_elimination since one has to look through the subreg anyway in order to decide whether the substitution is different than the inner reg. I was somehow hoping that if we were dealing directly with subregs, we then could also utilize validate_subreg which tests for more like REG_CAN_CHANGE_MODE_P. Cheers, Stefan
