public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/98470] New: ICE: "error: insn does not satisfy its constraints" with hard FP on xtensa
@ 2020-12-29  5:04 jcmvbkbc at gcc dot gnu.org
  2020-12-29  5:18 ` [Bug target/98470] " jcmvbkbc at gcc dot gnu.org
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: jcmvbkbc at gcc dot gnu.org @ 2020-12-29  5:04 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98470

            Bug ID: 98470
           Summary: ICE: "error: insn does not satisfy its constraints"
                    with hard FP on xtensa
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jcmvbkbc at gcc dot gnu.org
  Target Milestone: ---

Created attachment 49848
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49848&action=edit
float-ice.c

With the following change that enables hardware floating point for the xtensa
target
--->8---
diff --git a/include/xtensa-config.h b/include/xtensa-config.h
index 58d52db0c9b3..6ea55f94dc2a 100644
--- a/include/xtensa-config.h
+++ b/include/xtensa-config.h
@@ -25,7 +25,7 @@
    macros.  */

 #undef XCHAL_HAVE_BE
-#define XCHAL_HAVE_BE                  1
+#define XCHAL_HAVE_BE                  0

 #undef XCHAL_HAVE_DENSITY
 #define XCHAL_HAVE_DENSITY             1
@@ -85,22 +85,22 @@
 #define XCHAL_HAVE_S32C1I              1

 #undef XCHAL_HAVE_BOOLEANS
-#define XCHAL_HAVE_BOOLEANS            0
+#define XCHAL_HAVE_BOOLEANS            1

 #undef XCHAL_HAVE_FP
-#define XCHAL_HAVE_FP                  0
+#define XCHAL_HAVE_FP                  1

 #undef XCHAL_HAVE_FP_DIV
-#define XCHAL_HAVE_FP_DIV              0
+#define XCHAL_HAVE_FP_DIV              1

 #undef XCHAL_HAVE_FP_RECIP
-#define XCHAL_HAVE_FP_RECIP            0
+#define XCHAL_HAVE_FP_RECIP            1

 #undef XCHAL_HAVE_FP_SQRT
-#define XCHAL_HAVE_FP_SQRT             0
+#define XCHAL_HAVE_FP_SQRT             1

 #undef XCHAL_HAVE_FP_RSQRT
-#define XCHAL_HAVE_FP_RSQRT            0
+#define XCHAL_HAVE_FP_RSQRT            1

 #undef XCHAL_HAVE_DFP_accel
 #define XCHAL_HAVE_DFP_accel                   0

--->8---
the following compiler invocation with the attached example:

cc1 -O2 float-ice.c

results in the following ICE:

float-ice.c: In function ‘d’:
float-ice.c:15:1: error: insn does not satisfy its constraints:
   15 | }
      | ^
(insn 538 168 169 32 (set (reg:SF 19 f0 [orig:71 iftmp.0_87 ] [71])
        (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0  S4 A32]))
"float-ice.c":11:17 45 {movsf_internal}
     (nil))
during RTL pass: postreload
float-ice.c:15:1: internal compiler error: in extract_constrain_insn, at
recog.c:2670
0x113e0bd _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
        ../../gcc/gcc/rtl-error.c:108
0x113e11d _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
        ../../gcc/gcc/rtl-error.c:118
0x10ecd55 extract_constrain_insn(rtx_insn*)
        ../../gcc/gcc/recog.c:2670
0x10a1448 reload_cse_simplify_operands
        ../../gcc/gcc/postreload.c:407
0x10a08cd reload_cse_simplify
        ../../gcc/gcc/postreload.c:132
0x10a0ca8 reload_cse_regs_1
        ../../gcc/gcc/postreload.c:238
0x10a06c1 reload_cse_regs
        ../../gcc/gcc/postreload.c:66
0x10a6490 execute
        ../../gcc/gcc/postreload.c:2358

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug target/98470] ICE: "error: insn does not satisfy its constraints" with hard FP on xtensa
  2020-12-29  5:04 [Bug target/98470] New: ICE: "error: insn does not satisfy its constraints" with hard FP on xtensa jcmvbkbc at gcc dot gnu.org
@ 2020-12-29  5:18 ` jcmvbkbc at gcc dot gnu.org
  2020-12-30 12:41 ` rsandifo at gcc dot gnu.org
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: jcmvbkbc at gcc dot gnu.org @ 2020-12-29  5:18 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98470

--- Comment #1 from jcmvbkbc at gcc dot gnu.org ---
It happens at the reload pass when reload transforms the following RTL that
comes to it from the IRA pass:

(insn 20 163 164 30 (set (reg:SF 162 [ iftmp.0_87 ])
        (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0  S4 A32]))
"float-ice.c":11:17 45 {movsf_internal}
     (expr_list:REG_EQUIV (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2])
[0  S4 A32])
        (nil)))
...
(insn 538 168 169 32 (set (reg:SF 71 [ iftmp.0_87 ])
        (reg:SF 162 [ iftmp.0_87 ])) "float-ice.c":11:17 45 {movsf_internal}
     (nil))

to the following RTL:

(insn 538 168 169 32 (set (reg:SF 19 f0 [orig:71 iftmp.0_87 ] [71])
        (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0  S4 A32]))
"float-ice.c":11:17 45 {movsf_internal}
     (nil))

which tries to load a literal into a hardware FP register. There's no opcode
for it in the xtensa ISA, there's no constraint that would match it in the
movsf_internal and the predicate in this instruction definition evaluates to
false on such input, but the substitution happens anyway.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug target/98470] ICE: "error: insn does not satisfy its constraints" with hard FP on xtensa
  2020-12-29  5:04 [Bug target/98470] New: ICE: "error: insn does not satisfy its constraints" with hard FP on xtensa jcmvbkbc at gcc dot gnu.org
  2020-12-29  5:18 ` [Bug target/98470] " jcmvbkbc at gcc dot gnu.org
