Re: [webkit-dev] Some text about the B3 compiler

[Carlos Alberto Lopez Perez]

On 02/02/16 00:27, Ryosuke Niwa wrote:
> 
> We've been running those benchmarks with
> http://trac.webkit.org/browser/trunk/Tools/Scripts/run-benchmark
> 
> It might be useful for Mac and other ports to have bots available on
> build.webkit.org as well.
> 

After discussing this with Carlos Garcia. We think we will do the following:

1. Implement support on this run-benchmark script to execute the tests also on 
the WebKitGTK+ MiniBrowser.
2. Create a new step 'benchmark-test' for the bots to execute this script.
3. Make the current WebKitGTK+ performance test bot [1] run this step after the 
current 'perf-tests' step.
4. Hope that Apple makes public their private performance dashboard so we can 
tell the bot to upload the results there.

That way we will be running this JSC tests automatically on a browser helping 
to catch failures.

Any comment/suggestion regarding the plan is welcome.

Regards.


[1] 
https://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release%20%28Perf%29



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Filip Pizlo]

> On Feb 2, 2016, at 4:56 PM, Carlos Alberto Lopez Perez  
> wrote:
> 
> On 02/02/16 19:58, Ryosuke Niwa wrote:
>> On Tue, Feb 2, 2016 at 10:42 AM, Carlos Alberto Lopez Perez
>>> But this script seems focused on comparing the performance between
>>> different browsers (safari vs chrome vs firefox) rather than in testing
>>> and comparing the performance between different revisions of WebKit.
>> 
>> Not at all.  It simply supports running benchmark in other browsers.
>> 
>>> Do you think it makes any difference (from the point of view of
>>> detecting failures, not from the performance PoV) to run this tests in a
>>> full-fledged browser like Safari rather than in WebKitTestRunner ?
>> 
>> Yes. There are many browser features that can significantly impact the
>> real world performance.
>> 
> 
> I'm specifically not asking about performance, but about correctness.
> 
> This discussion was started because Filip said that running JS tests on
> a browser catches many failures that are not cached when running the
> tests from the terminal.
> 
> So, I'm wondering if running the JS tests on WTR or Safari makes any
> difference when catching failures.

I suspect that the browser will catch more failures.

> 
>>> We already have a performance test bot running tests inside WTR.
>>> And I see that the current set of tests executed on this bot already
>>> includes Speedometer, and that JetStream and Sunspider are skipped on
>>> PerformanceTests/Skipped.
>>> 
>>> So I see some options going forward:
>>> 
>>> - Fix the JetStream and Sunspider tests so they can be run as part of
>>> the current run-perf-tests script that the performance bots execute.
>> 
>> We should use run-benchmark instead since run-benchmark spits out the
>> JSON file that's compatible with run-pref-tests.
>> 
> 
> I'm a bit lost here. Are you planning to deprecate run-perf-tests with
> run-benchmark? What is wrong with run-perf-tests?
> 
>>> - Implement support on the script run-benchmark to run the tests inside
>>> WTR, and create a new step running this script that will be executed on
>>> the test bots.
>> 
>> I don't see a point in doing this.   Why is it desirable to run these
>> benchmarks inside WebKitTestRunner?
>> 
> 
> Less dependencies: WTR (or the MiniBrowser) is something that is
> currently built by the bots on each build.
> If we want to use Epiphany (for example) for the performance tests, is
> another thing we have to take care of building before each run. Not a
> big deal, but I wonder if is really worth.
> 
>>> - Deploy a new bot that runs run-perf-tests on a full-fledged browser
>>> like Safari or Epiphany.
>> 
>> We should just do this.
>> 
>>> I wonder what you think is the best option or if there is some option
>>> not viable.
>>> 
>>> From my PoV, the option #1 has the advantage of reusing the current
>>> infrastructure that collects and draws performance data at
>>> https://perf.webkit.org
>> 
>> We have an internal instance of the same dashboard to which we're
>> reporting results of run-benchmark script.
>> 
> 
> What about making this public? We will happily contribute with a
> GTK+/Linux buildbot for it.
> 
> 
> Regards.
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Carlos Alberto Lopez Perez]

On 02/02/16 19:58, Ryosuke Niwa wrote:
> On Tue, Feb 2, 2016 at 10:42 AM, Carlos Alberto Lopez Perez
>> But this script seems focused on comparing the performance between
>> different browsers (safari vs chrome vs firefox) rather than in testing
>> and comparing the performance between different revisions of WebKit.
> 
> Not at all.  It simply supports running benchmark in other browsers.
> 
>> Do you think it makes any difference (from the point of view of
>> detecting failures, not from the performance PoV) to run this tests in a
>> full-fledged browser like Safari rather than in WebKitTestRunner ?
> 
> Yes. There are many browser features that can significantly impact the
> real world performance.
> 

I'm specifically not asking about performance, but about correctness.

This discussion was started because Filip said that running JS tests on
a browser catches many failures that are not cached when running the
tests from the terminal.

So, I'm wondering if running the JS tests on WTR or Safari makes any
difference when catching failures.

>> We already have a performance test bot running tests inside WTR.
>> And I see that the current set of tests executed on this bot already
>> includes Speedometer, and that JetStream and Sunspider are skipped on
>> PerformanceTests/Skipped.
>>
>> So I see some options going forward:
>>
>>  - Fix the JetStream and Sunspider tests so they can be run as part of
>> the current run-perf-tests script that the performance bots execute.
> 
> We should use run-benchmark instead since run-benchmark spits out the
> JSON file that's compatible with run-pref-tests.
> 

I'm a bit lost here. Are you planning to deprecate run-perf-tests with
run-benchmark? What is wrong with run-perf-tests?

>>  - Implement support on the script run-benchmark to run the tests inside
>> WTR, and create a new step running this script that will be executed on
>> the test bots.
> 
> I don't see a point in doing this.   Why is it desirable to run these
> benchmarks inside WebKitTestRunner?
> 

Less dependencies: WTR (or the MiniBrowser) is something that is
currently built by the bots on each build.
If we want to use Epiphany (for example) for the performance tests, is
another thing we have to take care of building before each run. Not a
big deal, but I wonder if is really worth.

>>  - Deploy a new bot that runs run-perf-tests on a full-fledged browser
>> like Safari or Epiphany.
> 
> We should just do this.
> 
>> I wonder what you think is the best option or if there is some option
>> not viable.
>>
>> From my PoV, the option #1 has the advantage of reusing the current
>> infrastructure that collects and draws performance data at
>> https://perf.webkit.org
> 
> We have an internal instance of the same dashboard to which we're
> reporting results of run-benchmark script.
> 

What about making this public? We will happily contribute with a
GTK+/Linux buildbot for it.


Regards.



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Ryosuke Niwa]

On Tue, Feb 2, 2016 at 10:42 AM, Carlos Alberto Lopez Perez
 wrote:
> On 02/02/16 00:27,
- R. Niwa
 wrote:
>> On Mon, Feb 1, 2016 at 7:32 AM, Carlos Alberto Lopez Perez
>>  wrote:
>>> On 31/01/16 05:16, Filip Pizlo wrote:
 As my original message said, I was wondering if there was any support
 for running some JavaScript tests *in browser*.  run-jsc-stress-tests
 doesn’t support that because it doesn’t know what a browser is.

 Some tests, like Kraken, Octane, JetStream, and Speedometer, either
 require a browser to run (like JetStream and Speedometer) or have
 significantly different behavior in the browser than in their
 command-line harnesses (like Kraken and Octane).  If you did have a
 bot that ran these tests in some GTK+ or EFL browser, you’d probably
 catch bugs that testing the JSC shell cannot catch.

 -Filip
>>>
>>> Some questions regarding this JSC in-browser benchmarks:
>>>
>>> How does the Apple port runs this? Do you use some script that is
>>> currently available on the WebKit source tree? Are the buildbots running
>>> this tests public?
>>
>> We've been running those benchmarks with
>> http://trac.webkit.org/browser/trunk/Tools/Scripts/run-benchmark
>>
>
> I see.
>
> But this script seems focused on comparing the performance between
> different browsers (safari vs chrome vs firefox) rather than in testing
> and comparing the performance between different revisions of WebKit.

Not at all.  It simply supports running benchmark in other browsers.

> Do you think it makes any difference (from the point of view of
> detecting failures, not from the performance PoV) to run this tests in a
> full-fledged browser like Safari rather than in WebKitTestRunner ?

Yes. There are many browser features that can significantly impact the
real world performance.

> We already have a performance test bot running tests inside WTR.
> And I see that the current set of tests executed on this bot already
> includes Speedometer, and that JetStream and Sunspider are skipped on
> PerformanceTests/Skipped.
>
> So I see some options going forward:
>
>  - Fix the JetStream and Sunspider tests so they can be run as part of
> the current run-perf-tests script that the performance bots execute.

We should use run-benchmark instead since run-benchmark spits out the
JSON file that's compatible with run-pref-tests.

>  - Implement support on the script run-benchmark to run the tests inside
> WTR, and create a new step running this script that will be executed on
> the test bots.

I don't see a point in doing this.   Why is it desirable to run these
benchmarks inside WebKitTestRunner?

>  - Deploy a new bot that runs run-perf-tests on a full-fledged browser
> like Safari or Epiphany.

We should just do this.

> I wonder what you think is the best option or if there is some option
> not viable.
>
> From my PoV, the option #1 has the advantage of reusing the current
> infrastructure that collects and draws performance data at
> https://perf.webkit.org

We have an internal instance of the same dashboard to which we're
reporting results of run-benchmark script.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Carlos Alberto Lopez Perez]

On 02/02/16 00:27, Ryosuke Niwa wrote:
> On Mon, Feb 1, 2016 at 7:32 AM, Carlos Alberto Lopez Perez
>  wrote:
>> On 31/01/16 05:16, Filip Pizlo wrote:
>>> As my original message said, I was wondering if there was any support
>>> for running some JavaScript tests *in browser*.  run-jsc-stress-tests
>>> doesn’t support that because it doesn’t know what a browser is.
>>>
>>> Some tests, like Kraken, Octane, JetStream, and Speedometer, either
>>> require a browser to run (like JetStream and Speedometer) or have
>>> significantly different behavior in the browser than in their
>>> command-line harnesses (like Kraken and Octane).  If you did have a
>>> bot that ran these tests in some GTK+ or EFL browser, you’d probably
>>> catch bugs that testing the JSC shell cannot catch.
>>>
>>> -Filip
>>
>> Some questions regarding this JSC in-browser benchmarks:
>>
>> How does the Apple port runs this? Do you use some script that is
>> currently available on the WebKit source tree? Are the buildbots running
>> this tests public?
> 
> We've been running those benchmarks with
> http://trac.webkit.org/browser/trunk/Tools/Scripts/run-benchmark
> 

