Question about PR 48814 and ivopts and post-increment
Jeff Law
law@redhat.com
Tue Dec 1 22:50:00 GMT 2015
On 12/01/2015 02:11 PM, Steve Ellcey wrote:
> 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:
I'd start by looking at the code prior to reorg/delay slot scheduling.
It may be the case that you're running into the well known issue that
when reorg knows nothing about latency/scheduling issues and happily
picks whatever insn can safely fill the delay slot. In doing so, reorg
may muck up the schedule badly.
If that's the case you might test disallowing operations with > 1 cycle
latency in delay slots and see how that effects a wider range of benchmarks.
Jeff
More information about the Gcc
mailing list