Quoting Eric Botcazou <ebotca...@adacore.com>:
This is the bug: you shouldn't call set_unique_reg_note on a DATUM
with a mode
different from that of the destination. This usually means that the logic in
the caller is confused. This is the same interface as emit_move_insn.
No, it isn't. Expanders call other expanders to do fancy stuff. When
everything is done, they tag a REG_EQUAL note on the last insn.
One of the purposes of set_unique_reg_note is lubricate this process:
the layered expanders can add multiple REG_EQUAL notes. We only want
the most high-level note, so we discard the previous one from the
next lower level. Well, we realize now that we only want the most
high-level note that makes sense, actually. We either have to make it
make sense, or abandon adding it.
If every expander has to analyze the instructions that have been issued
to figure out if the new note needs to be modified, or cannot be applied
at all, you end up with umpteen duplications of the checks I added to
set_unique_reg_note prepended to its call sites.
