On Thu, 2015-12-03 at 19:56 +0000, Ramana Radhakrishnan wrote:
> IIRC it's because the scheduler *thinks* it can get a tighter schedule
> - probably because it thinks it can dual issue the lbu from $4 and the
> addiu to $5. Can it think so ? This may be related -
> https://gcc.gnu.org/ml/gcc-patches/2012-08/msg00155.html
>
> regards
> Ramana
No, the system I am tuning for (MIPS 24k) is single issue according to
its description. At least I do see now where the instruction is getting
rewritten in the instruction scheduler, so that is helpful. I am no
longer sure the scheduler is where the problem lies though. If I
compile with -O2 -mtune=24kc I get this loop:
addiu $4,$4,1
$L8:
addiu $5,$5,1
lbu $3,-1($4)
beq $3,$0,$L7
lbu $2,-1($5)
beq $3,$2,$L8
addiu $4,$4,1
If I use -O2 -fno-ivopts -mtune=24kc I get:
lbu $3,0($4)
$L8:
lbu $2,0($5)
addiu $4,$4,1
beq $3,$0,$L7
addiu $5,$5,1
beql $3,$2,$L8
lbu $3,0($4)
This second loop is better because there is more time between the loads
and where the loaded values are used in the beq instructions. So I
think there is something missing or wrong in the cost analysis that
ivopts is doing that it decides to do the adds before the loads instead
of visa versa.
I have tried tweaking the cost of loads in mips_rtx_costs and in the
instruction descriptions in 24k.md but that didn't seem to have any
affect on the ivopts code.
Steve Ellcey
sell...@imgtec.com
