1103311 - Pointless register move output when calling a DOM getter that was found on the receiver

Status: NEW

(Core :: JavaScript Engine: JIT, defect, P5)

Description

[Boris Zbarsky [:bzbarsky]]

Consider the situation in which we're in IonBuilder::getPropTryCommonGetter, "obj" is a singleton, and foundProto comes back as the same object as obj.  In other words, the window.foo case on the web.  ;)

Here's what JIT inspector says happens:

[Pointer:GC_THING]
  movabsq    $0x134ae0060, %rax
[GuardShape]
  movabsq    $0x12796c358, %r11
  cmpq       %r11, 0(%rax)
  jne        ((1562))
[Pointer:GC_THING]
  movabsq    $0x134ae0060, %rax

That's because we have an MConstant that's pointed to by both the GuardShape and the actual getter MInstruction.  Lowering converts this to an LPointer, but a new LPointer each time the MInstruction is seen.  So we end up with a pointless movabsq there.

The question is what we can do about this... I'm really not sure.  It _looks_ annoying, but not sure how much it matters in practice.

Comment 1

[Dan Gohman [:sunfish]]

Attachment: dont-emit-64bit-pointers-at-uses.patch

Here's a quick patch with one possible approach: emitting code for pointer constants on x64 at their definition, rather than at each use. The downside is that this increases register pressure in some cases.

Comment 2

[Dan Gohman [:sunfish]]

Attachment: simplify-stringsplit-operand.patch

The above patch also causes regressions due to a bunch of constants getting materialized in registers that aren't actually needed.

This patch fixes one such case. The StringSplit code builds an MConstant to hold the template object, but the MConstant itself isn't actually used. Attached is a patch which eliminates the MConstant.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Yeah, globally changing how constants work seems like a pretty big hammer for this problem, possibly out of proportion to the size of the problem...  Not sure whether there are smaller hammers here, though.