On 5/12/25 5:59 AM, 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.
In my mind I always thought of the PROMOTED_VAR_P as giving the
optimizers and target information that could be used to optimize. If
MIPS relies on it for correctness, then I'd be worried that ext-dce is
mucking things up.
For example, we clear SUBREG_PROMOTED_VAR_P when it appears in a source
operand of a memory store. Though maybe in that case it's not a big
deal. Hmmm.
We also clear SUBREG_PROMOTED_VAR_P if we transform a particular
extension into a subreg access since we can't guarantee promotion state
once that change is mode. Again, if MIPS depends on that info for
correctness, then we may be creating problems, even if they're not
immediately obvious today.
Hence my concern that this pass may simplify not be appropriate for the
MIPS ISA.
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.
It'd be more on the analysis side I'd think. In general when we see a
promoted subreg we consider more bits live than is immediately obvious.
Jeff
