public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug rtl-optimization/95267] New: [ICE][gcse]: in process_insert_insn at gcse.c
@ 2020-05-22  3:04 xuemaosheng at huawei dot com
  2020-05-22  3:31 ` [Bug rtl-optimization/95267] " pinskia at gcc dot gnu.org
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: xuemaosheng at huawei dot com @ 2020-05-22  3:04 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 95267
           Summary: [ICE][gcse]: in process_insert_insn at gcse.c
           Product: gcc
           Version: 7.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: xuemaosheng at huawei dot com
  Target Milestone: ---

In rtl-optimization gcse pass produces a invalid insn, and finally in function 
process_insert_insn reach the code gcc_unreachable ().

static rtx_insn *
process_insert_insn (struct gcse_expr *expr)
{
  ......
  else
    {
      rtx_insn *insn = emit_insn (gen_rtx_SET (reg, exp));

      if (insn_invalid_p (insn, false))
        gcc_unreachable ();
    }

  .....
}

function backtrace is shown as the following:
0xa127cc process_insert_insn
        /gcc/gcse.c:2074
0xa12cce pre_edge_insert
        gcc/gcse.c:2244
0xa137ee pre_gcse
        /gcc/gcse.c:2636
0xa1394f one_pre_gcse_pass
        /gcc/gcse.c:2691
0xa169cd execute_rtl_pre
        /gcc/gcse.c:4097
0xa16a80 execute
        /gcc/gcse.c:4141

the invalid insn produced by gcse pass is shown as the following:
(insn 423 0 0 (set (reg:V8HF16 442 [ userDagc ])
        (unspec:V8HF16 [
                (reg:V8HF16 171 [ _54 ])
                (reg/v:BF8 235 [ boolRsrp ])
                (reg/v:V8HF16 234 [ userDagc ])
            ] UNSPEC_MOVTVFM)) -1
     (nil))

while the original valid insn is shown as the followig:
(insn 261 262 263 30 (set (reg/v:V8HF16 236 [ userDagc ])
        (unspec:V8HF16 [
                (reg:V8HF16 171 [ _54 ])
                (reg/v:BF8 235 [ boolRsrp ])
                (reg/v:V8HF16 236 [ userDagc ])
            ] UNSPEC_MOVTVFM))
"/home2/w00364751/L1Rat/UBBP/src/RatV2/L1Uudp/Srs/nMM/MeasProc/Scheduler/ProcSchedule/src/SRS_UserProc_FDDMM_Private.c":1156
433 {movtv8hf16}
     (expr_list:REG_EQUAL (unspec:V8HF16 [
                (reg:V8HF16 171 [ _54 ])
                (reg/v:BF8 235 [ boolRsrp ])
                (reg/v:V8HF16 234 [ userDagc ])
            ] UNSPEC_MOVTVFM)
        (nil)))

After our analysis, we think that the source of invalid insn is the function
can_assign_to_reg_without_clobbers_p.
function backtrace is shown as the following:
#0  can_assign_to_reg_without_clobbers_p (x=0x7ffff7234460, mode=V8HF16mode) at
/gcc/gcse.c:882
#1  0x0000000000a0fe9e in want_to_gcse_p (x=0x7ffff7234460, mode=V8HF16mode,
max_distance_ptr=0x0) at /gcc/gcse.c:819
#2  0x0000000000a10a71 in hash_scan_set (set=0x7ffff71fe910,
insn=0x7ffff71ff370, table=0x1c39980 <expr_hash_table>)
    at /gcc/gcse.c:1260
#3  0x0000000000a10dbc in hash_scan_insn (insn=0x7ffff71ff370, table=0x1c39980
<expr_hash_table>) at /gcc/gcse.c:1370
#4  0x0000000000a11947 in compute_hash_table_work (table=0x1c39980
<expr_hash_table>) at /gcc/gcse.c:1625
#5  0x0000000000a11a95 in compute_hash_table (table=0x1c39980
<expr_hash_table>) at /gcc/gcse.c:1674
#6  0x0000000000a138de in one_pre_gcse_pass () at 
/gcc/gcse.c:2680
#7  0x0000000000a169ce in execute_rtl_pre () at 
/gcc/gcse.c:4097

the function can_assign_to_reg_without_clobbers_p return true if we can assign
X to a pseudo register of mode MODE such that the resulting insn does not
result in clobbering a hard register as a side-effect.

In our target, the insn is valid since operands[0] is inout reg, this means
that
the insn 262 not only define reg/v:V8HF16 236, but also use reg/v:V8HF16 236.
(insn 261 262 263 30 (set (reg/v:V8HF16 236 [ userDagc ])
        (unspec:V8HF16 [
                (reg:V8HF16 171 [ _54 ])
                (reg/v:BF8 235 [ boolRsrp ])
                (reg/v:V8HF16 236 [ userDagc ])
            ] UNSPEC_MOVTVFM)) 
the REG_EQUAL is
     (expr_list:REG_EQUAL (unspec:V8HF16 [
                (reg:V8HF16 171 [ _54 ])
                (reg/v:BF8 235 [ boolRsrp ])
                (reg/v:V8HF16 234 [ userDagc ])
            ] UNSPEC_MOVTVFM)
        (nil)))

the function can_assign_to_reg_without_clobbers_p use TEST_INSN to judge the
REG_EQUAL is valid or not.
the SET_DEST of TEST_INSN use the regno of FIRST_PSEUDO_REGISTER * 2;
if out target FIRST_PSEUDO_REGISTER is 117, which means that
FIRST_PSEUDO_REGISTER * 2 = 234.
the TEST_ISNN became the following code.
(insn 63 0 0 (set (reg:V8HF16 234)
        (unspec:V8HF16 [
                (reg:V8HF16 171 [ _54 ])
                (reg/v:BF8 235 [ boolRsrp ])
                (reg/v:V8HF16 234 [ userDagc ])
            ] UNSPEC_MOVTVFM)) -1
     (nil))

the insn looks like a valid insn.  However, this is a coincidence,because
FIRST_PSEUDO_REGISTER * 2 = 234, regno 234 is the same as the use reg
reg/v:V8HF16 234, the insn output operands[0],looks like a inout reg.
If  FIRST_PSEUDO_REGISTER is 100 in my target, then the pattern would become
(insn 63 0 0 (set (reg:V8HF16 200)
        (unspec:V8HF16 [
                (reg:V8HF16 171 [ _54 ])
                (reg/v:BF8 235 [ boolRsrp ])
                (reg/v:V8HF16 234 [ userDagc ])
            ] UNSPEC_MOVTVFM)) -1
     (nil))

Then the pattern would be invalid.

bool
can_assign_to_reg_without_clobbers_p (rtx x, machine_mode mode)
{
  ......

  /* Otherwise, check if we can make a valid insn from it.  First initialize
     our test insn if we haven't already.  */
  if (test_insn == 0)
    {
      test_insn
        = make_insn_raw (gen_rtx_SET (gen_rtx_REG (word_mode,
                                                   FIRST_PSEUDO_REGISTER * 2),
                                      const0_rtx));
      SET_NEXT_INSN (test_insn) = SET_PREV_INSN (test_insn) = 0;
      INSN_LOCATION (test_insn) = UNKNOWN_LOCATION;
    }

  /* Now make an insn like the one we would make when GCSE'ing and see if
     valid.  */
  PUT_MODE (SET_DEST (PATTERN (test_insn)), mode);
  SET_SRC (PATTERN (test_insn)) = x;

  icode = recog (PATTERN (test_insn), test_insn, &num_clobbers);

  ......

  return can_assign;
}


So in my opinion, the TEST_INSN use a stable regno FIRST_PSEUDO_REGISTER * 2 in
some case would make some invalid pattern looks like a valid pattern, and
finally will cause internal compiler error.

So can we initialize the SET_DEST every times rather than only initialize once 
And use max_reg_num to replace FIRST_PSEUDO_REGISTER * 2 ?

@@ -851,15 +851,12 @@ can_assign_to_reg_without_clobbers_p (rtx x, machine_mode
mode)

   /* Otherwise, check if we can make a valid insn from it.  First initialize
      our test insn if we haven't already.  */
-  if (test_insn == 0)
-    {
-      test_insn
-       = make_insn_raw (gen_rtx_SET (gen_rtx_REG (word_mode,
-                                                  FIRST_PSEUDO_REGISTER * 2),
-                                     const0_rtx));
-      SET_NEXT_INSN (test_insn) = SET_PREV_INSN (test_insn) = 0;
-      INSN_LOCATION (test_insn) = UNKNOWN_LOCATION;
-    }
+  test_insn = NULL;
+  test_insn
+    = make_insn_raw (gen_rtx_SET (gen_rtx_REG (word_mode, max_reg_num ()),
+                                  const0_rtx));
+  SET_NEXT_INSN (test_insn) = SET_PREV_INSN (test_insn) = 0;
+  INSN_LOCATION (test_insn) = UNKNOWN_LOCATION;

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

* [Bug rtl-optimization/95267] [ICE][gcse]: in process_insert_insn at gcse.c
  2020-05-22  3:04 [Bug rtl-optimization/95267] New: [ICE][gcse]: in process_insert_insn at gcse.c xuemaosheng at huawei dot com
@ 2020-05-22  3:31 ` pinskia at gcc dot gnu.org
  2020-05-22  3:38 ` xuemaosheng at huawei dot com
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2020-05-22  3:31 UTC (permalink / raw)
  To: gcc-bugs

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2020-05-22

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think this is a back-end issue.
Can you provide the definition of movtv8hf16 ?
I don't think you can do:
(set (match_operand 0 predicate constraint)
        (unspec:V8HF16 [
                (match_operand 1 predicate constraint)
                (match_operand 2 predicate constraint)
                (match_dup 0)
            ] UNSPEC_MOVTVFM)))

Rather you need to do:
(set (match_operand 0 predicate constraint)
        (unspec:V8HF16 [
                (match_operand 1 predicate constraint)
                (match_operand 2 predicate constraint)
                (match_operand 3 predicate "0")
            ] UNSPEC_MOVTVFM)))

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

* [Bug rtl-optimization/95267] [ICE][gcse]: in process_insert_insn at gcse.c
  2020-05-22  3:04 [Bug rtl-optimization/95267] New: [ICE][gcse]: in process_insert_insn at gcse.c xuemaosheng at huawei dot com
  2020-05-22  3:31 ` [Bug rtl-optimization/95267] " pinskia at gcc dot gnu.org
