[Bug target/77311] bfin: error: unable to find a register to spill in class 'CCREGS'

[law at gcc dot gnu.org]

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 <rguenther@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)