483649 - ppc64 debugger builds failing test suite

Status: VERIFIED FIXED

(Tamarin Graveyard :: Virtual Machine, defect)

Description

[Rick Reitmaier]

The following tests are failing on [debug|release] debugger builds : 

  ecma3/TypeConversion/e9_3.abc : Number(false) = -238423838475.15292 FAILED! expected: 0
  ecma3/TypeConversion/e9_3.abc : Number(0) = -238423838475.15292 FAILED! expected: 0
  ecma3/Types/e8_5.abc : var s:Number = 'string' = -238423838475.15292 FAILED! expected: NaN

Comment 1

[Brent Baker]

Marked expected failures until this is fixed: 1608:7c44b7d26f76

Marking as blocking the next TC merge since this is an injection.

Comment 2

[Rick Reitmaier]

Interesting; the following code fails: 

function foo() {
  var a = Number(false);
  var b = Number(0);
  return b
}

print(foo())

And re-enabling deadvars() allows it to pass.

Comment 3

[Rick Reitmaier]

Attachment: ver 1 - fmr fix

The issue turned out to be specific to the fmr() instruction.  

We were generating fmr f1,r15  <= note non-fp reg as src.

The problem started with a downstream store (stqi) for the result of a i2f.  This reserved a gp register, r15.  When we then came across a call in which we needed to pass the i2f result, f1 was marked as the argument and since the i2f result was already in r15, a fmr was issued.

This brings up an interesting point on 64b systems; since gp regs can hold the float value and we're using quad instructions somewhat interchangeably with float on these systems, are there other instances where we incorrectly choose a gp reg instead of a fp reg?

Diving into this bug also made me realize that debugger builds (with deadvars disabled) are generating absolutely horrible code.  I'll open a bug for that.

Comment 4

[Rick Reitmaier]

Attachment: ver 2 - removed extraneous changes from prior patch

Comment 5

[Edwin Smith]

(In reply to comment #3)
> Created an attachment (id=369001) [details]

> This brings up an interesting point on 64b systems; since gp regs can hold the
> float value and we're using quad instructions somewhat interchangeably with
> float on these systems, are there other instances where we incorrectly choose a
> gp reg instead of a fp reg?

bugs are certianly possible, but in the X64 code I did find and fix several in this area.  Each case in asm_nongp_copy() is definitely being used, as a result.

Take a look at NativeX64 asm_regarg(), since it just uses findSpecificRegFor(), it should handle the various corner cases.  (of course, it is slightly less optimized; the ppc code will copy from a saved-reg to a scratch-reg without forgetting the expr's assignment to the saved reg.  this should yeild less spillage).

> Diving into this bug also made me realize that debugger builds (with deadvars
> disabled) are generating absolutely horrible code.  I'll open a bug for that.

Comment 6

[Rick Reitmaier]

e772e92d06e4: Fix for bug 483649 - ppc64 fmr instruction fix (r=edwsmith) - rev 1682

Comment 7

[Brent Baker]

failing tests have been passing since the fix was submitted, removed "expectedfail" in changeset 1696:b1d4d72e4a22