[committed] Fix pr20601-1.c on the H8

[committed] Fix pr20601-1.c on the H8

[Jeff Law]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]


This is a codegen fix for the H8 that I debugged while working on the cc0
conversion.  In simplest terms we're accepting things like (const_int 0) as the
source of a zero_extract and it ultimately interacts badly with register
reloading.

One might argue this is combine's fault for not simplifying the extraction, but
it's really wrong for the pattern to accept something that we simply can't handle
correctly, ever.  THere isn't a great predicate for this, so we just reject the
constants in the condition.

Pushed to the trunk, without having to commit a ChangeLog entry! :-)

Jeff

[-- Attachment #2: P --]
[-- Type: text/plain, Size: 940 bytes --]

commit bc48456d085d4ab8be92cf5369624dd86317cecb
Author: Jeff Law <law@redhat.com>
Date:   Tue May 26 22:14:40 2020 -0600

    Fix pr20601-1.c on the H8
    
    gcc/
            * config/h8300/testcompare.md (tst_extzv_1_n): Do not accept constants
            for the primary input operand.
            (tstsi_variable_bit_qi): Similarly.

diff --git a/gcc/config/h8300/testcompare.md b/gcc/config/h8300/testcompare.md
index 2e4cb5afee7..118db145a8a 100644
--- a/gcc/config/h8300/testcompare.md
+++ b/gcc/config/h8300/testcompare.md
@@ -9,7 +9,7 @@
 				  (match_operand 1 "const_int_operand" "n,n,n"))
 		 (const_int 0)))
    (clobber (match_scratch:QI 2 "=X,X,&r"))]
-  ""
+  "!CONSTANT_P (operands[0])"
   "@
    btst\\t%Z1,%Y0
    btst\\t%Z1,%Y0
@@ -82,7 +82,7 @@
 					  (const_int 7)))
 		 (const_int 0)))
    (clobber (match_scratch:QI 2 "=X,X,&r"))]
-  ""
+  "!CONSTANT_P (operands[0])"
   "@
    btst\\t%w1,%X0
    btst\\t%w1,%X0