Help w/ CFG/loop optimization problem?

Dale Johannesen dalej@apple.com
Wed Sep 11 13:15:00 GMT 2002


On Wednesday, September 11, 2002, at 12:57 PM, Jeff Law wrote:

> In message <A21CD16A-C4F8-11D6-93B1-003065C86F94@apple.com>, Dale 
> Johannesen wr
> ites:
>> I've run into an optimization problem with
>>
>>     if (count > 10)
>>         for (i = 0; i < count; ++i)
>>             pcb += i;
>>     else...
> It'd really help to have a compilable example.

Here you go.  On ppc/darwin, the second loop is recognized
as a doloop, the first is not.  Sorry to have oversimplified.
(I'm looking at this myself along the lines suggested by
Jan Hubicka, BTW.)

void foo (int count, char* pca, char* pcb) {
     int i;
     if (count > 10)
         for (i = 0; i < count; ++i)
             pcb += i;
     else
         for (i = 0; i < count; ++i)
             pca += i;
     *pca = *pcb;
}

>> RTL before cfg:
>> (note 27 25 28 NOTE_INSN_LOOP_CONT)
>>
>> (code_label 28 27 74 3 5 "" [0 uses])
>>
>> (note 74 28 29 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
>>
>> (insn 29 74 17 3 0x0 (set (reg/v:SI 121)
>>         (plus:SI (reg/v:SI 121)
>>             (const_int 1 [0x1]))) -1 (nil)
>>     (nil))
>>
>> (code_label 17 29 75 4 3 "" [1 uses])
>>
>> (note 75 17 18 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
>>
>> (insn 18 75 19 4 0x0 (set (reg:CC 123)
>>         (compare:CC (reg/v:SI 121)
>>             (reg/v:SI 118))) -1 (nil)
>>     (nil))
>>
>> (jump_insn 19 18 76 4 0x0 (set (pc)
>>         (if_then_else (lt (reg:CC 123)
>>                 (const_int 0 [0x0]))
>>             (label_ref 22)
>>             (pc))) -1 (nil)
>>     (nil))
>>
>> (note 76 19 20 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
>>
>> (jump_insn 20 76 21 5 0x0 (set (pc)   ... this branch exits the loop
>>         (label_ref 36)) -1 (nil)
>>     (nil))
>>
>> (barrier 21 20 22)
>>
>> (code_label 22 21 77 6 6 "" [1 uses])
>>
>> (note 77 22 33 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
>>
>> (jump_insn 33 77 34 6 0x0 (set (pc)
>>         (label_ref 30)) -1 (nil)
>>     (nil))
>>
>> (barrier 34 33 35)
>>
>> (note 35 34 36 NOTE_INSN_LOOP_END)
>>
>> (code_label 36 35 78 7 4 "" [1 uses])
>>
>> (note 78 36 37 7 [bb 7] NOTE_INSN_BASIC_BLOCK)
>>
>> (jump_insn 37 78 38 7 0x0 (set (pc)     ... and is changed to point to
>> 63 instead of 36
>>         (label_ref 63)) -1 (nil)
>>     (nil))
>>
>> If insn 20 were not changed, it would branch to the next instruction
>> and would be removed, leaving the loop in a clean form.
> ?!?  It wouldn't branch to the next instruction because of the jump at
> insn #33.  Unless that's optimized away.
> From looking at the post-cfg rtl, we thread the jump at insn 19, that
> in turn makes the jump at 33 dead.  So indeed we could have just
> zapped insn 20 had it not been mucked up.

Exactly, and that's what happens in the 2nd loop in the example.



More information about the Gcc-patches mailing list