Right now we only demote slots to int if we see a ++ on them or the last store (the one that flows along the loop edge) is f2i. This takes care of ints we produce in the loop. In addition, we should also track each use of a slot. If all uses are f2i, then we should make that value int too. That would take care of values we only use as ints in the loop. Right now we explicitly demote those on trace with doubleToInt32.
This bug is obsolete. We use now a method devised by shaver: Treat everything thats an int at entry as an integer and re-compile and flag them as double if they don't end the trace with either an f2i (which guarantees the slot will be int inside the loop), or fadd x +/- 1. For the latter we emit an additional LIR_ov overflow check since we could overflow outside the int32 range. If the speculative demotion fails, we notify the shared Oracle hash-table that that slot shouldn't be speculatively demoted any more in the future.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.