Help with RTL/MD needed

[Jeff Law]

On 7/14/25 10:57 AM, Jan Dubiec via Gcc wrote:
> Recently I have started playing with machine descriptions in the context 
> of PR109324 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109324). I 
> have nodified MDs (see the attached patch) and got following ICE when I 
> tried to build gcc:
> 
> /d/Works/xcomp/gcc-build-stage1/./gcc/xgcc -B/d/Works/xcomp/gcc-build- 
> stage1/./gcc/ -B/usr/local/h8300-elf/bin/ -B/usr/local/h8300-elf/lib/ 
> normal/ -isystem /usr/local/h8300-elf/include -isystem /usr/local/h8300- 
> elf/sys-include --sysroot=/d/Works/xcomp/sysroot   -g -O2 -mn -O2  -g - 
> O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-error=narrowing - 
> Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes - 
> Wold-style-definition  -isystem ./include  -DDF=SF -g -DIN_LIBGCC2 - 
> fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -DDF=SF -I. -I. - 
> I../../.././gcc -I../../../../../gcc/libgcc -I../../../../../gcc/ 
> libgcc/. -I../../../../../gcc/libgcc/../gcc -I../../../../../gcc/ 
> libgcc/../include     -o _powisf2.o -MT _powisf2.o -MD -MP -MF 
> _powisf2.dep -DL_powisf2 -c ../../../../../gcc/libgcc/libgcc2.c - 
> fvisibility=hidden -DHIDE_EXPORTS
> D:/Works/gcc/libgcc/libgcc2.c: In function '__powisf2':
> D:/Works/gcc/libgcc/libgcc2.c:2574:1: error: unrecognizable insn:
>   2574 | }
>        | ^
> (insn 249 113 250 16 (set (reg:CCZ 12 cc)
>          (eq (zero_extract:SI (reg:SI 6 r6 [orig:22 n+-2 ] [22])
>                  (const_int 1 [0x1])
>                  (const_int 0 [0]))
>              (const_int 0 [0]))) "D:/Works/gcc/libgcc/libgcc2.c":2570:10 -1
>       (nil))
> during RTL pass: split2

I don't think modes on the condition operators are handled consistently 
in the H8 port.  In general I think the mode of the EQ operator in this 
context should match the mode of the destination object (CCZ).




> 
> After a short investigation I have found the offending code:
> 
> diff --git a/gcc/config/h8300/testcompare.md b/gcc/config/h8300/ 
> testcompare.md
> index 694c9e60d4e..3b43381e64a 100644
> --- a/gcc/config/h8300/testcompare.md
> +++ b/gcc/config/h8300/testcompare.md
> @@ -28,7 +28,7 @@
>   ;;
>   (define_insn ""
>     [(set (reg:CCZ CC_REG)
> -    (eq (zero_extract:HSI (match_operand:HSI 0 "register_operand" "r")
> +    (eq:CCZ (zero_extract:HSI (match_operand:HSI 0 "register_operand" "r")
>                     (const_int 1)
>                     (match_operand 1 "const_int_operand" "n"))
>           (const_int 0)))]
> 
> Other changes seem to be fine, i.e. I am able to build gcc and the same 
> set of test cases pases/fails as for unmodified compiler.
Your patch looks correct to me.  Given I've seen the H8 be inconsistent 
in this regard before I wouldn't be at all surprised if there are other 
problems of a similar nature lurking.



> 
> MD is a completely new topic to me so I am looking for some hints how to 
> debug the issue. Is it possible that this particular MD is not fully 
> complete?
Debugging failure to match is painful. I sometimes remove all the #line 
markers in the generated insn-recog.cc files and follow the recognizer, 
but that's only when I can't see what's going on with visual inspection 
of the dumps & md file.


> 
> As a side note I can say that unmodified gcc indeed emits "bit test" 
> instruction for line 2570:
> ;# ../../../../../gcc/libgcc/libgcc2.c:2570:       if (n % 2)
> .LM28:
>      btst    #0,r6l    ;#, n
>      beq    .L8        ;#,
Good.  Note that I've got a tester I can throw things into.  I'll do a 
regression test of mh, ms, msx with -mint32.  I can add your patch to 
that tester to see what happens.

Jeff