User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36 Edg/107.0.1418.24

The Bugbug bot thinks this bug should belong to the 'Core::JavaScript Engine' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Can you reply to this form in this bug?

Overall impact of the Port

If the answer to any of the next two questions is “no”, then we will not be able to accept the port:
Is the stack-direction the same as x86?
< your answer here >

Is the code for a little-endian architecture?
< your answer here >

If either of the above questions is “no”, it will result in a highly invasive port. We cannot accept it.

How is this architecture different from x64 or ARM64?

This could be about data representations, flag bits, atomics, special registers, special constraints on registers, and things of that nature. It could also be if it is 32 bit.
< your answer here >

Do you expect that changes will be needed to the design or architecture of the JITs to support this architecture? Or would you be ok without JIT support?
< your answer here >

Any other comments regarding the technical impact of porting to this architecture.
Relevant information may be:

• A proof of concept / prototype demonstrating the complexity of the port
• A detailed analysis of the SpiderMonkey codebase and target architecture.
• Whether the port is similar to existing third-party SpiderMonkey ports.

< your answer here >

Maintenance of the port

SpiderMonkey is an actively developed project, the SpiderMonkey team is not responsible for independent ports. Maintaining a port requires multiple hours per week of dedicated work. At times, when larger changes are made to the engine, this may grow to several days to several weeks. To make sure the port is successful, we want to understand what resources you have available to maintain it.

Who will be the contact person(s) of this project?
< your answer here >

Do the contact person(s) have dedicated time to maintain the port?
< your answer here >

Do you have a plan for testing the port (continuous integration or similar)
< your answer here >

Any other comments about maintenance?

Relevant information might be:

• The port has funding
• You have experience maintaining similar size projects
• You are involved in developing spidermonkey in general

< your answer here >

Establishing relevance of the port

Finally, we want to understand what communities this port serves. It helps us determine the relevance and the importance of the work
How commonly used is the architecture you are targeting?
< your answer here >

What use cases does SpiderMonkey running on this port open up which were closed before?
< your answer here >

What use case(s) does this open for Firefox?
< your answer here >

Is there a business case for this port for Mozilla or Firefox?
< your answer here >

Any other comments regarding impacts the port may have more broadly?

Relevant information may be:

• Planned work not captured by the above questions

< your answer here >

Do you have any further information you’d like us to know?
< your answer here >

