On Mon, 2025-05-12 at 12:59 +0100, Richard Sandiford wrote: > Xi Ruoyao <xry...@xry111.site> writes: > > The tranform would be unsafe if !TRULY_NOOP_TRUNCATION because on these > > machines the hardware may look at bits outside of the given mode. > > > > gcc/ChangeLog: > > > > PR rtl-optimization/120050 > > * ext-dce.cc (ext_dce_try_optimize_insn): Only transform the > > insn if TRULY_NOOP_TRUNCATION. > > Yeah, it's not obvious to me what the right fix is here. When I > responded to the PR, I was really only responding to the comment about > using mode_rep_extended. Now that I've read the rest of the PR trail, > I agree with you that the /u (unsigned promotion) in insn 440 looks > really suspicious. I don't see how MIPS can escape using a truncate for > that instruction. So it does seem that the code is potentially wrong > coming into ext-dce. > > But then the question is whether ext-dce could still misbehave when > the incoming code is correct. Certainly it mustn't remove/invalidate > SUBREG_PROMOTED_VAR_P for signed promotions from SI to DI, since MIPS > relies on those (for correctness) to avoid truncations. > > But then the question is where the TRULY_NOOP_TRUNCATION test should go. > The subreg in ext_dce_try_optimize_insn isn't itself problematic, since it's > creating an extension via a paradoxical subreg. So I wonder if the check > should instead be in the analysis phase, aimed at identifying insn 440.
Oops. I guess I misread the code then. > Specifically, if we see an rhs (subreg/s[/u]:M1 (...:M2)) (/s for > SUBREG_PROMOTED_VAR_P) and TRULY_NOOP_TRUNCATION says that the > truncation is not a noop, then all bits of M2 are significant/live. > We cannot reduce the live mask to that of M1. Will try that in the next version. > I'm also not sure off-hand what the consequences of the TRUNCATE handling > in safe_for_live_propagation would be for !TRULY_NOOP_TRUNCATION. > At first it seemed wrong, but now I think it's proably ok. I suppose > the truncation never goes away, and the whole point of MIPS truncations > is that they make no assumption about the upper bits of the incoming DI > register, so there's also no rule against changing those bits. -- Xi Ruoyao <xry...@xry111.site> School of Aerospace Science and Technology, Xidian University
