[webkit-dev] Bring back ARMv6 support to JSC

[Caio Lima]

Hi guys,I've posted this on the bug thread, but I would also like to
revive the discussion here.

After our last discussion, I put some effort to enable IC for ARMv6
into JIT layers and now I finally collected some results for that.

Now, we have regressions just into 2 tests in SunSpider (they aren't
regressing in LongSpider) and 3 into Octane (gbemu, typescript and
box2d). Also, I see regressions into microbenchmarks, mainly cases
with observable-side-effects and set/map tests.

With these results, what do you think about keep working into ARMv6 support?

Maybe an important report is that I'm almost fixing the errors taking
the http://trac.webkit.org/changeset/220532 as baseline. Currently
there are ~40 tests failing, and the majority of them are due to OOM
into my runtime env, due to memory constraints. I will try to merge it
with current master this week to check the status of build+failures.

Regards,
Caio.

2017-08-01 20:52 GMT-03:00 Caio Lima <ticaiolima at gmail.com>:
> Hi all.
>
> FYI, I keep the last weeks investigating the issue with ARMv6 IC and I
> was able to find the source of the bug and apply a quick fix to run
> benchmarks again to get results. I just ran V8Spider, Octane and
> Kraken by now and I'm attaching the results in this email.
>
> We found some test cases regressing, and my attention now is to
> identify the reason of the regression and how to fix them. Also, the
> improvements got with JIT in ARMv6 aren't as big as Filip commented in
> [1] to supported architectures.
>
> [1] - https://bugs.webkit.org/show_bug.cgi?id=172765#c9
>
> 2017-07-13 19:27 GMT-03:00 Caio Lima <ticaiolima at gmail.com>:
>> Yes. It probably will take a while to process on device, but I'll run it.
>>
>> Em qui, 13 de jul de 2017 às 17:50, Saam barati <sbarati at apple.com>
>> escreveu:
>>>
>>> And ARES6.
>>>
>>> - Saam
>>>
>>>
>>> On Jul 13, 2017, at 1:50 PM, Saam barati <sbarati at apple.com> wrote:
>>>
>>> Can you please run Octane and Kraken too?
>>>
>>> - Saam
>>>
>>> On Jul 13, 2017, at 7:47 AM, Caio Lima <ticaiolima at gmail.com> wrote:
>>>
>>> Finally I got the results from the last benchmark run. The results
>>> shows that the speed-ups are considerable comparing with CLoop
>>> version, since we get faster results in a big number of tests and
>>> regress in a minor number of scripts. I would like to get feedback
>>> from you as well, but IMHO enabling JIT for ARMv6 looks a good
>>> improvement step and the amount of code we are touching in current
>>> trunk code to make it possible is small.
>>>
>>> The results are attached and I also uploaded them in
>>> https://bugs.webkit.org/show_bug.cgi?id=172765.
>>>
>>> PS.: Some test cases (bigswitch-indirect-symbol-or-undefined,
>>> bigswitch-indirect-symbol, bigswitch, etc) are failing now and I'm
>>> already investigating the source of problem to fix them.
>>>
>>> Regards,
>>> Caio.
>>>
>>> 2017-07-05 22:54 GMT-03:00 Filip Pizlo <fpizlo at apple.com>:
>>>
>>> To be clear, I’m concerned that the 32-bit JIT backends have such bad
>>> tuning for these embedded platforms that it’s just pure badness. Until you
>>> can prove that you can change this, I think that porting should focus on
>>> making the cloop great. Then, we can rip out support for weird CPUs rather
>>> than bringing it back.
>>>
>>> -Filip
>>>
>>> On Jul 5, 2017, at 6:14 PM, Caio Lima <ticaiolima at gmail.com> wrote:
>>>
>>> 2017-07-05 18:25 GMT-03:00 Filip Pizlo <fpizlo at apple.com>:
>>>
>>> You need to establish that the JIT is a performance progression over the
>>> LLInt on ARMv6. I am opposed to more ARMv6 patches landing until there is
>>> some evidence provided that you’re actually getting speed-ups.
>>>
>>>
>>> It makes sense. I can get these numbers related to JIT.
>>>
>>> BTW, there is a Patch that isn't JIT related
>>> (https://bugs.webkit.org/show_bug.cgi?id=172766).
>>>
>>> Regards,
>>> Caio.
>>>
>>> -Filip
>>>
>>> On Jun 13, 2017, at 6:48 PM, Caio Lima <ticaiolima at gmail.com> wrote:
>>>
>>> Hi All.
>>>
>>> Some of you guys might know me through the work I have been doing in
>>> JSC. The experience working with WebKit has been great so far, thank
>>> you for the reviews!
>>>
>>> Since 1st May, we at Igalia have been working on bring back the ARMv6
>>> support into JSC. We already have commits into our downstream branch
>>> port[2] that fixes some compile/runtime errors when building JSC to
>>> ARMv6 and also fixes some bugs. However, this branch is not synced
>>> with WebKit upstream tree and I would like to pursue the upstreaming
>>> of this ARMv6/JSC support to WebKit.
>>>
>>> As a long shot, we are planning to maintain the ARMv6 support and make
>>> tests run as green as possible. Also, it's our goal make ARMv6 support
>>> not interfere with other ARM versions support code negatively and we
>>> will be in charge of implement platform-specific fixes/features for
>>> JSC/ARM6, this way no imposing burden to the rest of the community.
>>>
>>> To keep track of work to be done, I've create a meta-bug in
>>> bugzilla[3] and it's going to be used firstly to organize the commits
>>> from our downstream branch, but pretty soon I'm going to create issues
>>> related with javascriptcore-test failures and send patches to fix
>>> them. We have already submitted 3 patches (they are marked as
>>> dependence of [3]) that fixes ARMv6 into LLInt and JIT layers and got
>>> a round of review into them.
>>>
>>> Best Regards,
>>> Caio.
>>>
>>> [1] - https://www.igalia.com/about-us/coding-experience
>>> [2] - https://github.com/WebPlatformForEmbedded/WPEWebKit
>>> [3] - https://bugs.webkit.org/show_bug.cgi?id=172765
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>>
>>> <baseline_changes_SunSpiderLongSpiderV8SpiderMicrobenchmarksSixSpeed_buildroot_20170712_1029_report.txt>_______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>>
>>>
>>