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
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.renne...@embecosm.com joern.renne...@embecosm.com wrote:
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.
Bootstrapped powerpc64-unknown-linux-gnu.
With the patch +
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
Quoting Eric Botcazou ebotca...@adacore.com:
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
Quoting Kaz Kojima kkoj...@rr.iij4u.or.jp:
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 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 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.
Quoting Eric Botcazou ebotca...@adacore.com:
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
Joern Rennecke joern.renne...@embecosm.com 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
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.
Bootstrapped powerpc64-unknown-linux-gnu.
pr40154-fix
Description: Binary data
11 matches
Mail list logo
