https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101641
--- Comment #10 from Segher Boessenkool <segher at gcc dot gnu.org> --- > > > That is, somehow we must anticipate the removal, > > > I suppose it is via > > > > > > /* Recognize all noop sets, these will be killed by followup pass. */ > > > if (insn_code_number < 0 && GET_CODE (pat) == SET && set_noop_p (pat)) > > > insn_code_number = NOOP_MOVE_INSN_CODE, num_clobbers_to_add = 0; > > > > It is not. We must already pass set_noop_p before that insn_code is ever > > set, as you show here. > > Oh, so it's just a compile-time optimization then. The whole NOOP_MOVE_INSN_CODE thing? Yeah, pretty much. It is put in by RTL passes that do not find it convenient to completely obliterate te insn thereand then. > > > where set_noop_p for two MEMs simply dispatches to > > > rtx_equal_p && !side_effects_p. > > > > Yes. Which is completely correct, no? RTL describes what happens in the > > machine, not some layer whatever language drops on top of this, that has to > > be handled in the language frontend. > > Even RTL is more than just "what happens in the machine", Huh? > else we'd not > have MEM_ALIAS_SET or other side-band information usable by optimizers. > So then (*), aka > > if (MEM_P (dst) && MEM_P (src)) > return (rtx_equal_p (dst, src) > && !side_effects_p (dst) > && !side_effects_p (src)); > > is not true since the store represents changing the effective type of DST > with respect to TBAA (that's what all these bugs are about). But none of that is described in the RTL *at all*. There might be something in some to-the-side structure, but nothing is in the RTL, and if the semantics of that to-the-side thing contradict the RTL semantics that is a bug. > One might > argue the bug is in rtx_equal_p but then the "side-effect" of altering > the effective type is part of the insn, not of the SRC or DST by themselves. Nothing like that is part off RTL, nor can it ever be, nor would that be a good idea at all. > Note this is all a bit academic since the testcase is miscompiled in many > places during GIMPLE already. I was just noting that set_noop_p will > eventually trigger the same issue during the combine pass (as you say, > not a fault of combine, but of general infrastructure). It sounds more like wrong expectations even!
