On 2/24/25 9:43 AM, Michael Matz wrote:
It depends, but even if that were no problem in some specific cases
(perhaps by ensuring that such sequence isn't intermingled with insns that
are in different EH regions) that doesn't seem to be what the proposal is
doing? From the description it moves a EH note from a load (where it
presumably was for a reason) that occurs after a store to something that
so happens to be the (new) last instruction of a bb. Because otherwise
the load couldn't be moved earlier into the middle of a BB. In essence
the load would lose the EH note and a new EH note would be generated for a
different insn out of thin air. I don't see how that can ever be a
correct transformation in general. What _if_ the very load traps then?
What if the new insn cannot trap?
(Note that loads and stores may trap differently even on the same address,
e.g. write to read-only mem, or an misaligned load but an aligned (or
smaller-sized) write; though I'll say that GCC assumes that loads cannot
trap if shadowed by an equivalent write, in some other passes)
Good points. The alignment case was just starting to rattle around in
my head. It may simply be the case we can't do much here.
jeff
