542629 - nanojit: make LIR_mul faster than LIR_mulxov on ARM

Status: RESOLVED WONTFIX

(Core Graveyard :: Nanojit, defect)

Description

[Nicholas Nethercote [inactive]]

Follow-on from bug 539874:

> Also, for MUL, we don't care about overflow in the non-xov case, so a simple
> MUL implementation will suffice (and be an improvement on what we have before).
> This will be faster than SMULL! It's non-trivial (as SMULL is) because you have
> to deal with ARMv5's strange rX=rX*rY problem.

Comment 1

[Jacob Bramley [:jbramley]]

We should also use the barrel shifter for multiply-by-power-of-two operations whilst we're at it. A simple dump of MUL-with-immediate frequency looks like this:

Value   | Frequency (trace-test) | Frequency (SunSpider)
--------+------------------------+-----------------------
10      | 2 (1%)                 | 0 (0%)
100     | 5 (3%)                 | 11 (4%)
10000   | 1 (1%)                 | 11 (4%)
1000000 | 1 (1%)                 | 0 (0%)
2       | 18 (9%)                | 88 (30%)
3       | 3 (2%)                 | 22 (7%)
4       | 2 (1%)                 | 99 (33%)
8       | 159 (83%)              | 66 (22%)

2, 4 and 8 are particularly easy to implement. Multiply-by-eight looks like this:

MOV rX, rY, LSL #3

Multiply-by-three is also easy, but may add too much code bloat to be worthwhile. The others are rare enough that they probably aren't worth optimizing.

It's slightly more complicated when you want to catch overflow, but not by much.

Comment 2

[Edwin Smith]

should this be done in the processor backend or in LIR?

Comment 3

[Steven Johnson]

I'm guessing processor-specific -- this might not be a win on all cpus.

Comment 4

[Edwin Smith]

granted, but processor specific optimizations can be done on LIR or in the backend.  Doing it on LIR has the advantage of exposing it to other optimizer passes.  Doing it in the backend may in some cases be faster and is best if it needs detailed knowlege of register pressure, etc.

Comment 5

[Nicholas Nethercote [inactive]]

Nanojit has been dead for several years. Its Bugzilla component has been moved to the graveyard (bug 984276).

I checked all the open bugs. They're all uninteresting, so I'm WONTFIXing them all. Apologies for the bugspam.