@ 2020-05-22  3:38 ` xuemaosheng at huawei dot com
  2020-05-22  4:07 ` pinskia at gcc dot gnu.org
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: xuemaosheng at huawei dot com @ 2020-05-22  3:38 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from otcmaf <xuemaosheng at huawei dot com> ---
(In reply to Andrew Pinski from comment #1)
> I think this is a back-end issue.
> Can you provide the definition of movtv8hf16 ?
> I don't think you can do:
> (set (match_operand 0 predicate constraint)
>         (unspec:V8HF16 [
>                 (match_operand 1 predicate constraint)
>                 (match_operand 2 predicate constraint)
>                 (match_dup 0)
>             ] UNSPEC_MOVTVFM)))
> 
> Rather you need to do:
> (set (match_operand 0 predicate constraint)
>         (unspec:V8HF16 [
>                 (match_operand 1 predicate constraint)
>                 (match_operand 2 predicate constraint)
>                 (match_operand 3 predicate "0")
>             ] UNSPEC_MOVTVFM)))

we use this definition of movtv8hf16:
(define_insn "movtv8hf16"                                                       
  [(set (match_operand:V8HF16 0 "register_operand_s" "+Zrv")                    
        (unspec:V8HF16 [(match_operand:V8HF16 1 "register_operand_s" "Zrv")     
                        (match_operand:BF8 2 "register_operand_s" "Zrb")        
                        (match_dup 0)]UNSPEC_MOVTVFM))]

why we can't use (match_dup 0) ?

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

* [Bug rtl-optimization/95267] [ICE][gcse]: in process_insert_insn at gcse.c
  2020-05-22  3:04 [Bug rtl-optimization/95267] New: [ICE][gcse]: in process_insert_insn at gcse.c xuemaosheng at huawei dot com
  2020-05-22  3:31 ` [Bug rtl-optimization/95267] " pinskia at gcc dot gnu.org
  2020-05-22  3:38 ` xuemaosheng at huawei dot com
@ 2020-05-22  4:07 ` pinskia at gcc dot gnu.org
  2020-05-22  5:03 ` xuemaosheng at huawei dot com
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2020-05-22  4:07 UTC (permalink / raw)
  To: gcc-bugs

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The internals documentation documents this even, read:
https://gcc.gnu.org/onlinedocs/gccint/RTL-Template.html#index-match_005fdup

>From that:
Note that match_dup should not be used to tell the compiler that a particular
register is being used for two operands (example: add that adds one register to
another; the second register is both an input operand and the output operand).
Use a matching constraint (see Simple Constraints) for those.

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

* [Bug rtl-optimization/95267] [ICE][gcse]: in process_insert_insn at gcse.c
  2020-05-22  3:04 [Bug rtl-optimization/95267] New: [ICE][gcse]: in process_insert_insn at gcse.c xuemaosheng at huawei dot com
                   ` (2 preceding siblings ...)
  2020-05-22  4:07 ` pinskia at gcc dot gnu.org
@ 2020-05-22  5:03 ` xuemaosheng at huawei dot com
  2020-05-22  5:24 ` pinskia at gcc dot gnu.org
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: xuemaosheng at huawei dot com @ 2020-05-22  5:03 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from otcmaf <xuemaosheng at huawei dot com> ---
(In reply to Andrew Pinski from comment #3)
> The internals documentation documents this even, read:
> https://gcc.gnu.org/onlinedocs/gccint/RTL-Template.html#index-match_005fdup
> 
> From that:
> Note that match_dup should not be used to tell the compiler that a
> particular register is being used for two operands (example: add that adds
> one register to another; the second register is both an input operand and
> the output operand). Use a matching constraint (see Simple Constraints) for
> those.

However, in gcc/config/aarch64/aarch64-simd.md also has the similar usage。
For example:
1227 (define_insn "aarch64_simd_move_hi_quad_<mode>"                            
1228   [(set (match_operand:VQ 0 "register_operand" "+w,w")                     
1229         (vec_concat:VQ                                                     
1230           (vec_select:<VHALF>                                              
1231                 (match_dup 0)                                              
1232                 (match_operand:VQ 2 "vect_par_cnst_lo_half" ""))           
1233           (match_operand:<VHALF> 1 "register_operand" "w,r")))]            
1234   "TARGET_SIMD && !BYTES_BIG_ENDIAN"                                       
1235   "@                                                                       
1236    ins\\t%0.d[1], %1.d[0]                                                  
1237    ins\\t%0.d[1], %1"                                                      
1238   [(set_attr "type" "neon_ins")]                                           
1239 )     
the operands[0] is a inout reg, and the pattern also use (match_dup 0).

Another case in gcc/config/c6x/c6x.md
 440 (define_insn "*movstricthi_high"                                           
 441   [(set (match_operand:SI 0 "register_operand" "+ab")                      
 442         (ior:SI (and:SI (match_dup 0) (const_int 65535))                   
 443                 (ashift:SI (match_operand:SI 1 "const_int_operand" "IuB")  
 444                            (const_int 16))))]                              
 445   "reload_completed"                                                       
 446   "%|%.\\tmvklh\\t%$\\t%1, %0"                                             
 447   [(set_attr "units" "s")]) 

2930 (define_insn "setup_dsbt"                                                  
2931   [(set (match_operand:SI 0 "pic_register_operand" "+Z")                   
2932         (unspec:SI [(match_dup 0)                                          
2933                     (match_operand:SI 1 "symbolic_operand" "")]            
2934                    UNSPEC_SETUP_DSBT))]                                    
2935   "TARGET_DSBT"                                                            
2936   "%|%.\\tldw\\t%$\\t*+%0($DSBT_index%1), %0"                              
2937   [(set_attr "type" "load")                                                
2938    (set_attr "units" "d_addr")                                             
2939    (set_attr "dest_regfile" "b")                                           
2940    (set_attr "addr_regfile" "b")]) 


Do you mean that those pattern above are also wrong pattern ?
As you say that, that match_dup should not be used to tell the compiler that a
particular register is being used for two operands.
But I still think that the function can_assign_to_reg_without_clobbers_p can do
bettter, use max_reg_num to replace FIRST_PSEUDO_REGISTER * 2 and update
TEST_INSN when calling this function.

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

* [Bug rtl-optimization/95267] [ICE][gcse]: in process_insert_insn at gcse.c
  2020-05-22  3:04 [Bug rtl-optimization/95267] New: [ICE][gcse]: in process_insert_insn at gcse.c xuemaosheng at huawei dot com
                   ` (3 preceding siblings ...)
  2020-05-22  5:03 ` xuemaosheng at huawei dot com
@ 2020-05-22  5:24 ` pinskia at gcc dot gnu.org
  2020-05-22  6:12 ` zhongyunde at tom dot com
  2020-05-22  6:30 ` xuemaosheng at huawei dot com
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2020-05-22  5:24 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to otcmaf from comment #4)
> Do you mean that those pattern above are also wrong pattern ?

YES those are broken.

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

* [Bug rtl-optimization/95267] [ICE][gcse]: in process_insert_insn at gcse.c
  2020-05-22  3:04 [Bug rtl-optimization/95267] New: [ICE][gcse]: in process_insert_insn at gcse.c xuemaosheng at huawei dot com
                   ` (4 preceding siblings ...)
  2020-05-22  5:24 ` pinskia at gcc dot gnu.org
@ 2020-05-22  6:12 ` zhongyunde at tom dot com
  2020-05-22  6:30 ` xuemaosheng at huawei dot com
  6 siblings, 0 replies; 8+ messages in thread
From: zhongyunde at tom dot com @ 2020-05-22  6:12 UTC (permalink / raw)
  To: gcc-bugs

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

zhongyunde at tom dot com <zhongyunde at tom dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zhongyunde at tom dot com

--- Comment #6 from zhongyunde at tom dot com <zhongyunde at tom dot com> ---
*** Bug 95210 has been marked as a duplicate of this bug. ***

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

* [Bug rtl-optimization/95267] [ICE][gcse]: in process_insert_insn at gcse.c
  2020-05-22  3:04 [Bug rtl-optimization/95267] New: [ICE][gcse]: in process_insert_insn at gcse.c xuemaosheng at huawei dot com
                   ` (5 preceding siblings ...)
  2020-05-22  6:12 ` zhongyunde at tom dot com
@ 2020-05-22  6:30 ` xuemaosheng at huawei dot com
  6 siblings, 0 replies; 8+ messages in thread
From: xuemaosheng at huawei dot com @ 2020-05-22  6:30 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #7 from otcmaf <xuemaosheng at huawei dot com> ---
(In reply to Andrew Pinski from comment #5)
> (In reply to otcmaf from comment #4)
> > Do you mean that those pattern above are also wrong pattern ?
> 
> YES those are broken.

Ok, thanks very much.

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

end of thread, other threads:[~2020-05-22  6:30 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-22  3:04 [Bug rtl-optimization/95267] New: [ICE][gcse]: in process_insert_insn at gcse.c xuemaosheng at huawei dot com
2020-05-22  3:31 ` [Bug rtl-optimization/95267] " pinskia at gcc dot gnu.org
2020-05-22  3:38 ` xuemaosheng at huawei dot com
2020-05-22  4:07 ` pinskia at gcc dot gnu.org
2020-05-22  5:03 ` xuemaosheng at huawei dot com
2020-05-22  5:24 ` pinskia at gcc dot gnu.org
2020-05-22  6:12 ` zhongyunde at tom dot com
2020-05-22  6:30 ` xuemaosheng at huawei dot com

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).