550273 - ARM backend fails to JIT some acceptance testcases

Status: VERIFIED FIXED

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

Description

[Brent Baker]

Running the arm-linux shell with -Djitordie shows that there are some testcases that the ARM backend is unable to JIT.

  mops/mops.abc
  ecma3/LexicalConventions/e7_7_3.abc
  ecma3/Expressions/e11_2_1_1.abc
  ecma3/String/e15_5_4_6_2_rt.abc
  ecma3/String/e15_5_3_2_1.abc
  ecma3/String/e15_5_3_2_2.abc
  ecma3/String/e15_5_4_4_4_rt.abc
  ecma3/ObjectObjects/e15_2_1_1_rt.abc
  ecma3/GlobalObject/e15_1_2_3_1.abc
  ecma3/GlobalObject/e15_1_2_7.abc
  ecma3/GlobalObject/e15_1_2_6.abc
  ecma3/Math/e15_8_2_1.abc
  ecma3/Number/toLocaleString_rt.abc
  ecma3/Number/e15_7_4_2_4.abc
  ecma3/RegExp/eregress_103087.abc
  ecma3/Array/e15_4_4_4_1.abc
  regress/vector_domain_bug.abc
  as3/Expressions/asOperator/asOper.abc
  as3/ShellClasses/Domain.abc

Shell was compiled for arm-linux using patch from bug# 550202 

This is how the runtests was called (notice that I am piggy-backing on the arm-android config for known ARM failures/skips)

./runtests.py --config=arm-andriod-tvm-release-Djitordie --notimecheck --vmargs="-Djitordie"

* exact same testcases that failed to jit when I also ran with VFP support with -Darm_vfp
* same failures with both -Darm_arch 5 and 7

Comment 1

[Lars T Hansen]

Do we know /why/ we fail to JIT these cases?  If not then we risk releasing code that has unknown performance traps on ARM.  Also, since some AS3 facilities are being very lightly covered by the test suite (as eg the "as" operator, whose tests are in the above list) we risk that their JIT implementation is not tested on ARM at all.  Granted, small risk given the structure of the system overall, but still.

Comment 2

[Brent Baker]

(In reply to comment #1)
> Do we know /why/ we fail to JIT these cases?  

Is there a way from the shell to get more information on why JIT fails? Or is this something that needs to be determined by debugging the shell? Just wondering if there is more information that I can provide.

Comment 3

[Dan Smith]

Good points, Lars.  Let's do the analysis and decide on targeting.

Comment 4

[Krzysztof Palacz]

All the jit-or-die failures are due to the JIT trying to reserve more stack space for locals than the hardcoded limit (256 entries on ARM and MIPS, more on other architectures), and only happen while trying to compile global$init(), containing lengthy initialization sequences.  It's doubtful that these locals are actually all live all the time and really require that stack space but that's how it seems to work.

Comment 5

[Dan Smith]

This problem only occurs for global$init() and can be safely deferred to Future.

Comment 6

[Krzysztof Palacz]

May resolve itself depending on the resolution of bug 542016.

Comment 7

[Edwin Smith]

see Bug 556175

Comment 8

[Edwin Smith]

ARM backend has been increased to 1024 entries, and rematerialization has been improved (bug 555255) to reduce stack pressure.  Needs retesting.

Comment 9

[Trevor Baker]

Brent, please retest.

Comment 10

[Brent Baker]

retested -Djitordie on linux-arm with TR rev 5878 and all tests pass.