https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77311
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed| |2022-05-28
CC| |law at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
--- Comment #1 from Jeffrey A. Law <law at gcc dot gnu.org> ---
So my tester tripped over a similar, likely the same, problem starting about a
week ago.
After reviewing the bfin port I think it is fundamentally broken WRT its
handling of condition codes.
Let's say we have these two insns in the stream:
(insn 1711 1710 1717 139 (set (reg:BI 1203)
(ne:BI (reg:SI 977)
(const_int 0 [0]))) "k.c":18:12 130 {movsibi}
(expr_list:REG_DEAD (reg:SI 977)
(nil)))
(insn 1717 1711 1726 139 (set (reg:BI 1204)
(reg:BI 34 CC)) "k.c":19:13 13 {movbi}
(expr_list:REG_DEAD (reg:BI 34 CC)
(nil)))
r1203 is going to need to be allocated to the CC register. But we can
trivially see that the CC register already has a live value in it by way of the
use at insn 1717.
So r1203 is going to have to be assigned to a GPR and LRA/reload will have to
fix things up. Any sequence I can think of to do that will ultimately result
in clobbering CC. But that's not valid because bfin has exposed CC prior to
allocation/reload.
This change from Richi is trigger for the fault I've seen, but I think the real
issue is the bfin port is just plain broken.
commit 68e0063397ba820e71adc220b2da0581dce29ffa (HEAD, refs/bisect/bad)
Author: Richard Biener <rguent...@suse.de>
Date: Mon Apr 11 13:36:53 2022 +0200
Force the selection operand of a GIMPLE COND_EXPR to be a register
This goes away with the selection operand allowed to be a GENERIC
tcc_comparison tree. It keeps those for vectorizer pattern recog,
those are short lived and removing this instance is a bigger task.
The patch doesn't yet remove dead code and functionality, that's
left for a followup. Instead the patch makes sure to produce
valid GIMPLE IL and continue to optimize COND_EXPRs where the
previous IL allowed and the new IL showed regressions in the testsuite.
Here's the new failures just for reference. But I suspect this will likely go
latent as some point given its sensitivity to instruction orderings and
register allocation.
bfin-sim: c-c++-common/torture/pr101636.c -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess
errors)
bfin-sim: c-c++-common/torture/pr101636.c -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess
errors)
bfin-sim: c-c++-common/torture/pr101636.c -O3 -g (test for excess errors)
bfin-sim: c-c++-common/torture/pr101636.c -O3 -g (test for excess errors)