I see.

But this script seems focused on comparing the performance between
different browsers (safari vs chrome vs firefox) rather than in testing
and comparing the performance between different revisions of WebKit.

Do you think it makes any difference (from the point of view of
detecting failures, not from the performance PoV) to run this tests in a
full-fledged browser like Safari rather than in WebKitTestRunner ?

We already have a performance test bot running tests inside WTR.
And I see that the current set of tests executed on this bot already
includes Speedometer, and that JetStream and Sunspider are skipped on
PerformanceTests/Skipped.

So I see some options going forward:

 - Fix the JetStream and Sunspider tests so they can be run as part of
the current run-perf-tests script that the performance bots execute.

 - Implement support on the script run-benchmark to run the tests inside
WTR, and create a new step running this script that will be executed on
the test bots.

 - Deploy a new bot that runs run-perf-tests on a full-fledged browser
like Safari or Epiphany.

I wonder what you think is the best option or if there is some option
not viable.

From my PoV, the option #1 has the advantage of reusing the current
infrastructure that collects and draws performance data at
https://perf.webkit.org

> It might be useful for Mac and other ports to have bots available on
> build.webkit.org as well.
> 

Indeed.



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Benjamin Poulain]

On 1/30/16 3:36 PM, Michael Catanzaro wrote:

On Sun, 2016-01-31 at 06:00 +0900, Yusuke SUZUKI wrote:

Now, https://bugs.webkit.org/show_bug.cgi?id=153647 and
https://bugs.webkit.org/show_bug.cgi?id=153711 are landed.

So, now, in GTK Linux x64 port, all the JSC tests pass! I think it's
time
to enable B3 in Linux x64 :D

Regards,
Yusuke Suzuki


Let's turn this on. :)

I thought we could remove all the LLVM goo from the CMake build system,
but I see there is some code to support LLVM for the EFL port on
AArch64. (For the GTK port, FTL is only supported on x86_64).

Do we want to continue to support FTL on AArch64 using LLVM, or do we
want to just turn off FTL on that platform until B3 is ready? It's
currently disabled by default, so I don't see much value in keeping it
around.


B3 on AArch64 is passing the tests since last Friday but it does not yet 
generate great assembly.


It is likely there are still bugs, just not covered by the tests. Please 
tell me if you find anything suspicious on ARM.


Benjamin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Ryosuke Niwa]

On Mon, Feb 1, 2016 at 7:32 AM, Carlos Alberto Lopez Perez
 wrote:
> On 31/01/16 05:16, Filip Pizlo wrote:
>> As my original message said, I was wondering if there was any support
>> for running some JavaScript tests *in browser*.  run-jsc-stress-tests
>> doesn’t support that because it doesn’t know what a browser is.
>>
>> Some tests, like Kraken, Octane, JetStream, and Speedometer, either
>> require a browser to run (like JetStream and Speedometer) or have
>> significantly different behavior in the browser than in their
>> command-line harnesses (like Kraken and Octane).  If you did have a
>> bot that ran these tests in some GTK+ or EFL browser, you’d probably
>> catch bugs that testing the JSC shell cannot catch.
>>
>> -Filip
>
> Some questions regarding this JSC in-browser benchmarks:
>
> How does the Apple port runs this? Do you use some script that is
> currently available on the WebKit source tree? Are the buildbots running
> this tests public?

We've been running those benchmarks with
http://trac.webkit.org/browser/trunk/Tools/Scripts/run-benchmark

It might be useful for Mac and other ports to have bots available on
build.webkit.org as well.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Carlos Alberto Lopez Perez]

On 31/01/16 05:16, Filip Pizlo wrote:
> As my original message said, I was wondering if there was any support
> for running some JavaScript tests *in browser*.  run-jsc-stress-tests
> doesn’t support that because it doesn’t know what a browser is.
> 
> Some tests, like Kraken, Octane, JetStream, and Speedometer, either
> require a browser to run (like JetStream and Speedometer) or have
> significantly different behavior in the browser than in their
> command-line harnesses (like Kraken and Octane).  If you did have a
> bot that ran these tests in some GTK+ or EFL browser, you’d probably
> catch bugs that testing the JSC shell cannot catch.
> 
> -Filip

Some questions regarding this JSC in-browser benchmarks:

How does the Apple port runs this? Do you use some script that is
currently available on the WebKit source tree? Are the buildbots running
this tests public?

Regards
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Carlos Garcia Campos]

El dom, 31-01-2016 a las 06:00 +0900, Yusuke SUZUKI escribió:
> Now, https://bugs.webkit.org/show_bug.cgi?id=153647 and https://bugs.
> webkit.org/show_bug.cgi?id=153711 are landed.

Awesome, thanks for fixing those issues so quickly.

> So, now, in GTK Linux x64 port, all the JSC tests pass! I think it's
> time to enable B3 in Linux x64 :D

Indeed!

> Regards,
> Yusuke Suzuki
> 
> On Sat, Jan 30, 2016 at 8:09 AM, Filip Pizlo 
> wrote:
> > Follow up on this:
> > 
> > > On Jan 29, 2016, at 11:38 AM, Filip Pizlo 
> > > wrote:
> > > 
> > > I started coverting the documentation to Markdown.  I don’t think
> > > this is a good idea.
> > > 
> > > - Markdown has no definition lists.  The entire IR document is a
> > > definition list.  I don’t want B3’s documentation to be blocked
> > > on this issue.
> > It turns out that it does have them, but they are very weak.  For
> > example, you can’t have code blocks or paragraphs inside them.  We
> > want to have code blocks inside opcode definitions, to show
> > examples.
> > 
> > > - Markdown’s conversion step makes the workflow awkward.  I’m not
> > > going to use some Markdown editing app - that will prevent me
> > > from being able to properly format code examples.  I need a code
> > > editor for that.
> > This was hard to get around.  This isn’t a problem with Markdown,
> > but rather, a problem with using Wordpress to render Markdown that
> > is in svn.  There is no way to preview the Markdown before
> > committing it.  That would lead to unusual problems, where after a
> > patch is landed, the patch author or someone else would have to do
> > a bunch of blind follow-up commits to fix any style issues, like
> > code blocks that don’t fit properly or whatever.
> > 
> > Considering that we will have to be hacking raw HTML inside those
> > Markdown files (due to definition lists), the lack of preview
> > basically means that you have no way of predicting what the your
> > HTML will render like.
> > 
> > > 
> > > I think that this documentation should be HTML.  I don’t think we
> > > should expend a lot of energy to formatting it nicely.  The point
> > > of this document is for it to be read by engineers while they
> > > hack code.
> > I landed raw HTML documentation: http://trac.webkit.org/changeset/1
> > 95841
> > 
> > I filed this bug about improving its style: https://bugs.webkit.org
> > /show_bug.cgi?id=153674
> > 
> > -Filip
> > 
> > 
> > > 
> > > -Filip
> > > 
> > > 
> > > > On Jan 29, 2016, at 10:12 AM, Timothy Hatcher  > > > m> wrote:
> > > > 
> > > > I also added:
> > > > 
> > > > https://webkit.org/documentation/b3/air/ loads /docs/b3/assembl
> > > > y-intermediate-representation.md
> > > > 
> > > > > On Jan 29, 2016, at 10:05 AM, Filip Pizło 
> > > > > wrote:
> > > > > 
> > > > > Thank you!  I'll convert them today. 
> > > > > 
> > > > > -Filip
> > > > > 
> > > > > On Jan 29, 2016, at 10:02 AM, Timothy Hatcher  > > > > com> wrote:
> > > > > 
> > > > > > Markdown is pretty similar to the wiki formatting and very
> > > > > > simple.
> > > > > > 
> > > > > > You can look at a cheatsheet if you login to the blog: http
> > > > > > s://webkit.org/wp/wp-admin/post.php?post=4300&action=edit
> > > > > > 
> > > > > > I have also used this HTML to Markdown converter before: ht
> > > > > > tp://domchristie.github.io/to-markdown/
> > > > > > 
> > > > > > The pages are created:
> > > > > > 
> > > > > > https://webkit.org/documentation/b3/ loads /docs/b3/bare-bo
> > > > > > nes-backend.md
> > > > > > https://webkit.org/documentation/b3/intermediate-representa
> > > > > > tion/ loads /docs/b3/intermediate-representation.md
> > > > > > 
> > > > > > Once those files are added to SVN, they will get picked up
> > > > > > by the site. I can change those to point to other names if
> > > > > > you want something different.
> > > > > > 
> > > > > > — Timothy Hatcher
> > > > > > 
> > > > > > > On Jan 29, 2016, at 9:34 AM, saam barati  > > > > > > il.com> wrote:
> > > > > > > 
> > > > > > > I'm happy to convert the document to markdown. Can you
> > > > > > > send me your latest revision or post it to the website?
> > > > > > > 
> > > > > > > I usually look at:
> > > > > > > http://daringfireball.net/projects/markdown/syntax
> > > > > > > For a refresher on the syntax.
> > > > > > > 
> > > > > > > Tim, could you create a page that loads the markdown
> > > > > > > file?
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Saam
> > > > > > > 
> > > > > > > On Jan 29, 2016, at 12:06 AM, Filip Pizło  > > > > > > om> wrote:
> > > > > > > 
> > > > > > > > I'm all for this but I don't know anything about
> > > > > > > > markdown. 
> > > > > > > > 
> > > > > > > > What's the best way to proceed?
> > > > > > > > 
> > > > > > > > -Filip
> > > > > > > > 
> > > > > > > > On Jan 28, 2016, at 9:24 PM, Timothy Hatcher  > > > > > > > pple.com> wrote:
> > > > > > > > 
> > > > > > > > > They should be markdown files like we do for the code
> > > > > > > > > style and policy documents.
> > > > > > > > >

Re: [webkit-dev] Some text about the B3 compiler

[Carlos Garcia Campos]

