Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
I'm seeing this on my 16-bit ix86 port. Something isn't right:
insn_cost 5: 12
insn_cost 6: 8
insn_cost 7: 4
...
rejecting combination of insns 5 and 6
original costs 12 + 8 = 24
replacement cost 28
Now, 12 + 8 = 20, not 24. The cost obviously includes insn 7 also. What's
happening is that combine is trying to combine insns 5, 6 but needs a CCmode
change in insn 7 because we have plain CCmode but SELECT_CC_MODE chooses
CCZ_Cmode for the combined insn 5+6.
I recommend to add 2 zeros to the integer costs as if those are 2 decimal zeros,
for example,
insn_cost 5: 1200 // it's 12.00
insn_cost 6: 800 // it's 8.00
insn_cost 7: 400 // it's 4.00
insn_cost 8: 433 // it's 4.33 little costly than 7th, +x.xx%
better calibrating.
insn_cost 9: 466 // it's 4.66 little costly than 8th, +x.xx%
better calibrating.
insn_cost 10: 500 // it's 5.00
The 8th & 9th instructions are greater cost than the 7th instruction
that has the
value 4 and lesser cost than the 10th instruction that has the value 5.
There is not integer value of cost beetween 4 and 5, so the solution is x100 to
reach the objective beetween 400 and 500 meaning 4.00 .. 5.00, and then
there are valid values between 401 and 499.
Sincerely, J.C.
