Question about PR 48814 and ivopts and post-increment

[Bin.Cheng]

On Fri, Dec 4, 2015 at 10:48 AM, Bin.Cheng <amker.cheng@gmail.com> wrote:
> On Wed, Dec 2, 2015 at 5:11 AM, Steve Ellcey <sellcey@imgtec.com> wrote:
>>
>> I have a question involving ivopts and PR 48814, which was a fix for
>> the post increment operation.  Prior to the fix for PR 48814, MIPS
>> would generate this loop for strcmp (C code from glibc):
>>
>> $L4:
>>         lbu     $3,0($4)
>>         lbu     $2,0($5)
>>         addiu   $4,$4,1
>>         beq     $3,$0,$L7
>>         addiu   $5,$5,1    # This is a branch delay slot
>>         beq     $3,$2,$L4
>>         subu    $2,$3,$2   # This is a branch delay slot (only used after loop)
>>
>>
>> With the current top-of-tree we now generate:
>>
>>         addiu   $4,$4,1
>> $L8:
>>         lbu     $3,-1($4)
>>         addiu   $5,$5,1
>>         beq     $3,$0,$L7
>>         lbu     $2,-1($5)  # This is a branch delay slot
>>         beq     $3,$2,$L8
>>         addiu   $4,$4,1    # This is a branch delay slot
>>
>>         subu    $2,$3,$2   # Done only once now after exiting loop.
>>
>> The main problem with the new loop is that the beq comparing $2 and $3
>> is right before the load of $2 so there can be a delay due to the time
>> that the load takes.  The ideal code would probably be:
>>
>>         addiu   $4,$4,1
>> $L8:
>>         lbu     $3,-1($4)
>>         lbu     $2,0($5)  # This is a branch delay slot
>>         beq     $3,$0,$L7
>>         addiu   $5,$5,1
>>         beq     $3,$2,$L8
>>         addiu   $4,$4,1    # This is a branch delay slot
>>
>>         subu    $2,$3,$2   # Done only once now after exiting loop.
>>
>> Where we load $2 earlier (using a 0 offset instead of a -1 offset) and
>> then do the increment of $5 after using it in the load.  The problem
>> is that this isn't something that can just be done in the instruction
>> scheduler because we are changing one of the instructions (to modify the
>> offset) in addition to rearranging them and I don't think the instruction
>> scheduler supports that.
> Hmm, I think Bernd introduced sched_flag !DONT_BREAK_DEPENDENCIES to
> resolve dependence by modifying address expression.  I think this is
> the same problem, what's needed is to model dependence using that
> framework.  Maybe delay slot is special here?
>
>>
>> It looks like is the ivopts code that decided to increment the registers
>> first and use the -1 offsets in the loads after instead of using 0 offsets
>> and then incrementing the offsets after the loads but I can't figure out
>> how or why ivopts made that decision.
>>
>> Does anyone have any ideas on how I could 'fix' GCC to make it generate
>> the ideal code?  Is there some way to do it in the instruction scheduler?
>> Is there some way to modify ivopts to fix this by modifying the cost
> It's likely IVO just peaks the first candidate when it runs into a
> tie.  Could you please post preprocessed source code so that I can
> have a look?  I am not familiar with glibc.  Thanks.
Oh, I saw the example in another thread of yours.

Thanks,
bin