El sáb, 30-01-2016 a las 20:16 -0800, Filip Pizlo escribió:
> Michael,
> 
> As my original message said, I was wondering if there was any support
> for running some JavaScript tests *in browser*.  run-jsc-stress-tests 
> doesn’t support that because it doesn’t know what a browser is.
> 
> Some tests, like Kraken, Octane, JetStream, and Speedometer, either
> require a browser to run (like JetStream and Speedometer) or have
> significantly different behavior in the browser than in their
> command-line harnesses (like Kraken and Octane).  If you did have a
> bot that ran these tests in some GTK+ or EFL browser, you’d probably
> catch bugs that testing the JSC shell cannot catch.

We should definitely do that. We are quite late already in our release
cycle, so if we are going to switch to B3 at this point, we really need
a lot more testing. 

> -Filip
> 
> 
> > On Jan 30, 2016, at 7:50 PM, Michael Catanzaro  > om> wrote:
> > 
> > On Sat, 2016-01-30 at 16:06 -0800, Filip Pizło wrote:
> > > Do we have Linux bots that run Octane, Speedometer, JetStream and
> > > Kraken in browser?
> > > 
> > > We find that this catches a lot of bugs that none of the other
> > > tests
> > > catch. 
> > > 
> > > -Filip
> > 
> > This is the command that the bots run:
> > 
> > /usr/bin/env ruby Tools/Scripts/run-jsc-stress-tests -j
> > /home/slave/webkitgtk/gtk-linux-64-release-
> > tests/build/WebKitBuild/Release/bin/jsc -o
> > /home/slave/webkitgtk/gtk-
> > linux-64-release-tests/build/WebKitBuild/Release/bin/jsc-stress-
> > results 
> > PerformanceTests/SunSpider/tests/sunspider-1.0
> > PerformanceTests/JetStream/cdjs/cdjs-tests.yaml
> > Source/JavaScriptCore/tests/executableAllocationFuzz.yaml
> > Source/JavaScriptCore/tests/exceptionFuzz.yaml
> > PerformanceTests/SunSpider/no-architecture-specific-
> > optimizations.yaml
> > PerformanceTests/SunSpider/tests/v8-v6
> > Source/JavaScriptCore/tests/mozilla/mozilla-tests.yaml
> > Source/JavaScriptCore/tests/stress LayoutTests/js/regress/script-
> > tests
> > PerformanceTests/SunSpider/profiler-test.yaml LayoutTests/jsc-
> > layout-
> > tests.yaml Source/JavaScriptCore/tests/typeProfiler.yaml
> > Source/JavaScriptCore/tests/controlFlowProfiler.yaml
> > Source/JavaScriptCore/tests/es6.yaml
> > Source/JavaScriptCore/tests/modules.yaml --ftl-jit --
> > 
> > I see SunSpider and JetStream in there, but not the others
> > 
> > Michael
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Filip Pizlo]

Michael,

As my original message said, I was wondering if there was any support for 
running some JavaScript tests *in browser*.  run-jsc-stress-tests doesn’t 
support that because it doesn’t know what a browser is.

Some tests, like Kraken, Octane, JetStream, and Speedometer, either require a 
browser to run (like JetStream and Speedometer) or have significantly different 
behavior in the browser than in their command-line harnesses (like Kraken and 
Octane).  If you did have a bot that ran these tests in some GTK+ or EFL 
browser, you’d probably catch bugs that testing the JSC shell cannot catch.

-Filip


> On Jan 30, 2016, at 7:50 PM, Michael Catanzaro  wrote:
> 
> On Sat, 2016-01-30 at 16:06 -0800, Filip Pizło wrote:
>> Do we have Linux bots that run Octane, Speedometer, JetStream and
>> Kraken in browser?
>> 
>> We find that this catches a lot of bugs that none of the other tests
>> catch. 
>> 
>> -Filip
> 
> This is the command that the bots run:
> 
> /usr/bin/env ruby Tools/Scripts/run-jsc-stress-tests -j
> /home/slave/webkitgtk/gtk-linux-64-release-
> tests/build/WebKitBuild/Release/bin/jsc -o /home/slave/webkitgtk/gtk-
> linux-64-release-tests/build/WebKitBuild/Release/bin/jsc-stress-results 
> PerformanceTests/SunSpider/tests/sunspider-1.0
> PerformanceTests/JetStream/cdjs/cdjs-tests.yaml
> Source/JavaScriptCore/tests/executableAllocationFuzz.yaml
> Source/JavaScriptCore/tests/exceptionFuzz.yaml
> PerformanceTests/SunSpider/no-architecture-specific-optimizations.yaml
> PerformanceTests/SunSpider/tests/v8-v6
> Source/JavaScriptCore/tests/mozilla/mozilla-tests.yaml
> Source/JavaScriptCore/tests/stress LayoutTests/js/regress/script-tests
> PerformanceTests/SunSpider/profiler-test.yaml LayoutTests/jsc-layout-
> tests.yaml Source/JavaScriptCore/tests/typeProfiler.yaml
> Source/JavaScriptCore/tests/controlFlowProfiler.yaml
> Source/JavaScriptCore/tests/es6.yaml
> Source/JavaScriptCore/tests/modules.yaml --ftl-jit --
> 
> I see SunSpider and JetStream in there, but not the others
> 
> Michael

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Michael Catanzaro]

On Sat, 2016-01-30 at 16:06 -0800, Filip Pizło wrote:
> Do we have Linux bots that run Octane, Speedometer, JetStream and
> Kraken in browser?
> 
> We find that this catches a lot of bugs that none of the other tests
> catch. 
> 
> -Filip

This is the command that the bots run:

/usr/bin/env ruby Tools/Scripts/run-jsc-stress-tests -j
/home/slave/webkitgtk/gtk-linux-64-release-
tests/build/WebKitBuild/Release/bin/jsc -o /home/slave/webkitgtk/gtk-
linux-64-release-tests/build/WebKitBuild/Release/bin/jsc-stress-results 
PerformanceTests/SunSpider/tests/sunspider-1.0
PerformanceTests/JetStream/cdjs/cdjs-tests.yaml
Source/JavaScriptCore/tests/executableAllocationFuzz.yaml
Source/JavaScriptCore/tests/exceptionFuzz.yaml
PerformanceTests/SunSpider/no-architecture-specific-optimizations.yaml
PerformanceTests/SunSpider/tests/v8-v6
Source/JavaScriptCore/tests/mozilla/mozilla-tests.yaml
Source/JavaScriptCore/tests/stress LayoutTests/js/regress/script-tests
PerformanceTests/SunSpider/profiler-test.yaml LayoutTests/jsc-layout-
tests.yaml Source/JavaScriptCore/tests/typeProfiler.yaml
Source/JavaScriptCore/tests/controlFlowProfiler.yaml
Source/JavaScriptCore/tests/es6.yaml
Source/JavaScriptCore/tests/modules.yaml --ftl-jit --

I see SunSpider and JetStream in there, but not the others

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Michael Catanzaro]

On Sat, 2016-01-30 at 16:06 -0800, Filip Pizło wrote:
> Do we have Linux bots that run Octane, Speedometer, JetStream and
> Kraken in browser?
> 
> We find that this catches a lot of bugs that none of the other tests
> catch. 
> 
> -Filip

I would assume it just executes 'run-jsc-tests'.

I didn't realize Apple was running tests not covered in run-jsc-tests.
It would be good to improve this.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Filip Pizło]

> On Jan 30, 2016, at 3:16 PM, Michael Catanzaro  wrote:
> 
>> On Sat, 2016-01-30 at 14:13 -0800, Filip Pizło wrote:
>> That's so awesome!  I can't wait to see it enabled on Linux!
>> 
>> The gcc-clang differences suggest that we will need to be extra
>> careful now. I'd like to see more Linux testing of JSC. 
>> 
>> -Filip
> 
> Hi,
> 
> We have two bots that run the JSC tests with GCC (our major
> distributors all use GCC). The JSC tests break regularly, but the
> failures are usually cross-platform and so get fixed fairly quickly. If
> there are any JSC failures, they show up here:
> 
> https://build.webkit.org/dashboard/
> 
> Currently all the JSC tests are passing (running FTL with LLVM).
> 
> It would be very nice if the EWS were to run GTK tests (without
> blocking commit-queue) so that developers can notice failures
> immediately. Otherwise, I don't see room for improvement here.

Do we have Linux bots that run Octane, Speedometer, JetStream and Kraken in 
browser?

We find that this catches a lot of bugs that none of the other tests catch. 

-Filip

> 
> Michael
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Yusuke SUZUKI]

On Sun, Jan 31, 2016 at 8:36 AM, Michael Catanzaro 
wrote:
>
> I thought we could remove all the LLVM goo from the CMake build system,
> but I see there is some code to support LLVM for the EFL port on
> AArch64. (For the GTK port, FTL is only supported on x86_64).
>
> Do we want to continue to support FTL on AArch64 using LLVM, or do we
> want to just turn off FTL on that platform until B3 is ready? It's
> currently disabled by default, so I don't see much value in keeping it
> around.
>

As one of Linux JSC developer, turning off FTL on AArch64 right now and
enable it when B3 is ready is preferable to me.
It drops LLVM dependencies.


>
> Michael
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Michael Catanzaro]

On Sun, 2016-01-31 at 06:00 +0900, Yusuke SUZUKI wrote:
> Now, https://bugs.webkit.org/show_bug.cgi?id=153647 and
> https://bugs.webkit.org/show_bug.cgi?id=153711 are landed.
> 
> So, now, in GTK Linux x64 port, all the JSC tests pass! I think it's
> time
> to enable B3 in Linux x64 :D
> 
> Regards,
> Yusuke Suzuki

Let's turn this on. :)

I thought we could remove all the LLVM goo from the CMake build system,
but I see there is some code to support LLVM for the EFL port on
AArch64. (For the GTK port, FTL is only supported on x86_64).

Do we want to continue to support FTL on AArch64 using LLVM, or do we
want to just turn off FTL on that platform until B3 is ready? It's
currently disabled by default, so I don't see much value in keeping it
around.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Michael Catanzaro]

On Sat, 2016-01-30 at 14:13 -0800, Filip Pizło wrote:
> That's so awesome!  I can't wait to see it enabled on Linux!
> 
> The gcc-clang differences suggest that we will need to be extra
> careful now. I'd like to see more Linux testing of JSC. 
> 
> -Filip

Hi,

We have two bots that run the JSC tests with GCC (our major
distributors all use GCC). The JSC tests break regularly, but the
failures are usually cross-platform and so get fixed fairly quickly. If
there are any JSC failures, they show up here:

