> 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-
> I'm regtesting the patch on SH, though currently many C++ tests fail
> on SH with
>
> undefined reference to `std::atomic_thread_fence(std::memory_order)'.
There are no new failures with the patch + reverting
148018 workaround on sh4-unknown-linux-gnu.
Regards,
kaz
Joern Rennecke wrote:
> That's true, and it is by design.
> This use of set_unique_reg_note is a bit debatable - add_reg_note
> should do just fine there.
>
> OTOH keeping this as it is, and keeping set_unique_reg_note accepting USE
> in this case, seems more conservative for stage3.
A tiny chan
Quoting Eric Botcazou :
set_unique_reg note already makes a number of checks so that its
multitude of callers doesn't have to. E.g. it checks that there is
indeed only one set, not only one set of a live register.
Indeed, but not on the DATUM.
P.S.: The DATUM is in the right mode for the co
Quoting Eric Botcazou :
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 exp
> set_unique_reg note already makes a number of checks so that its
> multitude of callers doesn't have to. E.g. it checks that there is
> indeed only one set, not only one set of a live register.
Indeed, but not on the DATUM.
> As you can see in the PR, there are different pieces in the compiler
Quoting Kaz Kojima :
It seems that find_reloads calls set_unique_reg_note for
a USE insn.
That's true, and it is by design.
This use of set_unique_reg_note is a bit debatable - add_reg_note
should do just fine there.
OTOH keeping this as it is, and keeping set_unique_reg_note accepting USE
in
Quoting Eric Botcazou :
This fixes the problem on the Epiphany, but I haven't tested if it also
fixes it on the SH - AAUI you'd have to back out a workaround first to
properly test it.
The fix belongs in the caller instead - it should make sure that what it is
doing makes sense at all.
set_u
> This fixes the problem on the Epiphany, but I haven't tested if it also
> fixes it on the SH - AAUI you'd have to back out a workaround first to
> properly test it.
The fix belongs in the caller instead - it should make sure that what it is
doing makes sense at all.
--
Eric Botcazou
