Re: [2/5] C-SKY port: Backend implementation

[瞿仙淼 <xianmiao_qu@c-sky.com>]

> 在 2018年7月25日，上午5:24，Jeff Law <law@redhat.com> 写道：
> 
> On 07/24/2018 12:18 PM, Sandra Loosemore wrote:
>> On 07/24/2018 09:45 AM, Jeff Law wrote:
>>> On 07/23/2018 10:21 PM, Sandra Loosemore wrote:
>>> I'm not a big fan of more awk code, but I'm not going to object to it :-)
>>> 
>>> Why does the port have its own little pass for condition code
>>> optimization (cse_cc)?  What is it doing that can't be done with our
>>> generic optimizers?
>> 
>> This pass was included in the initial patch set we got from C-SKY, and
>> as it didn't seem to break anything I left it in.  Perhaps C-SKY can
>> provide a testcase that demonstrates why it's still useful in the
>> current version of GCC; otherwise we can remove this from the initial
>> port submission and restore it later if some performance analysis shows
>> it is still worthwhile.
> FWIW it looks like we model CC setting on just a few insns, (add,
> subtract) so I'd be surprised if this little mini pass found much.  I'd
> definitely like to hear from the csky authors here.
> 
> Alternately, you could do add some instrumentation to flag when it
> triggers, take a test or two that does, reduce it and we can then look
> at the key RTL sequences and see what the pass is really doing.
> 

I wrote a case to reproduce this problem on C-SKY. C code is as follows:
-----------------------------------------------------------------------
int e1, e2;

void func (int a, int b, int c, int d, int f, int g)
{
  e1 = a > b ? f : g;
  e2 = a > b ? c : d;

  return;
}
-----------------------------------------------------------------------

compile to assembler with option “-O3 -S” :
-----------------------------------------------------------------------
func:
  cmplt a1, a0
  ld.w  t1, (sp, 0)
  ld.w  t0, (sp, 4)
  movt  t0, t1
  cmplt a1, a0
  movt  a3, a2
  lrw a1, e2
  lrw a2, e1
  st.w  a3, (a1, 0)
  st.w  t0, (a2, 0)
  rts
-----------------------------------------------------------------------
There is an extra “cmplt a1, a0" in the above code without cse_cc. This situation mainly occurs when a relatively short branch jump is converted into a conditional execution instruction. And the CSE pass can not reduce the same conditional comparison instruction . Here is the rtx sequence after “cse2” pass.

-----------------------------------------------------------------------
(insn 28 13 29 2 (set (reg:CC 33 c)
        (gt:CC (reg/v:SI 77 [ a ])
            (reg/v:SI 78 [ b ]))) func.c:5 1099 {*cmpgtsi}
     (nil))
(insn 29 28 30 2 (set (reg/v:SI 82 [ g ])
        (if_then_else:SI (eq (reg:CC 33 c)
                (const_int 0 [0]))
            (reg/v:SI 82 [ g ])
            (reg/v:SI 81 [ f ]))) func.c:5 983 {movf}
     (expr_list:REG_DEAD (reg/v:SI 81 [ f ])
        (expr_list:REG_DEAD (reg:CC 33 c)
            (nil))))
(insn 30 29 31 2 (set (reg:CC 33 c)
        (gt:CC (reg/v:SI 77 [ a ])
            (reg/v:SI 78 [ b ]))) func.c:5 1099 {*cmpgtsi}
     (expr_list:REG_DEAD (reg/v:SI 78 [ b ])
        (expr_list:REG_DEAD (reg/v:SI 77 [ a ])
            (nil))))
(insn 31 30 18 2 (set (reg/v:SI 80 [ d ])
        (if_then_else:SI (eq (reg:CC 33 c)
                (const_int 0 [0]))
            (reg/v:SI 80 [ d ])
            (reg/v:SI 79 [ c ]))) func.c:5 983 {movf}
     (expr_list:REG_DEAD (reg/v:SI 79 [ c ])
        (expr_list:REG_DEAD (reg:CC 33 c)
            (nil))))
-----------------------------------------------------------------------

It doesn't seem to check the same conditional comparison instruction .So I wrote this to solve this problem, but I am not sure if this is the best way : )

PS, the same conditional comparison instruction cannot be reduced with the latest version gcc with C-SKY because I just insert the “cse_cc” after “cse1”, when I insert after “cse2”, this problem can be solved very well.


Thanks,
Xianmiao