https://build.webkit.org/dashboard/

Currently all the JSC tests are passing (running FTL with LLVM).

It would be very nice if the EWS were to run GTK tests (without
blocking commit-queue) so that developers can notice failures
immediately. Otherwise, I don't see room for improvement here.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Filip Pizło]

That's so awesome!  I can't wait to see it enabled on Linux!

The gcc-clang differences suggest that we will need to be extra careful now. 
I'd like to see more Linux testing of JSC. 

-Filip

> On Jan 30, 2016, at 1:00 PM, Yusuke SUZUKI  wrote:
> 
> Now, https://bugs.webkit.org/show_bug.cgi?id=153647 and 
> https://bugs.webkit.org/show_bug.cgi?id=153711 are landed.
> 
> So, now, in GTK Linux x64 port, all the JSC tests pass! I think it's time to 
> enable B3 in Linux x64 :D
> 
> Regards,
> Yusuke Suzuki
> 
>> On Sat, Jan 30, 2016 at 8:09 AM, Filip Pizlo  wrote:
>> Follow up on this:
>> 
>>> On Jan 29, 2016, at 11:38 AM, Filip Pizlo  wrote:
>>> 
>>> I started coverting the documentation to Markdown.  I don’t think this is a 
>>> good idea.
>>> 
>>> - Markdown has no definition lists.  The entire IR document is a definition 
>>> list.  I don’t want B3’s documentation to be blocked on this issue.
>> 
>> It turns out that it does have them, but they are very weak.  For example, 
>> you can’t have code blocks or paragraphs inside them.  We want to have code 
>> blocks inside opcode definitions, to show examples.
>> 
>>> - Markdown’s conversion step makes the workflow awkward.  I’m not going to 
>>> use some Markdown editing app - that will prevent me from being able to 
>>> properly format code examples.  I need a code editor for that.
>> 
>> This was hard to get around.  This isn’t a problem with Markdown, but 
>> rather, a problem with using Wordpress to render Markdown that is in svn.  
>> There is no way to preview the Markdown before committing it.  That would 
>> lead to unusual problems, where after a patch is landed, the patch author or 
>> someone else would have to do a bunch of blind follow-up commits to fix any 
>> style issues, like code blocks that don’t fit properly or whatever.
>> 
>> Considering that we will have to be hacking raw HTML inside those Markdown 
>> files (due to definition lists), the lack of preview basically means that 
>> you have no way of predicting what the your HTML will render like.
>> 
>>> 
>>> I think that this documentation should be HTML.  I don’t think we should 
>>> expend a lot of energy to formatting it nicely.  The point of this document 
>>> is for it to be read by engineers while they hack code.
>> 
>> I landed raw HTML documentation: http://trac.webkit.org/changeset/195841
>> 
>> I filed this bug about improving its style: 
>> https://bugs.webkit.org/show_bug.cgi?id=153674
>> 
>> -Filip
>> 
>> 
>>> 
>>> -Filip
>>> 
>>> 
 On Jan 29, 2016, at 10:12 AM, Timothy Hatcher  wrote:
 
 I also added:
 
 https://webkit.org/documentation/b3/air/ loads 
 /docs/b3/assembly-intermediate-representation.md
 
> On Jan 29, 2016, at 10:05 AM, Filip Pizło  wrote:
> 
> Thank you!  I'll convert them today. 
> 
> -Filip
> 
>> On Jan 29, 2016, at 10:02 AM, Timothy Hatcher  wrote:
>> 
>> Markdown is pretty similar to the wiki formatting and very simple.
>> 
>> You can look at a cheatsheet if you login to the blog: 
>> https://webkit.org/wp/wp-admin/post.php?post=4300&action=edit
>> 
>> I have also used this HTML to Markdown converter before: 
>> http://domchristie.github.io/to-markdown/
>> 
>> The pages are created:
>> 
>> https://webkit.org/documentation/b3/ loads /docs/b3/bare-bones-backend.md
>> https://webkit.org/documentation/b3/intermediate-representation/ loads 
>> /docs/b3/intermediate-representation.md
>> 
>> Once those files are added to SVN, they will get picked up by the site. 
>> I can change those to point to other names if you want something 
>> different.
>> 
>> — Timothy Hatcher
>> 
>>> On Jan 29, 2016, at 9:34 AM, saam barati  wrote:
>>> 
>>> I'm happy to convert the document to markdown. Can you send me your 
>>> latest revision or post it to the website?
>>> 
>>> I usually look at:
>>> http://daringfireball.net/projects/markdown/syntax
>>> For a refresher on the syntax.
>>> 
>>> Tim, could you create a page that loads the markdown file?
>>> 
>>> Thanks,
>>> Saam
>>> 
 On Jan 29, 2016, at 12:06 AM, Filip Pizło  wrote:
 
 I'm all for this but I don't know anything about markdown. 
 
 What's the best way to proceed?
 
 -Filip
 
> On Jan 28, 2016, at 9:24 PM, Timothy Hatcher  
> wrote:
> 
> They should be markdown files like we do for the code style and 
> policy documents.
> 
> https://trac.webkit.org/browser/trunk/Websites/webkit.org/code-style.md
> 
> We can then make Wordpress pages on the site that load the markdown.
> 
> Maybe put them in a /docs/b3/ directory?
> 
> — Timothy Hatcher
> 
>> On Jan 28, 2016, at 4:48 PM, Filip Pizlo  wrote:
>> 
>> I guess we could put it in Websi

Re: [webkit-dev] Some text about the B3 compiler

[Yusuke SUZUKI]

Now, https://bugs.webkit.org/show_bug.cgi?id=153647 and
https://bugs.webkit.org/show_bug.cgi?id=153711 are landed.

So, now, in GTK Linux x64 port, all the JSC tests pass! I think it's time
to enable B3 in Linux x64 :D

Regards,
Yusuke Suzuki

On Sat, Jan 30, 2016 at 8:09 AM, Filip Pizlo  wrote:

> Follow up on this:
>
> On Jan 29, 2016, at 11:38 AM, Filip Pizlo  wrote:
>
> I started coverting the documentation to Markdown.  I don’t think this is
> a good idea.
>
> - Markdown has no definition lists.  The entire IR document is a
> definition list.  I don’t want B3’s documentation to be blocked on this
> issue.
>
>
> It turns out that it does have them, but they are very weak.  For example,
> you can’t have code blocks or paragraphs inside them.  We want to have code
> blocks inside opcode definitions, to show examples.
>
> - Markdown’s conversion step makes the workflow awkward.  I’m not going to
> use some Markdown editing app - that will prevent me from being able to
> properly format code examples.  I need a code editor for that.
>
>
> This was hard to get around.  This isn’t a problem with Markdown, but
> rather, a problem with using Wordpress to render Markdown that is in svn.
> There is no way to preview the Markdown before committing it.  That would
> lead to unusual problems, where after a patch is landed, the patch author
> or someone else would have to do a bunch of blind follow-up commits to fix
> any style issues, like code blocks that don’t fit properly or whatever.
>
> Considering that we will have to be hacking raw HTML inside those Markdown
> files (due to definition lists), the lack of preview basically means that
> you have no way of predicting what the your HTML will render like.
>
>
> I think that this documentation should be HTML.  I don’t think we should
> expend a lot of energy to formatting it nicely.  The point of this document
> is for it to be read by engineers while they hack code.
>
>
> I landed raw HTML documentation: http://trac.webkit.org/changeset/195841
>
> I filed this bug about improving its style:
> https://bugs.webkit.org/show_bug.cgi?id=153674
>
> -Filip
>
>
>
> -Filip
>
>
> On Jan 29, 2016, at 10:12 AM, Timothy Hatcher  wrote:
>
> I also added:
>
> https://webkit.org/documentation/b3/air/ loads /docs/b3/
> assembly-intermediate-representation.md
>
> On Jan 29, 2016, at 10:05 AM, Filip Pizło  wrote:
>
> Thank you!  I'll convert them today.
>
> -Filip
>
> On Jan 29, 2016, at 10:02 AM, Timothy Hatcher  wrote:
>
> Markdown is pretty similar to the wiki formatting and very simple.
>
> You can look at a cheatsheet if you login to the blog:
> https://webkit.org/wp/wp-admin/post.php?post=4300&action=edit
>
> I have also used this HTML to Markdown converter before:
> http://domchristie.github.io/to-markdown/
>
> The pages are created:
>
> https://webkit.org/documentation/b3/ loads /docs/b3/bare-bones-backend.md
> https://webkit.org/documentation/b3/intermediate-representation/ loads
> /docs/b3/intermediate-representation.md
>
> Once those files are added to SVN, they will get picked up by the site. I
> can change those to point to other names if you want something different.
>
> — Timothy Hatcher
>
> On Jan 29, 2016, at 9:34 AM, saam barati  wrote:
>
> I'm happy to convert the document to markdown. Can you send me your latest
> revision or post it to the website?
>
> I usually look at:
> http://daringfireball.net/projects/markdown/syntax
> For a refresher on the syntax.
>
> Tim, could you create a page that loads the markdown file?
>
> Thanks,
> Saam
>
> On Jan 29, 2016, at 12:06 AM, Filip Pizło  wrote:
>
> I'm all for this but I don't know anything about markdown.
>
> What's the best way to proceed?
>
> -Filip
>
> On Jan 28, 2016, at 9:24 PM, Timothy Hatcher  wrote:
>
> They should be markdown files like we do for the code style and policy
> documents.
>
> https://trac.webkit.org/browser/trunk/Websites/webkit.org/code-style.md
>
> We can then make Wordpress pages on the site that load the markdown.
>
> Maybe put them in a /docs/b3/ directory?
>
> — Timothy Hatcher
>
> On Jan 28, 2016, at 4:48 PM, Filip Pizlo  wrote:
>
> I guess we could put it in Websites/webkit.org/b3.  Then patches could
> edit both B3 and the documentation in one go, and the documentation would
> go live when it’s committed.
>
> Does anyone object to this?
>
> -Filip
>
>
> On Jan 28, 2016, at 4:39 PM, Saam barati  wrote:
>
> Yeah. That’d be the easiest way to keep it up IMO.
>
> Saam
>
> On Jan 28, 2016, at 4:37 PM, Filip Pizło  wrote:
>
> +1
>
> Do you think we should move the documentation to a file in svn so that it
> can be reviewed as part of patch review?
>
> -Filip
>
> On Jan 28, 2016, at 4:32 PM, Saam barati  wrote:
>
> This is great. Thanks Fil.
>
> I propose that we do all that we can to keep this updated.
> I suggest that all patches that change to the IR should also include with
> it
> a change to the documentation, and that reviewers should require this.
>
> It’d also be great if other signif

