ICE, insn does not satisfy its constraints

[igrr]

Recently we ran into this issue on a couple of programs, when compiling code which uses floating point at -O2 optimization level:

$ xtensa-esp32-elf-gcc -c test.c  -mlongcalls -O2 -Wall -Werror -Wextra -Wpedantic -fdump-rtl-all
test.c: In function 'd':
test.c:15:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 74 27 19 4 (set (reg:SF 19 f0 [orig:43 iftmp$0_6 ] [43])
        (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0  S4 A32])) "test.c":11 47 {movsf_internal}
     (nil))
during RTL pass: postreload
dump file: test.c.279r.postreload
test.c:15:1: internal compiler error: in extract_constrain_insn, at recog.c:2210

test.c (as minimal as i could c-reduce it):

extern unsigned char a();
extern float b;
extern unsigned char c, h;

void d(signed char unused)
{
  (void) unused;
  const unsigned char e = a();
  for (unsigned char f = c; f; f++) {
    for (unsigned char g = 0; g <= h; g++) {
      b = e ? b : 0;
      d(f);
    }
  }
}

I'm slowly learning my way through the RTL dumps, hoping to find the cause, but wanted to post just in case there is any obvious issue here.

GCC branch I'm using is https://github.com/espressif/gcc/tree/esp_based_on_8_4_0 (a few patches on top of GCC 8.4).

[jcmvbkbc]

Thanks for the report and reproducer. I can reproduce it. Looking at it.

[jcmvbkbc]

AFAICS movsf_internal pattern for xtensa does not have suitable constraints to match loading SF mode constant from a literal pool into an FP register, that's what offending RTL pattern tries to do. I'm not sure how to fix it properly yet. I guess movsf_internal need to be split into patterns with more restrictive predicates that don't allow loading FP registers from memory designated by symbol. Looking into it...

[bhcuong2008]

Hi, is there any update on this? I've also faced this when compiling ulab transform.c:67, movsf_internal, with esp-idf 3.3.5

Thank you.

[kisvegabor]

Facing the same issue with ESP-IDF v5.2.1 when trying to compile ThorVG for ESP32-S3.

[igrr]

@kisvegabor As a workaround, please try adding -fno-if-conversion (espressif/esp-idf#11696 (comment))

[kisvegabor]

I didn't help in my case, however espressif/esp-idf#11696 (comment) suggests that it's any optimization issue. So I added

set_source_files_properties(components/lvgl/src/libts/thorvg/tvgSwImage.cpp PROPERTIES COMPILE_FLAGS "-O0")

but it didn't help either.

However with -O0 optimization in menuconfig it worked. It seems set_source_files_properties has no affect. I've tried with absolute path too.

[igrr]

Most likely you are not using the set_source_files_properties command in the same directory where the library containing the file is defined.

From CMake manual:

By default, source file properties are only visible to targets added in the same directory (CMakeLists.txt).

If you give a pointer to the branch where you have tried using set_source_files_properties, I can suggest a way to fix this.

[kisvegabor]

Most likely you are not using the set_source_files_properties command in the same directory where the library containing the file is defined.

Ah, I didn't know that. Here is my lvgl forg with ThorVG included: https://github.com/kisvegabor/lvgl_upstream/tree/demo/ebike

It's required to add add_compile_options("-Wno-dangling-pointer") due to a ThorVG warning.

[jjsuwa-sys3175]

@igrr
I was interested in this issue, so I tried the above sample in my local environment (based on 10.3, with as many diffs as possible applied from master), but it seems that the problem cannot be reproduced:

[test.c.282r.ira]

(insn 22 446 26 2 (set (reg:SF 167 [ iftmp$0_97 ])
        (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0  S4 A32])) "test.c":11:17 57 {movsf_internal}
     (expr_list:REG_EQUIV (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0  S4 A32])
        (nil)))
...
(insn 516 187 179 36 (set (reg:SF 75 [ iftmp$0_97 ])
        (reg:SF 167 [ iftmp$0_97 ])) "test.c":11:17 57 {movsf_internal}
     (nil))

[test.c.284r.postreload]

(insn 516 187 749 36 (set (reg:SF 10 a10 [orig:75 iftmp$0_97 ] [75])
        (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0  S4 A32])) "test.c":11:17 57 {movsf_internal}
     (nil))

Of course TARGET_HARD_FLOAT was enabled :)

The most impactful change recently is transition from reload to LRA, so IMHO this issue should be resolved with that.

[igrr]

Hi @jjsuwa-sys3175, thanks for testing and letting me know.

The most impactful change recently is transition from reload to LRA, so IMHO this issue should be resolved with that.

Can you please point me to the commit where this change has occurred? I'll try to build ESP toolchain based on that and try to reproduce.

[jjsuwa-sys3175]

@igrr

The most impactful change recently is transition from reload to LRA, so IMHO this issue should be resolved with that.

Can you please point me to the commit where this change has occurred? I'll try to build ESP toolchain based on that and try to reproduce.

24d5e0b
The register allocation logic has been completely revamped before and after this commit.

See also: GCC Wiki - reload GCC Wiki - LRAIsDefault

Q: What is reload?
A: Reload is the GCC equivalent of Satan.

Addendum: It would be better to also apply fb7b829.

[jjsuwa-sys3175]

@jcmvbkbc
A question about something that probably doesn't apply to the esp32, but is technically related:

The ISA refman (Cadence version) describes an instruction (CONST.S instruction) that assigns some immediate constants to HW FP registers, and requires only the "Floating-Point Coprocessor Option" as configuration option, but which HW version is this instruction available from?

If this instruction were available, the above movsf_internal would turn into legitimate and look like this:

(insn 16 7 19 2 (set (reg:SF 19 f0 [45])
        (const_double:SF 0.0 [0x0.0p+0])) "test.c":3:1 62 {movsf_internal}
     (expr_list:REG_EQUIV (const_double:SF 0.0 [0x0.0p+0])
        (nil)))

then, will result in the assembler output const.s f0, 0.

[jcmvbkbc]

which HW version is this instruction available from?

It's associated with the "Floating-Point Coprocessor option" (as opposed to the "Floating-Point 2000 Coprocessor option" which doesn't have it). The distinction between these two options is not really represented in the include/xtensa-config.h, but in the full configuration overlay it is marked by the macros XCHAL_HAVE_DFP, XCHAL_HAVE_DFPU_SINGLE_ONLY or XCHAL_HAVE_DFPU_SINGLE_DOUBLE.

[jameszah]

I have bumped into this with Arduino 1.8.19 using some 1 year old code (board library 2.??), being recompiled with esp32 board library 3.04.

The problem was a function call with 2 x int and 4 x 1-byte parameters -- the code that calls that function gets the "insn does not satisfy constraints"

So far I gave copied the code and dropped the function call to work-around the problem.
Written up over here: https://gist.github.com/jameszah/c8b03712ff9b286541811ac10437a645

Newer Update:

This innocuous piece of code is the problem --- got rid of the float.

      float factor = 2.0;
      if (k == 0 ) {
        factor = 2.0;
      } else if (k == 1) {
        factor = 1.0;
      } else {
        factor = 0.5;
      }