Hi Vladimir,

I have been looking into regression testing for mips16 with LRA enabled 
and tried to understand and solve some ICEs. It was found that in 
a narrowed testcase (attached below) that there are two issues:

1. In the back end - pattern not recognized and hence ICE.
2. In the LRA - a bug that exposes the problem above.

The problem within LRA points to check_rtl function. The function
does not only check for the consistency of the instruction stream, but
unfortunately, it accidentally modifies it as well.

The fragment of the RTL dump before check_rtl():

(insn 18 7 12 2 (set (reg/f:DI 197)                                             
                     
                      (symbol_ref:DI ("a")  <var_decl 0x7fd34f3af558 a>)) 
fpr-moves-7.c:7 280 {*movdi_64bit_mips16}
     (expr_list:REG_EQUIV (symbol_ref:DI ("a")  <var_decl 0x7fd34f3af558 a>)    
                     
        (nil)))                                                                 
                     

After check_rtl(), movdi_64bit_mips16 turns into *lea64:

(insn 18 7 12 2 (parallel [                                                 
            (set (reg/f:DI 197)                                             
                (symbol_ref:DI ("a")  <var_decl 0x7fd34f3af558 a>))         
            (clobber (scratch:DI))                                          
        ]) fpr-moves-7.c:7 258 {*lea64}                                     
     (expr_list:REG_EQUIV (symbol_ref:DI ("a")  <var_decl 0x7fd34f3af558 a>)
        (nil)))                                                             

What happens here is that check_rtl calls insn_invalid_p and insn_invalid_p
tries to add clobber registers in the hope to match a pattern. In our case, 
adding a clobber does match *lea64 and insn_invalid_p generates new 
instruction. The reason for doing this is that reload_in_progress is not being 
set
when LRA is running. Otherwise, insn_invalid_p would be prevented to add 
clobbers.
The problem does not exist if we run it with the classic reload.

One of the solutions I can think of is adding !lra_in_progress to insn_invalid_p
and set this variable before check_rtl() but I am not fully confident that this
is so trivial (I am new to the gcc hacking business). I see a number of reasons
that reload_in_progress is not being used when LRA is used, thus, not entirely
sure if this change would not break anything else. 

Can you suggest how to guarantee check_rtl does not modify the insns?

The back end issue will be looked separately by us.

The testcase compiled with -mips64 -mabi=64 -mips16 -msoft-float with LRA 
enabled:

char a[10];
char foo () {  return a[2]; }

Regards,
Robert Suchanek




Reply via email to