Re: [webkit-dev] Some text about the B3 compiler

[Filip Pizlo]

Follow up on this:

> On Jan 29, 2016, at 11:38 AM, Filip Pizlo  wrote:
> 
> I started coverting the documentation to Markdown.  I don’t think this is a 
> good idea.
> 
> - Markdown has no definition lists.  The entire IR document is a definition 
> list.  I don’t want B3’s documentation to be blocked on this issue.

It turns out that it does have them, but they are very weak.  For example, you 
can’t have code blocks or paragraphs inside them.  We want to have code blocks 
inside opcode definitions, to show examples.

> - Markdown’s conversion step makes the workflow awkward.  I’m not going to 
> use some Markdown editing app - that will prevent me from being able to 
> properly format code examples.  I need a code editor for that.

This was hard to get around.  This isn’t a problem with Markdown, but rather, a 
problem with using Wordpress to render Markdown that is in svn.  There is no 
way to preview the Markdown before committing it.  That would lead to unusual 
problems, where after a patch is landed, the patch author or someone else would 
have to do a bunch of blind follow-up commits to fix any style issues, like 
code blocks that don’t fit properly or whatever.

Considering that we will have to be hacking raw HTML inside those Markdown 
files (due to definition lists), the lack of preview basically means that you 
have no way of predicting what the your HTML will render like.

> 
> I think that this documentation should be HTML.  I don’t think we should 
> expend a lot of energy to formatting it nicely.  The point of this document 
> is for it to be read by engineers while they hack code.

I landed raw HTML documentation: http://trac.webkit.org/changeset/195841 


I filed this bug about improving its style: 
https://bugs.webkit.org/show_bug.cgi?id=153674 


-Filip


> 
> -Filip
> 
> 
>> On Jan 29, 2016, at 10:12 AM, Timothy Hatcher > > wrote:
>> 
>> I also added:
>> 
>> https://webkit.org/documentation/b3/air/ 
>>  loads 
>> /docs/b3/assembly-intermediate-representation.md
>> 
>>> On Jan 29, 2016, at 10:05 AM, Filip Pizło >> > wrote:
>>> 
>>> Thank you!  I'll convert them today. 
>>> 
>>> -Filip
>>> 
>>> On Jan 29, 2016, at 10:02 AM, Timothy Hatcher >> > wrote:
>>> 
 Markdown is pretty similar to the wiki formatting and very simple.
 
 You can look at a cheatsheet if you login to the blog: 
 https://webkit.org/wp/wp-admin/post.php?post=4300&action=edit 
 
 
 I have also used this HTML to Markdown converter before: 
 http://domchristie.github.io/to-markdown/ 
 
 
 The pages are created:
 
 https://webkit.org/documentation/b3/ 
  loads /docs/b3/bare-bones-backend.md
 https://webkit.org/documentation/b3/intermediate-representation/ 
  loads 
 /docs/b3/intermediate-representation.md
 
 Once those files are added to SVN, they will get picked up by the site. I 
 can change those to point to other names if you want something different.
 
 — Timothy Hatcher
 
> On Jan 29, 2016, at 9:34 AM, saam barati  > wrote:
> 
> I'm happy to convert the document to markdown. Can you send me your 
> latest revision or post it to the website?
> 
> I usually look at:
> http://daringfireball.net/projects/markdown/syntax 
> 
> For a refresher on the syntax.
> 
> Tim, could you create a page that loads the markdown file?
> 
> Thanks,
> Saam
> 
> On Jan 29, 2016, at 12:06 AM, Filip Pizło  > wrote:
> 
>> I'm all for this but I don't know anything about markdown. 
>> 
>> What's the best way to proceed?
>> 
>> -Filip
>> 
>> On Jan 28, 2016, at 9:24 PM, Timothy Hatcher > > wrote:
>> 
>>> They should be markdown files like we do for the code style and policy 
>>> documents.
>>> 
>>> https://trac.webkit.org/browser/trunk/Websites/webkit.org/code-style.md 
>>> 
>>> 
>>> We can then make Wordpress pages on the site that load the markdown.
>>> 
>>> Maybe put them in a /docs/b3/ directory?
>>> 
>>> — Timothy Hatcher
>>> 
>>> On Jan 28, 2016, at 4:48 PM, Filip Pizlo >> > wrote:
>>> 
 I guess we could put it in Websites/webkit.org/b3 
 .  Then patches could edit both B3 and the 
 documentation i

Re: [webkit-dev] Some text about the B3 compiler

[Filip Pizlo]

I started coverting the documentation to Markdown.  I don’t think this is a 
good idea.

- Markdown has no definition lists.  The entire IR document is a definition 
list.  I don’t want B3’s documentation to be blocked on this issue.
- Markdown’s conversion step makes the workflow awkward.  I’m not going to use 
some Markdown editing app - that will prevent me from being able to properly 
format code examples.  I need a code editor for that.

I think that this documentation should be HTML.  I don’t think we should expend 
a lot of energy to formatting it nicely.  The point of this document is for it 
to be read by engineers while they hack code.

-Filip


> On Jan 29, 2016, at 10:12 AM, Timothy Hatcher  wrote:
> 
> I also added:
> 
> https://webkit.org/documentation/b3/air/ 
>  loads 
> /docs/b3/assembly-intermediate-representation.md
> 
>> On Jan 29, 2016, at 10:05 AM, Filip Pizło > > wrote:
>> 
>> Thank you!  I'll convert them today. 
>> 
>> -Filip
>> 
>> On Jan 29, 2016, at 10:02 AM, Timothy Hatcher > > wrote:
>> 
>>> Markdown is pretty similar to the wiki formatting and very simple.
>>> 
>>> You can look at a cheatsheet if you login to the blog: 
>>> https://webkit.org/wp/wp-admin/post.php?post=4300&action=edit 
>>> 
>>> 
>>> I have also used this HTML to Markdown converter before: 
>>> http://domchristie.github.io/to-markdown/ 
>>> 
>>> 
>>> The pages are created:
>>> 
>>> https://webkit.org/documentation/b3/  
>>> loads /docs/b3/bare-bones-backend.md
>>> https://webkit.org/documentation/b3/intermediate-representation/ 
>>>  loads 
>>> /docs/b3/intermediate-representation.md
>>> 
>>> Once those files are added to SVN, they will get picked up by the site. I 
>>> can change those to point to other names if you want something different.
>>> 
>>> — Timothy Hatcher
>>> 
 On Jan 29, 2016, at 9:34 AM, saam barati >>> > wrote:
 
 I'm happy to convert the document to markdown. Can you send me your latest 
 revision or post it to the website?
 
 I usually look at:
 http://daringfireball.net/projects/markdown/syntax 
 
 For a refresher on the syntax.
 
 Tim, could you create a page that loads the markdown file?
 
 Thanks,
 Saam
 
 On Jan 29, 2016, at 12:06 AM, Filip Pizło >>> > wrote:
 
> I'm all for this but I don't know anything about markdown. 
> 
> What's the best way to proceed?
> 
> -Filip
> 
> On Jan 28, 2016, at 9:24 PM, Timothy Hatcher  > wrote:
> 
>> They should be markdown files like we do for the code style and policy 
>> documents.
>> 
>> https://trac.webkit.org/browser/trunk/Websites/webkit.org/code-style.md 
>> 
>> 
>> We can then make Wordpress pages on the site that load the markdown.
>> 
>> Maybe put them in a /docs/b3/ directory?
>> 
>> — Timothy Hatcher
>> 
>> On Jan 28, 2016, at 4:48 PM, Filip Pizlo > > wrote:
>> 
>>> I guess we could put it in Websites/webkit.org/b3 
>>> .  Then patches could edit both B3 and the 
>>> documentation in one go, and the documentation would go live when it’s 
>>> committed.
>>> 
>>> Does anyone object to this?
>>> 
>>> -Filip
>>> 
>>> 
 On Jan 28, 2016, at 4:39 PM, Saam barati >>> > wrote:
 
 Yeah. That’d be the easiest way to keep it up IMO.
 
 Saam
 
> On Jan 28, 2016, at 4:37 PM, Filip Pizło  > wrote:
> 
> +1
> 
> Do you think we should move the documentation to a file in svn so 
> that it can be reviewed as part of patch review?
> 
> -Filip
> 
> On Jan 28, 2016, at 4:32 PM, Saam barati  > wrote:
> 
>> This is great. Thanks Fil.
>> 
>> I propose that we do all that we can to keep this updated.
>> I suggest that all patches that change to the IR should also include 
>> with it 
>> a change to the documentation, and that reviewers should require 
>> this.
>> 
>> It’d also be great if other significant changes that seem like the 
>> deserve
>> a mention in the documentation also get added as part of patches.
>> 
>> Saam
>> 
>>> On Jan 28, 2016, at 4:23 PM, Filip Pizlo >

Re: [webkit-dev] Some text about the B3 compiler

[Timothy Hatcher]

I also added:

https://webkit.org/documentation/b3/air/ loads 
/docs/b3/assembly-intermediate-representation.md

> On Jan 29, 2016, at 10:05 AM, Filip Pizło  wrote:
> 
> Thank you!  I'll convert them today. 
> 
> -Filip
> 
> On Jan 29, 2016, at 10:02 AM, Timothy Hatcher  > wrote:
> 
>> Markdown is pretty similar to the wiki formatting and very simple.
>> 
>> You can look at a cheatsheet if you login to the blog: 
>> https://webkit.org/wp/wp-admin/post.php?post=4300&action=edit 
>> 
>> 
>> I have also used this HTML to Markdown converter before: 
>> http://domchristie.github.io/to-markdown/ 
>> 
>> 
>> The pages are created:
>> 
>> https://webkit.org/documentation/b3/  
>> loads /docs/b3/bare-bones-backend.md
>> https://webkit.org/documentation/b3/intermediate-representation/ 
>>  loads 
>> /docs/b3/intermediate-representation.md
>> 
>> Once those files are added to SVN, they will get picked up by the site. I 
>> can change those to point to other names if you want something different.
>> 
>> — Timothy Hatcher
>> 
>>> On Jan 29, 2016, at 9:34 AM, saam barati >> > wrote:
>>> 
>>> I'm happy to convert the document to markdown. Can you send me your latest 
>>> revision or post it to the website?
>>> 
>>> I usually look at:
>>> http://daringfireball.net/projects/markdown/syntax 
>>> 
>>> For a refresher on the syntax.
>>> 
>>> Tim, could you create a page that loads the markdown file?
>>> 
>>> Thanks,
>>> Saam
>>> 
>>> On Jan 29, 2016, at 12:06 AM, Filip Pizło >> > wrote:
>>> 
 I'm all for this but I don't know anything about markdown. 
 
 What's the best way to proceed?
 
 -Filip
 
 On Jan 28, 2016, at 9:24 PM, Timothy Hatcher >>> > wrote:
 