(In reply to Nicolas B. Pierron [:nbp] from comment #4)

Can you reply to this form in this bug?

Overall impact of the Port

If the answer to any of the next two questions is “no”, then we will not be able to accept the port:
Is the stack-direction the same as x86?
< your answer here >

Is the code for a little-endian architecture?
< your answer here >

If either of the above questions is “no”, it will result in a highly invasive port. We cannot accept it.

How is this architecture different from x64 or ARM64?

This could be about data representations, flag bits, atomics, special registers, special constraints on registers, and things of that nature. It could also be if it is 32 bit.
< your answer here >

Do you expect that changes will be needed to the design or architecture of the JITs to support this architecture? Or would you be ok without JIT support?
< your answer here >

Any other comments regarding the technical impact of porting to this architecture.
Relevant information may be:

• A proof of concept / prototype demonstrating the complexity of the port
• A detailed analysis of the SpiderMonkey codebase and target architecture.
• Whether the port is similar to existing third-party SpiderMonkey ports.

< your answer here >

Maintenance of the port

SpiderMonkey is an actively developed project, the SpiderMonkey team is not responsible for independent ports. Maintaining a port requires multiple hours per week of dedicated work. At times, when larger changes are made to the engine, this may grow to several days to several weeks. To make sure the port is successful, we want to understand what resources you have available to maintain it.

Who will be the contact person(s) of this project?
< your answer here >

Do the contact person(s) have dedicated time to maintain the port?
< your answer here >

Do you have a plan for testing the port (continuous integration or similar)
< your answer here >

Any other comments about maintenance?

Relevant information might be:

• The port has funding
• You have experience maintaining similar size projects
• You are involved in developing spidermonkey in general

< your answer here >

Establishing relevance of the port

Finally, we want to understand what communities this port serves. It helps us determine the relevance and the importance of the work
How commonly used is the architecture you are targeting?
< your answer here >

What use cases does SpiderMonkey running on this port open up which were closed before?
< your answer here >

What use case(s) does this open for Firefox?
< your answer here >

Is there a business case for this port for Mozilla or Firefox?
< your answer here >

Any other comments regarding impacts the port may have more broadly?

Relevant information may be:

• Planned work not captured by the above questions

< your answer here >

Do you have any further information you’d like us to know?
< your answer here >

yes, I'am writing it.

Proposal to add RISCV64GC JIT support to SpiderMonkey

This is a template for you to fill out before writing a port. If you write a port without filling out this form, please do not be surprised if we reject it.
Once this form is filled, post it on the SpiderMonkey discourse for discussion, or email it to your contacts on the SpiderMonkey team.
Overall impact of the Port

If the answer to any of the next two questions is “no”, then we will not be able to accept the port:
Is the stack-direction the same as x86?
Yes

Is the code for a little-endian architecture?

Yes
If either of the above questions is “no”, it will result in a highly invasive port. We cannot accept it.

How is this architecture different from x64 or ARM64?
This could be about data representations, flag bits, atomics, special registers, special constraints on registers, and things of that nature. It could also be if it is 32 bit.

RISC-V is a typical RISC ISA. The base integer instruction sets use a two’s-complement representation for signed integer values. The floating-point instruction set is compliant to IEEE-754 2008 standard. It has no flag bits for the comparing result of both integer and floating point. The comparing result is written into an integer register then used later by the consumer instruction. Overflow of integer computation is not recorded by hardware. There are several flags bit in the CSR (control and status registers) to hold the exception flags of floating-point instructions. There are 32 GPRs and 32 FPRs for the RISC-V ISA. Despite the hard-wired zero (GPR [0]), there’s no special register and no special constraints on registers.
RISC-V contains both 32bit and 64bit ISA. We want to add the JIT port of the 64bit standard ISA, which is the IMAFDC variant this time.

Do you expect that changes will be needed to the design or architecture of the JITs to support this architecture? Or would you be ok without JIT support?

No. According to our current porting work, almost no change to the core part of the JIT architecture.

No. According to the testing result on a real hardware hifive-unmatched, more than 6 times performance improvement is obtained with JIT comparing to that w/o JIT usinf SunSpider.

Any other comments regarding the technical impact of porting to this architecture.
Relevant information may be:
o A proof of concept / prototype demonstrating the complexity of the port
o A detailed analysis of the SpiderMonkey codebase and target architecture.
o Whether the port is similar to existing third-party SpiderMonkey ports.

In fact, we have nearly done the porting work, the test result is as follow:

jit-test: [ 9984| 33| 12| 0] 100% ======================================>| 205.6s
jstests: [44270| 2| 1| 6684] 100% ======================================>| 589.7s
jsapi-tests: 4 unexpected failures.

The detailed analysis can be seen at:
https://discourse.mozilla.org/t/meta-project-porting-spidermonkey-to-risc-v-rv64gc/85538

We had searched widely to make sure that there is no third-party RISCV64GC SpiderMonkey ports yet.
Maintenance of the port
SpiderMonkey is an actively developed project, the SpiderMonkey team is not responsible for independent ports. Maintaining a port requires multiple hours per week of dedicated work. At times, when larger changes are made to the engine, this may grow to several days to several weeks. To make sure the port is successful, we want to understand what resources you have available to maintain it.
Who will be the contact person(s) of this project?

Yahan Lu(yahan@iscas.ac.cn) and Ji Qiu(qiuji@iscas.ac.cn). We are both from the PLCT lab, ISCAS (Institute of Software, Chinese Academy of Sciences)[1].

Do the contact person(s) have dedicated time to maintain the port?

Yes, we are full-time engineers for this project at PLCT lab, ISCAS. One of the responsibilities of our job is to maintain RISC-V ports in open-source software, including SpiderMonkey and V8.

Do you have a plan for testing the port (continuous integration or similar)

Yes, we had set up CI on GitHub during our down-stream porting process. Once it accepted by upstream, we are going to set up a daily CI for it at https://ci.rvperf.org/. With the same style as V8, we will do daily regression for both debug/release mode in the simulator mode. Once the flag is red, we start to fix and upstream our patch.

Any other comments about maintenance?
Relevant information might be:
o The port has funding
o You have experience maintaining similar size projects
o You are involved in developing SpiderMonkey in general

Yahan and Ji had been maintainers of Chromium V8 for RISCV ISA since Feb 2021. We initiated the RISCV porting of both V8 and SpiderMonkey. We are hoping and exciting to bring up the most excellent JavaScript engines and browsers in the world to the RISCV eco-system.

Establishing relevance of the port
Finally, we want to understand what communities this port serves. It helps us determine the relevance and the importance of the work
How commonly used is the architecture you are targeting?

RISC-V is a new but quickly growing ISA. It’s believed that browser is one of the most important software for the desktop and mobile eco system. Although RISCV notebook or mobile phone is not quite commonly seen now, it’s necessary to prepare for the fundamental part of software solutions, especially for the Mozilla Firefox, the most excellent and widely used browser in the world.

What use cases does SpiderMonkey running on this port open up which were closed before?

Firefox browser had been brought up in September 2021 with basic RISCV64 porting. The SpiderMonkey was running at interpreter mode.
If the JIT support is OK, Firefox on RV64 Linux can run with a more smoothly.

What use case(s) does this open for Firefox?
Firefox browser on RISCV64 Linux Desktop

Is there a business case for this port for Mozilla or Firefox?

Not yet.

Any other comments regarding impacts the port may have more broadly?
Relevant information may be:
o Planned work not captured by the above questions

No.

Do you have any further information you’d like us to know?

No.

Reference:
[1] https://plctlab.github.io/

Big congrats! Finally :P

Thanks for filling this form, we would step forward to ask for approval from higher management to integrate such large contribution which might have an impact on the team.

Next week, knowledgeable team members would be looking at the implementation and provide incremental feedback on phabricator.
Multiple iterations of review should be expected, as such large set of changes are not reviewed in one day.

Thanks for your patience and this awesome contribution.

(In reply to Nicolas B. Pierron [:nbp] from comment #8)

Thanks for filling this form, we would step forward to ask for approval from higher management to integrate such large contribution which might have an impact on the team.

Next week, knowledgeable team members would be looking at the implementation and provide incremental feedback on phabricator.
Multiple iterations of review should be expected, as such large set of changes are not reviewed in one day.

Thanks for your patience and this awesome contribution.

Hi Nicolas ~

Are you any plan to review in this week?

(In reply to LuYahan from comment #9)

Are you any plan to review in this week?

Originally, yes.
However, I completely forgot about Thanksgiving happening this week and many co-workers taking days-off.

We are waiting for the acknowledgement from our management chain that this work can be integrated in Firefox code base before doing any formal review of the code.

Also, be aware that the review process might take some time, to verify every corner cases that we know of.
Sorry for the delay.

Thanks for all your work on this! We're happy to accept this backend into the tree.

Before we start reviewing, it would be great if you could split up the patch in at least the following parts:

1. Build system changes for the new architecture.
2. Other changes outside the js/src/jit/risc64/ directory
3. Adding the js/src/jit/riscv64/ directory.

Also, can you say more about the failing jit-tests? Have you tried running ./mach jit-test --ion? This does some extra stress testing of the JIT tiers.

(In reply to Jan de Mooij [:jandem] from comment #11)

Thanks for all your work on this! We're happy to accept this backend into the tree.

Before we start reviewing, it would be great if you could split up the patch in at least the following parts:

1. Build system changes for the new architecture.
2. Other changes outside the js/src/jit/risc64/ directory
3. Adding the js/src/jit/riscv64/ directory.

Also, can you say more about the failing jit-tests? Have you tried running ./mach jit-test --ion? This does some extra stress testing of the JIT tiers.

Hi jandem~

I had rebased and split up the patch.
And I run jit-test locally, such as

[17380|   45|   15|    0] 100% ======================================>| 275.7s

I continue to fix these failures.

When originally I uploaded the patch, i test it also, such as

jit-test: [ 9996|   21|   12|    0] 100% ======================================>| 206.3s
jstests: [44270|    2|    1| 6684] 100% ======================================>| 589.7s
jsapi-tests: 4 unexpected failures.

(In reply to Jan de Mooij [:jandem] from comment #11)

Thanks for all your work on this! We're happy to accept this backend into the tree.

Before we start reviewing, it would be great if you could split up the patch in at least the following parts:

1. Build system changes for the new architecture.
2. Other changes outside the js/src/jit/risc64/ directory
3. Adding the js/src/jit/riscv64/ directory.

Also, can you say more about the failing jit-tests? Have you tried running ./mach jit-test --ion? This does some extra stress testing of the JIT tiers.

Hi jandem ~

I had fix some error and uploaded patch into ph.
Now test status

jittest
[17413|   12|    1|    0] 100% ======================================>| 240.6s

(In reply to LuYahan from comment #15)

Hi jandem ~

I had fix some error and uploaded patch into ph.
Now test status

Thank you for the update! I'll work on getting those patches reviewed.

Against which revision of mozilla-central do these patches apply? And in what sequence should they be applied?

(In reply to Julian Seward [:jseward] from comment #17)

Against which revision of mozilla-central do these patches apply? And in what sequence should they be applied?

These patchs base on the main branch.
We can apply these by
1.D163407 Bug 1800431 - Add riscv64 backend about non riscv64 file.r=jandem
2.D161986 Bug 1800431 - Add riscv64 backend.r=jandem
3.D163406 Bug 1800431 - Add jit build condig for riscv64.r=jandem

(In reply to Jan de Mooij [:jandem] from comment #16)

(In reply to LuYahan from comment #15)

Hi jandem ~

I had fix some error and uploaded patch into ph.
Now test status

Thank you for the update! I'll work on getting those patches reviewed.

Hi jandem~

These patch have been accepted. Can you land these patch?

(In reply to LuYahan from comment #19)

These patch have been accepted. Can you land these patch?

Yes, for sure. Thanks so much for your work and patience! I'll push this to the try server first to check it doesn't break other builds.

We pushed these patches. We did notice some build bustage caused by recent code changes, but we expect those issues can be fixed more easily in a separate bug.

https://hg.mozilla.org/mozilla-central/rev/478a50a67d75
https://hg.mozilla.org/mozilla-central/rev/e2d1f36939ee
https://hg.mozilla.org/mozilla-central/rev/74ac0beba129

Comment on attachment 9314174 [details]
Bug 1800431-Port patch to riscv64.r=jandem

Revision D167901 was moved to bug 1812559. Setting attachment 9314174 [details] to obsolete.

A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party. (Or: if the patch doesn't change behavior -- e.g. landing a test case, or fixing a typo -- then feel free to disregard this message)

https://hg.mozilla.org/mozilla-central/rev/bc37e7c857ee