https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101641
--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Segher Boessenkool from comment #10) [...] > > > > 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. It's GCCs middle-end memory model. I'm not sure how without such a thing you can use TBAA to optimize things at all.
