704079 - cmpOptimization is wrong

Status: VERIFIED FIXED

(Tamarin Graveyard :: Baseline JIT (CodegenLIR), defect, P2)

Description

[Lars T Hansen]

Consider:

> function f() { var x: float4 = 0, y: Date = null; print(x == y); }
> f()
true

The semantics were clarified after the Waltham meeting to make sure that float4 comparisons do not absorb null/undefined.  In this case the old semantics call for converting null to 0 to float4(0,0,0,0), but that's wrong now.

Comment 1

[Lars T Hansen]

Also botches strict equality, which should respect different types even more strongly:

> function h() { var x: float4 = 0, y: Date = null; print(x === y); }
> h()
true

Comment 2

[William Maddox]

Attachment: Inline LIR_eqf4 only when neither argument requires coercion

Comment 3

[William Maddox]

http://asteam.macromedia.com/hg/tr-float/rev/8f8a455de452

Fixes for CodegenLIR::cmpOptimization(), a few comment cleanups, and extensive test cases to verify that type-specialized comparisons on float and float4, e.g., as implemented by cmpOptimization(), agree with the generic comparisons.

Comment 4

[Brent Baker]

Testcases landed with code