Bug 96299 – [CMake] Add flags for LLInt's C Loop backend

• Component: Tools / Tests
• Status: RESOLVED WONTFIX

[Thiago Marcos P. Santos]

For that, we need to disable JIT and the Classic Interpreter.

[Mark Lam]

(In reply to comment #0)
> For that, we need to disable JIT and the Classic Interpreter.

Just to clarify, does the EFL port already support the JIT?  If so, then it should not be too hard for you to go all the way to using the ASM llint (i.e. ENABLE(JIT) and ENABLE(LLINT).  This way, you still get the benefit of the JIT and better llint performance.  Running with the llint C++ interpreter is only interesting if you don't have JIT support.

[Thiago Marcos P. Santos]

(In reply to comment #1)
> (In reply to comment #0)
> > For that, we need to disable JIT and the Classic Interpreter.
> 
> Just to clarify, does the EFL port already support the JIT?  If so, then it should not be too hard for you to go all the way to using the ASM llint (i.e. ENABLE(JIT) and ENABLE(LLINT).  This way, you still get the benefit of the JIT and better llint performance.  Running with the llint C++ interpreter is only interesting if you don't have JIT support.

We are building EFL right now with JIT and ASM LLINT. I guess we have the optimal settings already, right?

[Mark Lam]

(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > For that, we need to disable JIT and the Classic Interpreter.
> > 
> > Running with the llint C++ interpreter is only interesting if you don't have JIT support.
> 
> We are building EFL right now with JIT and ASM LLINT. I guess we have the optimal settings already, right?

Yes.  That is the more optimal setting.  The only other reason you may want the llint C++ interpreter is for debugging purposes, but that need not be your standard configuration.

[Thiago Marcos P. Santos]

Rewording the bug. Gonna add the flags if someone still want to use the C++ interpreter.

[Thiago Marcos P. Santos]

No extra flag is needed. The command line bellow is enough to build C Loop backend if you want to:

Tools/Scripts/build-webkit --[efl|blackberry|etc] --debug --cmakearg="-DENABLE_JIT=OFF -DENABLE_LLINT=ON"

Tried on my desktop, I got the following regressions on the layout tests full run:

Regressions: Unexpected text failures : (3)
  fast/dom/inline-event-attributes-release.html = TEXT
  fast/workers/worker-close-more.html = TEXT
  http/tests/inspector/resource-tree/resource-tree-frame-navigate.html = TEXT

Regressions: Unexpected crashes : (1)
  media/adopt-node-crash.html = CRASH

Regressions: Unexpected timeouts : (1)
  fast/js/random-array-gc-stress.html = TIMEOUT

I'm not saying that they are related (maybe just random flakiness), although the timeout one looks suspicious.

[Mark Lam]

(In reply to comment #5)

I'm currently compiling the list of failures I see with the various interpreter configurations.  Here is some preliminary feedback for you:

> Regressions: Unexpected text failures : (3)
>   fast/dom/inline-event-attributes-release.html = TEXT
>   http/tests/inspector/resource-tree/resource-tree-frame-navigate.html = TEXT

I haven't seen these in any of my interpreter configurations.  Could be flakiness in the test.

>   fast/workers/worker-close-more.html = TEXT

This one has failed on all interpreter configurations so far.

> Regressions: Unexpected crashes : (1)
>   media/adopt-node-crash.html = CRASH

I haven't seen these in any of my interpreter configurations.  Could be flakiness in the test.

> Regressions: Unexpected timeouts : (1)
>   fast/js/random-array-gc-stress.html = TIMEOUT

This one is known.  It occurs when you run the test with any interpreter configuration (i.e. without a JIT).  If you take away the time out, it passes.

These are based on my test runs on platform mac.  YMMV.

[Mark Lam]

(In reply to comment #6)
> I'm currently compiling the list of failures I see with the various interpreter configurations.

FYI, the layout test results are recorded in comment <https://bugs.webkit.org/show_bug.cgi?id=91052#c33> and attachment <https://bug-91052-attachments.webkit.org/attachment.cgi?id=163231>.