> They should be markdown files like we do for the code style and policy 
> documents.
> 
> https://trac.webkit.org/browser/trunk/Websites/webkit.org/code-style.md 
> 
> 
> We can then make Wordpress pages on the site that load the markdown.
> 
> Maybe put them in a /docs/b3/ directory?
> 
> — Timothy Hatcher
> 
> On Jan 28, 2016, at 4:48 PM, Filip Pizlo  > wrote:
> 
>> I guess we could put it in Websites/webkit.org/b3 
>> .  Then patches could edit both B3 and the 
>> documentation in one go, and the documentation would go live when it’s 
>> committed.
>> 
>> Does anyone object to this?
>> 
>> -Filip
>> 
>> 
>>> On Jan 28, 2016, at 4:39 PM, Saam barati >> > wrote:
>>> 
>>> Yeah. That’d be the easiest way to keep it up IMO.
>>> 
>>> Saam
>>> 
 On Jan 28, 2016, at 4:37 PM, Filip Pizło >>> > wrote:
 
 +1
 
 Do you think we should move the documentation to a file in svn so that 
 it can be reviewed as part of patch review?
 
 -Filip
 
 On Jan 28, 2016, at 4:32 PM, Saam barati >>> > wrote:
 
> This is great. Thanks Fil.
> 
> I propose that we do all that we can to keep this updated.
> I suggest that all patches that change to the IR should also include 
> with it 
> a change to the documentation, and that reviewers should require this.
> 
> It’d also be great if other significant changes that seem like the 
> deserve
> a mention in the documentation also get added as part of patches.
> 
> Saam
> 
>> On Jan 28, 2016, at 4:23 PM, Filip Pizlo > > wrote:
>> 
>> Hi everyone,
>> 
>> We’ve been working on a new compiler backend for the FTL JIT, which 
>> we call B3.  It stands for “Bare Bones Backend”.  We recently 
>> enabled it on X86/Mac, and we’re working hard to enable it on other 
>> platforms.
>> 
>> If you’re interested in how it works, I’ve started writing 
>> documentation.  I’ll be adding more to it soon!
>> https://trac.webkit.org/wiki/BareBonesBackend 
>> 
>> https://trac.webkit.org/wiki/B3IntermediateRepresentation 
>> 
>> 
>> -Filip
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 

Re: [webkit-dev] Some text about the B3 compiler

[Filip Pizło]

Thank you!  I'll convert them today. 

-Filip

> On Jan 29, 2016, at 10:02 AM, Timothy Hatcher  wrote:
> 
> Markdown is pretty similar to the wiki formatting and very simple.
> 
> You can look at a cheatsheet if you login to the blog: 
> https://webkit.org/wp/wp-admin/post.php?post=4300&action=edit
> 
> I have also used this HTML to Markdown converter before: 
> http://domchristie.github.io/to-markdown/
> 
> The pages are created:
> 
> https://webkit.org/documentation/b3/ loads /docs/b3/bare-bones-backend.md
> https://webkit.org/documentation/b3/intermediate-representation/ loads 
> /docs/b3/intermediate-representation.md
> 
> Once those files are added to SVN, they will get picked up by the site. I can 
> change those to point to other names if you want something different.
> 
> — Timothy Hatcher
> 
>> On Jan 29, 2016, at 9:34 AM, saam barati  wrote:
>> 
>> I'm happy to convert the document to markdown. Can you send me your latest 
>> revision or post it to the website?
>> 
>> I usually look at:
>> http://daringfireball.net/projects/markdown/syntax
>> For a refresher on the syntax.
>> 
>> Tim, could you create a page that loads the markdown file?
>> 
>> Thanks,
>> Saam
>> 
>>> On Jan 29, 2016, at 12:06 AM, Filip Pizło  wrote:
>>> 
>>> I'm all for this but I don't know anything about markdown. 
>>> 
>>> What's the best way to proceed?
>>> 
>>> -Filip
>>> 
 On Jan 28, 2016, at 9:24 PM, Timothy Hatcher  wrote:
 
 They should be markdown files like we do for the code style and policy 
 documents.
 
 https://trac.webkit.org/browser/trunk/Websites/webkit.org/code-style.md
 
 We can then make Wordpress pages on the site that load the markdown.
 
 Maybe put them in a /docs/b3/ directory?
 
 — Timothy Hatcher
 
> On Jan 28, 2016, at 4:48 PM, Filip Pizlo  wrote:
> 
> I guess we could put it in Websites/webkit.org/b3.  Then patches could 
> edit both B3 and the documentation in one go, and the documentation would 
> go live when it’s committed.
> 
> Does anyone object to this?
> 
> -Filip
> 
> 
>> On Jan 28, 2016, at 4:39 PM, Saam barati  wrote:
>> 
>> Yeah. That’d be the easiest way to keep it up IMO.
>> 
>> Saam
>> 
>>> On Jan 28, 2016, at 4:37 PM, Filip Pizło  wrote:
>>> 
>>> +1
>>> 
>>> Do you think we should move the documentation to a file in svn so that 
>>> it can be reviewed as part of patch review?
>>> 
>>> -Filip
>>> 
 On Jan 28, 2016, at 4:32 PM, Saam barati  wrote:
 
 This is great. Thanks Fil.
 
 I propose that we do all that we can to keep this updated.
 I suggest that all patches that change to the IR should also include 
 with it 
 a change to the documentation, and that reviewers should require this.
 
 It’d also be great if other significant changes that seem like the 
 deserve
 a mention in the documentation also get added as part of patches.
 
 Saam
 
> On Jan 28, 2016, at 4:23 PM, Filip Pizlo  wrote:
> 
> Hi everyone,
> 
> We’ve been working on a new compiler backend for the FTL JIT, which 
> we call B3.  It stands for “Bare Bones Backend”.  We recently enabled 
> it on X86/Mac, and we’re working hard to enable it on other platforms.
> 
> If you’re interested in how it works, I’ve started writing 
> documentation.  I’ll be adding more to it soon!
> https://trac.webkit.org/wiki/BareBonesBackend
> https://trac.webkit.org/wiki/B3IntermediateRepresentation
> 
> -Filip
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Timothy Hatcher]

Markdown is pretty similar to the wiki formatting and very simple.

You can look at a cheatsheet if you login to the blog: 
https://webkit.org/wp/wp-admin/post.php?post=4300&action=edit

I have also used this HTML to Markdown converter before: 
http://domchristie.github.io/to-markdown/

The pages are created:

https://webkit.org/documentation/b3/ loads /docs/b3/bare-bones-backend.md
https://webkit.org/documentation/b3/intermediate-representation/ loads 
/docs/b3/intermediate-representation.md

Once those files are added to SVN, they will get picked up by the site. I can 
change those to point to other names if you want something different.

— Timothy Hatcher

> On Jan 29, 2016, at 9:34 AM, saam barati  wrote:
> 
> I'm happy to convert the document to markdown. Can you send me your latest 
> revision or post it to the website?
> 
> I usually look at:
> http://daringfireball.net/projects/markdown/syntax 
> 
> For a refresher on the syntax.
> 
> Tim, could you create a page that loads the markdown file?
> 
> Thanks,
> Saam
> 
> On Jan 29, 2016, at 12:06 AM, Filip Pizło  > wrote:
> 
>> I'm all for this but I don't know anything about markdown. 
>> 
>> What's the best way to proceed?
>> 
>> -Filip
>> 
>> On Jan 28, 2016, at 9:24 PM, Timothy Hatcher > > wrote:
>> 
>>> They should be markdown files like we do for the code style and policy 
>>> documents.
>>> 
>>> https://trac.webkit.org/browser/trunk/Websites/webkit.org/code-style.md 
>>> 
>>> 
>>> We can then make Wordpress pages on the site that load the markdown.
>>> 
>>> Maybe put them in a /docs/b3/ directory?
>>> 
>>> — Timothy Hatcher
>>> 
>>> On Jan 28, 2016, at 4:48 PM, Filip Pizlo >> > wrote:
>>> 
 I guess we could put it in Websites/webkit.org/b3 .  
 Then patches could edit both B3 and the documentation in one go, and the 
 documentation would go live when it’s committed.
 
 Does anyone object to this?
 
 -Filip
 
 
> On Jan 28, 2016, at 4:39 PM, Saam barati  > wrote:
> 
> Yeah. That’d be the easiest way to keep it up IMO.
> 
> Saam
> 
>> On Jan 28, 2016, at 4:37 PM, Filip Pizło > > wrote:
>> 
>> +1
>> 
>> Do you think we should move the documentation to a file in svn so that 
>> it can be reviewed as part of patch review?
>> 
>> -Filip
>> 
>> On Jan 28, 2016, at 4:32 PM, Saam barati > > wrote:
>> 
>>> This is great. Thanks Fil.
>>> 
>>> I propose that we do all that we can to keep this updated.
>>> I suggest that all patches that change to the IR should also include 
>>> with it 
>>> a change to the documentation, and that reviewers should require this.
>>> 
>>> It’d also be great if other significant changes that seem like the 
>>> deserve
>>> a mention in the documentation also get added as part of patches.
>>> 
>>> Saam
>>> 
 On Jan 28, 2016, at 4:23 PM, Filip Pizlo >>> > wrote:
 
 Hi everyone,
 
 We’ve been working on a new compiler backend for the FTL JIT, which we 
 call B3.  It stands for “Bare Bones Backend”.  We recently enabled it 
 on X86/Mac, and we’re working hard to enable it on other platforms.
 
 If you’re interested in how it works, I’ve started writing 
 documentation.  I’ll be adding more to it soon!
 https://trac.webkit.org/wiki/BareBonesBackend 
 
 https://trac.webkit.org/wiki/B3IntermediateRepresentation 
 
 
 -Filip
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org 
 https://lists.webkit.org/mailman/listinfo/webkit-dev 
 
