459755 - TM: Support LIR_merge

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, enhancement)

Description

[Andreas Gal :gal]

It would be nice to be able to merge results after a branch without having to go through memory. A limited form might be sufficient, i.e. LIR_merge sets the register assignment for both arguments to the same register, but requires both values to be defined immediately before LIR_merge along the two incoming control-flow edges to make sure there are no spills interfering. Any ideas?

Comment 1

[Edwin Smith]

is LIR_merge(a,b) semantically the same as phi(a,b)?

Comment 2

[Andreas Gal :gal]

Attachment: patch (untested, for discussion only)

Comment 3

[Andreas Gal :gal]

Ed, what do you think about this approach? We basically use the stack whenever we want to merge values after a jump. So boxing for example would look like this:

if !fits_in_jsint(i) goto x;
push (i)
goto y;
x:
push(call box_as_double(i))
y:
jsval = pop()

Push and pop are very fast on x86, so even performance should be alright.

Comment 4

[Edwin Smith]

is this faster than:

t = LIR_alloc 4 // or 8

if !fits_in_jsint(i) goto x;
store i, t[0]
goto y;
x:
d = call box_as_double(i)
store d, t[0]
y:
jsval = ld t[0]

iow are push/pop better than store/load?  really?

i mean, sure, i get that its not great to have to store to memory, but both of these store to memory.  so it comes down to push/pop vs store/load, right?  what other considerations are there?

my (weak, very weak) concerns about push/pop are just that they now introduce an  explicit stack pointer into LIR semantics, i'm not sure but are we making trouble for ourselves for writing lir manipulation code, that now has to learn about push/pop and stack modelling.

Comment 5

[Andreas Gal :gal]

Not having run any benchmarks on this, I am reasonably certain push/pop are crazy fast on x86. At the very least we save ourselves some register pressure. That having said, I like the LIR_alloc solution as well. We are losing massive performance due to the builtin call right now. Anything but that is an improvement, so I think I will go your route and once we are at the end of that route and need still better code we revisit this bug. I will mask wontfix in the meantime.

Comment 6

[Edwin Smith]

I am hoping that once i get time to work on LIR_def/use, that will give us a nice replacement for LIR_alloc/st/ld, that can keep things in registers.

Comment 7

[Andreas Gal :gal]

The generate code looks pretty reasonable to be honest, and since the slow path contains a call most registers end up getting spilled anyway.