@ 2020-12-30 12:41 ` rsandifo at gcc dot gnu.org
  2021-01-05  8:13 ` jcmvbkbc at gcc dot gnu.org
  2023-02-26  9:37 ` jcmvbkbc at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2020-12-30 12:41 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98470

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu.org

--- Comment #2 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
What code should GCC generate if it wants to move the given
MEM into an FP register?  The two main options are:

(1) reload the literal address into a temporary register.
    This can be done by using "define_memory_constraint"
    instead of "define_constraint" to define "U".

(2) load into a general-purpose register and then move the
    general-purpose register to an FP register.  This can
    be done using the TARGET_SECONDARY_RELOAD hook.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug target/98470] ICE: "error: insn does not satisfy its constraints" with hard FP on xtensa
  2020-12-29  5:04 [Bug target/98470] New: ICE: "error: insn does not satisfy its constraints" with hard FP on xtensa jcmvbkbc at gcc dot gnu.org
  2020-12-29  5:18 ` [Bug target/98470] " jcmvbkbc at gcc dot gnu.org
  2020-12-30 12:41 ` rsandifo at gcc dot gnu.org
@ 2021-01-05  8:13 ` jcmvbkbc at gcc dot gnu.org
  2023-02-26  9:37 ` jcmvbkbc at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: jcmvbkbc at gcc dot gnu.org @ 2021-01-05  8:13 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98470

--- Comment #3 from jcmvbkbc at gcc dot gnu.org ---
(In reply to rsandifo@gcc.gnu.org from comment #2)
> What code should GCC generate if it wants to move the given
> MEM into an FP register?  The two main options are:
> 
> (1) reload the literal address into a temporary register.
>     This can be done by using "define_memory_constraint"
>     instead of "define_constraint" to define "U".

I've tried that, it doesn't change anything for me. I've also tried doing this
change to the "T" constraint and to both of them. Nothing.

> (2) load into a general-purpose register and then move the
>     general-purpose register to an FP register.  This can
>     be done using the TARGET_SECONDARY_RELOAD hook.

There's already TARGET_SECONDARY_RELOAD hook for xtensa which seems to do
exactly this. But it's not called from the reload and later passes for literal
loads into FPU registers.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug target/98470] ICE: "error: insn does not satisfy its constraints" with hard FP on xtensa
  2020-12-29  5:04 [Bug target/98470] New: ICE: "error: insn does not satisfy its constraints" with hard FP on xtensa jcmvbkbc at gcc dot gnu.org
                   ` (2 preceding siblings ...)
  2021-01-05  8:13 ` jcmvbkbc at gcc dot gnu.org
@ 2023-02-26  9:37 ` jcmvbkbc at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: jcmvbkbc at gcc dot gnu.org @ 2023-02-26  9:37 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98470

--- Comment #4 from jcmvbkbc at gcc dot gnu.org ---
I've noticed that this forward-propagation of the literal load followed by not
calling the secondary reload function happens when the first literal load
instruction has the following in its expression list:

(expr_list:REG_EQUIV (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0  S4
A32])

and it doesn't happen for instructions that have the following:

(expr_list:REG_EQUIV (const_double:SF 0.0 [0x0.0p+0])

This expression is present in this instruction up to the ce2 pass where it's
lost. Compiling with -fno-if-conversion preserves the expression and results in
the correct output.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-02-26  9:37 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-29  5:04 [Bug target/98470] New: ICE: "error: insn does not satisfy its constraints" with hard FP on xtensa jcmvbkbc at gcc dot gnu.org
2020-12-29  5:18 ` [Bug target/98470] " jcmvbkbc at gcc dot gnu.org
2020-12-30 12:41 ` rsandifo at gcc dot gnu.org
2021-01-05  8:13 ` jcmvbkbc at gcc dot gnu.org
2023-02-26  9:37 ` jcmvbkbc at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).