>>> 
> 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org 
 https://lists.webkit.org/mailman/listinfo/webkit-dev 
 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[saam barati]

I'm happy to convert the document to markdown. Can you send me your latest 
revision or post it to the website?

I usually look at:
http://daringfireball.net/projects/markdown/syntax
For a refresher on the syntax.

Tim, could you create a page that loads the markdown file?

Thanks,
Saam

> On Jan 29, 2016, at 12:06 AM, Filip Pizło  wrote:
> 
> I'm all for this but I don't know anything about markdown. 
> 
> What's the best way to proceed?
> 
> -Filip
> 
>> On Jan 28, 2016, at 9:24 PM, Timothy Hatcher  wrote:
>> 
>> They should be markdown files like we do for the code style and policy 
>> documents.
>> 
>> https://trac.webkit.org/browser/trunk/Websites/webkit.org/code-style.md
>> 
>> We can then make Wordpress pages on the site that load the markdown.
>> 
>> Maybe put them in a /docs/b3/ directory?
>> 
>> — Timothy Hatcher
>> 
>>> On Jan 28, 2016, at 4:48 PM, Filip Pizlo  wrote:
>>> 
>>> I guess we could put it in Websites/webkit.org/b3.  Then patches could edit 
>>> both B3 and the documentation in one go, and the documentation would go 
>>> live when it’s committed.
>>> 
>>> Does anyone object to this?
>>> 
>>> -Filip
>>> 
>>> 
 On Jan 28, 2016, at 4:39 PM, Saam barati  wrote:
 
 Yeah. That’d be the easiest way to keep it up IMO.
 
 Saam
 
> On Jan 28, 2016, at 4:37 PM, Filip Pizło  wrote:
> 
> +1
> 
> Do you think we should move the documentation to a file in svn so that it 
> can be reviewed as part of patch review?
> 
> -Filip
> 
>> On Jan 28, 2016, at 4:32 PM, Saam barati  wrote:
>> 
>> This is great. Thanks Fil.
>> 
>> I propose that we do all that we can to keep this updated.
>> I suggest that all patches that change to the IR should also include 
>> with it 
>> a change to the documentation, and that reviewers should require this.
>> 
>> It’d also be great if other significant changes that seem like the 
>> deserve
>> a mention in the documentation also get added as part of patches.
>> 
>> Saam
>> 
>>> On Jan 28, 2016, at 4:23 PM, Filip Pizlo  wrote:
>>> 
>>> Hi everyone,
>>> 
>>> We’ve been working on a new compiler backend for the FTL JIT, which we 
>>> call B3.  It stands for “Bare Bones Backend”.  We recently enabled it 
>>> on X86/Mac, and we’re working hard to enable it on other platforms.
>>> 
>>> If you’re interested in how it works, I’ve started writing 
>>> documentation.  I’ll be adding more to it soon!
>>> https://trac.webkit.org/wiki/BareBonesBackend
>>> https://trac.webkit.org/wiki/B3IntermediateRepresentation
>>> 
>>> -Filip
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Michael Catanzaro]

On Fri, 2016-01-29 at 13:44 +0900, Yusuke SUZUKI wrote:
> Awesome, awesome work!
> Thanks Fil and all the JSC B3 developers!
> 
> After this https://bugs.webkit.org/show_bug.cgi?id=153422 is landed,
> jsc-layout-tests.yaml/js/script-tests/array-enumerators-
> functions.js.layout-ftl-eager-no-cjit
>  is only the test failing in B3 on Linux GTK port! B3 in the other
> platforms looks approaching :D

https://bugs.webkit.org/show_bug.cgi?id=153647 looks pretty serious as
well.

Glad we're getting close though!

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Konstantin Tokarev]

29.01.2016, 03:23, "Filip Pizlo" :
> Hi everyone,
>
> We’ve been working on a new compiler backend for the FTL JIT, which we call 
> B3.  It stands for “Bare Bones Backend”.  We recently enabled it on X86/Mac, 
> and we’re working hard to enable it on other platforms.
>
> If you’re interested in how it works, I’ve started writing documentation.  
> I’ll be adding more to it soon!
> https://trac.webkit.org/wiki/BareBonesBackend
> https://trac.webkit.org/wiki/B3IntermediateRepresentation
>

Will it be feasible to port FTL/B3 to 32-bit platforms?
Thanks!

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Filip Pizło]

Context: https://trac.webkit.org/wiki/b3Discussion2015

I plan to write more on this topic soon. 

-Filip

> On Jan 28, 2016, at 11:12 PM, Stéphane Letz  wrote:
> 
> Maybe a stupid question, but what is a the rationale for this new backend? (I 
> was thinking LLVM JIT was used instead to produce machine code….)
> 
> Thanks.
> 
> Stéphane Letz
> 
>> Le 29 janv. 2016 à 01:23, Filip Pizlo  a écrit :
>> 
>> Hi everyone,
>> 
>> We’ve been working on a new compiler backend for the FTL JIT, which we call 
>> B3.  It stands for “Bare Bones Backend”.  We recently enabled it on X86/Mac, 
>> and we’re working hard to enable it on other platforms.
>> 
>> If you’re interested in how it works, I’ve started writing documentation.  
>> I’ll be adding more to it soon!
>> https://trac.webkit.org/wiki/BareBonesBackend
>> https://trac.webkit.org/wiki/B3IntermediateRepresentation
>> 
>> -Filip
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Filip Pizło]

I'm all for this but I don't know anything about markdown. 

What's the best way to proceed?

-Filip

> On Jan 28, 2016, at 9:24 PM, Timothy Hatcher  wrote:
> 
> They should be markdown files like we do for the code style and policy 
> documents.
> 
> https://trac.webkit.org/browser/trunk/Websites/webkit.org/code-style.md
> 
> We can then make Wordpress pages on the site that load the markdown.
> 
> Maybe put them in a /docs/b3/ directory?
> 
> — Timothy Hatcher
> 
>> On Jan 28, 2016, at 4:48 PM, Filip Pizlo  wrote:
>> 
>> I guess we could put it in Websites/webkit.org/b3.  Then patches could edit 
>> both B3 and the documentation in one go, and the documentation would go live 
>> when it’s committed.
>> 
>> Does anyone object to this?
>> 
>> -Filip
>> 
>> 
>>> On Jan 28, 2016, at 4:39 PM, Saam barati  wrote:
>>> 
>>> Yeah. That’d be the easiest way to keep it up IMO.
>>> 
>>> Saam
>>> 
 On Jan 28, 2016, at 4:37 PM, Filip Pizło  wrote:
 
 +1
 
 Do you think we should move the documentation to a file in svn so that it 
 can be reviewed as part of patch review?
 
 -Filip
 
> On Jan 28, 2016, at 4:32 PM, Saam barati  wrote:
> 
> This is great. Thanks Fil.
> 
> I propose that we do all that we can to keep this updated.
> I suggest that all patches that change to the IR should also include with 
> it 
> a change to the documentation, and that reviewers should require this.
> 
> It’d also be great if other significant changes that seem like the deserve
> a mention in the documentation also get added as part of patches.
> 
> Saam
> 
>> On Jan 28, 2016, at 4:23 PM, Filip Pizlo  wrote:
>> 
>> Hi everyone,
>> 
>> We’ve been working on a new compiler backend for the FTL JIT, which we 
>> call B3.  It stands for “Bare Bones Backend”.  We recently enabled it on 
>> X86/Mac, and we’re working hard to enable it on other platforms.
>> 
>> If you’re interested in how it works, I’ve started writing 
>> documentation.  I’ll be adding more to it soon!
>> https://trac.webkit.org/wiki/BareBonesBackend
>> https://trac.webkit.org/wiki/B3IntermediateRepresentation
>> 
>> -Filip
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Stéphane Letz]

Maybe a stupid question, but what is a the rationale for this new backend? (I 
was thinking LLVM JIT was used instead to produce machine code….)

Thanks.

Stéphane Letz

Le 29 janv. 2016 à 01:23, Filip Pizlo  a écrit :

> Hi everyone,
> 
> We’ve been working on a new compiler backend for the FTL JIT, which we call 
> B3.  It stands for “Bare Bones Backend”.  We recently enabled it on X86/Mac, 
> and we’re working hard to enable it on other platforms.
> 
> If you’re interested in how it works, I’ve started writing documentation.  
> I’ll be adding more to it soon!
> https://trac.webkit.org/wiki/BareBonesBackend
> https://trac.webkit.org/wiki/B3IntermediateRepresentation
> 
> -Filip
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Timothy Hatcher]

They should be markdown files like we do for the code style and policy 
documents.

https://trac.webkit.org/browser/trunk/Websites/webkit.org/code-style.md

We can then make Wordpress pages on the site that load the markdown.

Maybe put them in a /docs/b3/ directory?

— Timothy Hatcher

> On Jan 28, 2016, at 4:48 PM, Filip Pizlo  wrote:
> 
> I guess we could put it in Websites/webkit.org/b3.  Then patches could edit 
> both B3 and the documentation in one go, and the documentation would go live 
> when it’s committed.
> 
> Does anyone object to this?
> 
> -Filip
> 
> 
>> On Jan 28, 2016, at 4:39 PM, Saam barati  wrote:
>> 
>> Yeah. That’d be the easiest way to keep it up IMO.
>> 
>> Saam
>> 
>>> On Jan 28, 2016, at 4:37 PM, Filip Pizło  wrote:
>>> 
>>> +1
>>> 
>>> Do you think we should move the documentation to a file in svn so that it 
>>> can be reviewed as part of patch review?
>>> 
>>> -Filip
>>> 
 On Jan 28, 2016, at 4:32 PM, Saam barati  wrote:
 
 This is great. Thanks Fil.
 
 I propose that we do all that we can to keep this updated.
 I suggest that all patches that change to the IR should also include with 
 it 
 a change to the documentation, and that reviewers should require this.
 
 It’d also be great if other significant changes that seem like the deserve
 a mention in the documentation also get added as part of patches.
 
 Saam
 
> On Jan 28, 2016, at 4:23 PM, Filip Pizlo  wrote:
> 
> Hi everyone,
> 
> We’ve been working on a new compiler backend for the FTL JIT, which we 
> call B3.  It stands for “Bare Bones Backend”.  We recently enabled it on 
> X86/Mac, and we’re working hard to enable it on other platforms.
> 
> If you’re interested in how it works, I’ve started writing documentation. 
>  I’ll be adding more to it soon!
> https://trac.webkit.org/wiki/BareBonesBackend
> https://trac.webkit.org/wiki/B3IntermediateRepresentation
> 
> -Filip
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Yusuke SUZUKI]

