493949 - There are some testcases in the acceptance suite that cannot be jitted

Status: VERIFIED DUPLICATE of bug 473769

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

Description

[Brent Baker]

Running the acceptance suite using the -Djitordie switch shows that there are some testcases that are not able to be jitted.

This bug can be treated as a high level tracking bug and individual issues can be attached (blockers) in the likely event that all of these failures are NOT caused by the same issue.

Comment 1

[Brent Baker]

Attachment: testconfig.txt expected failures

+ mark expected test failures when using -Djitordie
+ switch use of -Ojit in regexp to .*jit.* so both -Ojit and -Djitordie are found

Comment 2

[Brent Baker]

testconfig.txt pushed as 1908:9fc02963c7f5

Comment 3

[Brent Baker]

Should add a -Djitordie acceptance run into the deep testing phase. Should at least do a "release" build pass.

Comment 4

[Dan Schaffer]

on linux acceptance 3 additional tests failed with the cannot jit message,  set to expectedfail in testconfig.txt:
+as3/Expressions/asOperator/asOper, .*-Djitordie , expectedfail, https://bugzilla.mozilla.org/show_bug.cgi?id=493949
+regress/vector_domain_bug, .*-Djitordie , expectedfail, https://bugzilla.mozilla.org/show_bug.cgi?id=493949
+ecma3/String/e15_5_4_4_4_rt, .*-Djitordie , expectedfail, https://bugzilla.mozilla.org/show_bug.cgi?id=493949

Comment 5

[Brent Baker]

as3/Expressions/asOperator/asOper.as is now passing as of 2701:25ac2e1b6609 that was submitted for bug 520531. Removing the expectedfail in 2736:f0842432ddfe

Comment 6

[Brent Baker]

Comment from bug 520531

-------  Comment #9 From  Edwin Smith   2009-10-08 16:31:29 PDT   (-) [reply] -------

it almost certianly is still there.  The jit has a 256-entry limit for its
stack frame management code, and the main things that consume space are
stack-allocated structs (LIR_alloca) and spills of expressions.  small changes
to LIR code can change live ranges or register pressure, and small changes to
what structs are allocated can do that too.

The multiname and inline caching changes changed theset things in LIR, so a
test that was straddling the existing 256-entry limit might move over or under
it based on these changes.

but as you say, the underlying limitation still exists.

Comment 7

[Edwin Smith]

since only known cause is bug 473769 (memory failures aren't an issue anymore), marking this as dup.