Awesome, awesome work!
Thanks Fil and all the JSC B3 developers!

After this https://bugs.webkit.org/show_bug.cgi?id=153422 is landed,
jsc-layout-tests.yaml/js/script-tests/array-enumerators-functions.js.layout-ftl-eager-no-cjit
 is only the test failing in B3 on Linux GTK port! B3 in the other
platforms looks approaching :D

Regards,
Yusuke Suzuki

On Fri, Jan 29, 2016 at 9:49 AM, Andy Estes  wrote:

> I was just going to suggest something similar! 👍
>
> Andy
>
> On Jan 28, 2016, at 4:48 PM, Filip Pizlo  wrote:
>
> I guess we could put it in Websites/webkit.org/b3.  Then patches could
> edit both B3 and the documentation in one go, and the documentation would
> go live when it’s committed.
>
> Does anyone object to this?
>
> -Filip
>
>
> On Jan 28, 2016, at 4:39 PM, Saam barati  wrote:
>
> Yeah. That’d be the easiest way to keep it up IMO.
>
> Saam
>
> On Jan 28, 2016, at 4:37 PM, Filip Pizło  wrote:
>
> +1
>
> Do you think we should move the documentation to a file in svn so that it
> can be reviewed as part of patch review?
>
> -Filip
>
> On Jan 28, 2016, at 4:32 PM, Saam barati  wrote:
>
> This is great. Thanks Fil.
>
> I propose that we do all that we can to keep this updated.
> I suggest that all patches that change to the IR should also include with
> it
> a change to the documentation, and that reviewers should require this.
>
> It’d also be great if other significant changes that seem like the deserve
> a mention in the documentation also get added as part of patches.
>
> Saam
>
> On Jan 28, 2016, at 4:23 PM, Filip Pizlo  wrote:
>
> Hi everyone,
>
> We’ve been working on a new compiler backend for the FTL JIT, which we
> call B3.  It stands for “Bare Bones Backend”.  We recently enabled it on
> X86/Mac, and we’re working hard to enable it on other platforms.
>
> If you’re interested in how it works, I’ve started writing documentation.
> I’ll be adding more to it soon!
> https://trac.webkit.org/wiki/BareBonesBackend
> https://trac.webkit.org/wiki/B3IntermediateRepresentation
>
> -Filip
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Andy Estes]

I was just going to suggest something similar! 👍

Andy

> On Jan 28, 2016, at 4:48 PM, Filip Pizlo  wrote:
> 
> I guess we could put it in Websites/webkit.org/b3 .  
> Then patches could edit both B3 and the documentation in one go, and the 
> documentation would go live when it’s committed.
> 
> Does anyone object to this?
> 
> -Filip
> 
> 
>> On Jan 28, 2016, at 4:39 PM, Saam barati > > wrote:
>> 
>> Yeah. That’d be the easiest way to keep it up IMO.
>> 
>> Saam
>> 
>>> On Jan 28, 2016, at 4:37 PM, Filip Pizło >> > wrote:
>>> 
>>> +1
>>> 
>>> Do you think we should move the documentation to a file in svn so that it 
>>> can be reviewed as part of patch review?
>>> 
>>> -Filip
>>> 
>>> On Jan 28, 2016, at 4:32 PM, Saam barati >> > wrote:
>>> 
 This is great. Thanks Fil.
 
 I propose that we do all that we can to keep this updated.
 I suggest that all patches that change to the IR should also include with 
 it 
 a change to the documentation, and that reviewers should require this.
 
 It’d also be great if other significant changes that seem like the deserve
 a mention in the documentation also get added as part of patches.
 
 Saam
 
> On Jan 28, 2016, at 4:23 PM, Filip Pizlo  > wrote:
> 
> Hi everyone,
> 
> We’ve been working on a new compiler backend for the FTL JIT, which we 
> call B3.  It stands for “Bare Bones Backend”.  We recently enabled it on 
> X86/Mac, and we’re working hard to enable it on other platforms.
> 
> If you’re interested in how it works, I’ve started writing documentation. 
>  I’ll be adding more to it soon!
> https://trac.webkit.org/wiki/BareBonesBackend 
> 
> https://trac.webkit.org/wiki/B3IntermediateRepresentation 
> 
> 
> -Filip
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
 
>> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Filip Pizlo]

I guess we could put it in Websites/webkit.org/b3 .  Then 
patches could edit both B3 and the documentation in one go, and the 
documentation would go live when it’s committed.

Does anyone object to this?

-Filip


> On Jan 28, 2016, at 4:39 PM, Saam barati  wrote:
> 
> Yeah. That’d be the easiest way to keep it up IMO.
> 
> Saam
> 
>> On Jan 28, 2016, at 4:37 PM, Filip Pizło > > wrote:
>> 
>> +1
>> 
>> Do you think we should move the documentation to a file in svn so that it 
>> can be reviewed as part of patch review?
>> 
>> -Filip
>> 
>> On Jan 28, 2016, at 4:32 PM, Saam barati > > wrote:
>> 
>>> This is great. Thanks Fil.
>>> 
>>> I propose that we do all that we can to keep this updated.
>>> I suggest that all patches that change to the IR should also include with 
>>> it 
>>> a change to the documentation, and that reviewers should require this.
>>> 
>>> It’d also be great if other significant changes that seem like the deserve
>>> a mention in the documentation also get added as part of patches.
>>> 
>>> Saam
>>> 
 On Jan 28, 2016, at 4:23 PM, Filip Pizlo >>> > wrote:
 
 Hi everyone,
 
 We’ve been working on a new compiler backend for the FTL JIT, which we 
 call B3.  It stands for “Bare Bones Backend”.  We recently enabled it on 
 X86/Mac, and we’re working hard to enable it on other platforms.
 
 If you’re interested in how it works, I’ve started writing documentation.  
 I’ll be adding more to it soon!
 https://trac.webkit.org/wiki/BareBonesBackend 
 
 https://trac.webkit.org/wiki/B3IntermediateRepresentation 
 
 
 -Filip
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org 
 https://lists.webkit.org/mailman/listinfo/webkit-dev 
 
>>> 
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Saam barati]

Yeah. That’d be the easiest way to keep it up IMO.

Saam

> On Jan 28, 2016, at 4:37 PM, Filip Pizło  wrote:
> 
> +1
> 
> Do you think we should move the documentation to a file in svn so that it can 
> be reviewed as part of patch review?
> 
> -Filip
> 
> On Jan 28, 2016, at 4:32 PM, Saam barati  > wrote:
> 
>> This is great. Thanks Fil.
>> 
>> I propose that we do all that we can to keep this updated.
>> I suggest that all patches that change to the IR should also include with it 
>> a change to the documentation, and that reviewers should require this.
>> 
>> It’d also be great if other significant changes that seem like the deserve
>> a mention in the documentation also get added as part of patches.
>> 
>> Saam
>> 
>>> On Jan 28, 2016, at 4:23 PM, Filip Pizlo >> > wrote:
>>> 
>>> Hi everyone,
>>> 
>>> We’ve been working on a new compiler backend for the FTL JIT, which we call 
>>> B3.  It stands for “Bare Bones Backend”.  We recently enabled it on 
>>> X86/Mac, and we’re working hard to enable it on other platforms.
>>> 
>>> If you’re interested in how it works, I’ve started writing documentation.  
>>> I’ll be adding more to it soon!
>>> https://trac.webkit.org/wiki/BareBonesBackend 
>>> 
>>> https://trac.webkit.org/wiki/B3IntermediateRepresentation 
>>> 
>>> 
>>> -Filip
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org 
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>>> 
>> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Filip Pizło]

+1

Do you think we should move the documentation to a file in svn so that it can 
be reviewed as part of patch review?

-Filip

> On Jan 28, 2016, at 4:32 PM, Saam barati  wrote:
> 
> This is great. Thanks Fil.
> 
> I propose that we do all that we can to keep this updated.
> I suggest that all patches that change to the IR should also include with it 
> a change to the documentation, and that reviewers should require this.
> 
> It’d also be great if other significant changes that seem like the deserve
> a mention in the documentation also get added as part of patches.
> 
> Saam
> 
>> On Jan 28, 2016, at 4:23 PM, Filip Pizlo  wrote:
>> 
>> Hi everyone,
>> 
>> We’ve been working on a new compiler backend for the FTL JIT, which we call 
>> B3.  It stands for “Bare Bones Backend”.  We recently enabled it on X86/Mac, 
>> and we’re working hard to enable it on other platforms.
>> 
>> If you’re interested in how it works, I’ve started writing documentation.  
>> I’ll be adding more to it soon!
>> https://trac.webkit.org/wiki/BareBonesBackend
>> https://trac.webkit.org/wiki/B3IntermediateRepresentation
>> 
>> -Filip
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Saam barati]

This is great. Thanks Fil.

I propose that we do all that we can to keep this updated.
I suggest that all patches that change to the IR should also include with it 
a change to the documentation, and that reviewers should require this.

It’d also be great if other significant changes that seem like the deserve
a mention in the documentation also get added as part of patches.

Saam

> On Jan 28, 2016, at 4:23 PM, Filip Pizlo  wrote:
> 
> Hi everyone,
> 
> We’ve been working on a new compiler backend for the FTL JIT, which we call 
> B3.  It stands for “Bare Bones Backend”.  We recently enabled it on X86/Mac, 
> and we’re working hard to enable it on other platforms.
> 
> If you’re interested in how it works, I’ve started writing documentation.  
> I’ll be adding more to it soon!
> https://trac.webkit.org/wiki/BareBonesBackend 
> 
> https://trac.webkit.org/wiki/B3IntermediateRepresentation 
> 
> 
> -Filip
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Some text about the B3 compiler

[Filip Pizlo]

Hi everyone,

We’ve been working on a new compiler backend for the FTL JIT, which we call B3. 
 It stands for “Bare Bones Backend”.  We recently enabled it on X86/Mac, and 
we’re working hard to enable it on other platforms.

If you’re interested in how it works, I’ve started writing documentation.  I’ll 
be adding more to it soon!
https://trac.webkit.org/wiki/BareBonesBackend 

https://trac.webkit.org/wiki/B3IntermediateRepresentation 


-Filip

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev