[RFC] Add a new backend called LoongArch

Hi all,

We are proposing the integration of a new backend targeting the LoongArch ISA.

  1. LoongArch intro
    LoongArch is a RISC style ISA which is independently designed by Loongson
    Technology in China. It is divided into two versions, the 32-bit version (LA32)
    and the 64-bit version (LA64). LA64 applications have application-level
    backward binary compatibility with LA32 applications. LoongArch is composed of
    a basic part (Loongson Base) and an expanded part. The expansion part includes
    Loongson Binary Translation (LBT), Loongson VirtualiZation (LVZ), Loongson SIMD
    EXtension (LSX) and Loongson Advanced SIMD EXtension(LASX).

Currently the LA464 processor core supports LoongArch ISA and the Loongson
3A5000 processor integrates 4 64-bit LA464 cores. LA464 is a four-issue 64-bit
high-performance processor core. It can be used as a single core for high-end
embedded and desktop applications, or as a basic processor core to form an
on-chip multi-core system for server and high-performance machine applications.

  1. Conform to the policy
    According to https://llvm.org/docs/DeveloperPolicy.html#adding-a-new-target
    a) Of couse it will be an experimental target at first.
    b) I’d like to be the code owner of this target.
    c) There is an active community behind the target: https://github.com/loongson
    And we will provide builbot support.
    d) Documentations:
  1. Status
    We started to implement an out-of-tree LoongArch LLVM port since last year
    based on llvm-8/11 and posted it to https://github.com/loongson/llvm-project
    last month. This port also adds supports to clang front-end and we finally pass
    100% llvm-test-suite in O0/1/2/3 optimization levels. But in this port there
    are a few issues we must handle to get it upstreamed.
  • The codebase is too old that means we may use some out-of-date interfaces.
  • The test coverage is not broad enough.
  • Coding standard is not met.
    So we decide to refactor this port base on llvm trunk and integrate to upstream
    incrementally. This approach of small, incremental patches is somewhat similar
    to what has been or is being done with many other backends like RISC-V, CSKY
    and VE.

The current status is that we have completed a series of 5 patches adding
triple, ELF machine, basic interger instructions and registers definition. We
will submit them for review later. Any comments are welcome and please do let
me know if you’d like to be added as a reviewer to future patches.

A rough development roadmap:

  • MC layer
  • CodeGen for Loongson Base
  • CodeGen for ISA extensions, including LSX and LASX
  • Support clang
  • Support other sub-projects

Best regards,
Weining Lu

Hi Weining,

Welcome to the LLVM community!

I had a look at the documentation and your fork and the description you gave matches what the community expects of new targets, so thanks for making the effort to know what to do before proposing a new target!

Some more comments below…

  1. LoongArch intro
    LoongArch is a RISC style ISA which is independently designed by Loongson
    Technology in China. It is divided into two versions, the 32-bit version (LA32)
    and the 64-bit version (LA64). LA64 applications have application-level
    backward binary compatibility with LA32 applications. LoongArch is composed of
    a basic part (Loongson Base) and an expanded part. The expansion part includes
    Loongson Binary Translation (LBT), Loongson VirtualiZation (LVZ), Loongson SIMD
    EXtension (LSX) and Loongson Advanced SIMD EXtension(LASX).

That’s an interesting target. It seems very sensible on its instruction encoding, data sizes and alignment, etc.

I’m just curious about the binary translation unit. Is that to support LA32/LA64 interchangeably (like x86_64 and AArch64 do with their 32-bit counterparts), or is that for some other architecture (like MIPS or Arm)?

  1. Conform to the policy
    According to https://llvm.org/docs/DeveloperPolicy.html#adding-a-new-target
    a) Of couse it will be an experimental target at first.
    b) I’d like to be the code owner of this target.
    c) There is an active community behind the target: https://github.com/loongson
    And we will provide builbot support.

Sounds great!

d) Documentations:

Some documents there (binary translation, vector extension) are TBD.

Given that the current llvm fork you have is only for basic support, I imagine you’ll tackle that after the basic support is merged. Before bringing extensions, we’d need documents for those, too.

The one thing left is to know if there are existing implementations of the hardware (as a product or a dev board) and/or if there are emulators freely available.

This is important for people that want to test the back-end on your hardware (for example, while debugging unrelated changes that break on your target).

  1. Status
    We started to implement an out-of-tree LoongArch LLVM port since last year
    based on llvm-8/11 and posted it to https://github.com/loongson/llvm-project
    last month. This port also adds supports to clang front-end and we finally pass
    100% llvm-test-suite in O0/1/2/3 optimization levels.

This is actually really nice!

But in this port there
are a few issues we must handle to get it upstreamed.

  • The codebase is too old that means we may use some out-of-date interfaces.

Your fork is based on the tree as of Oct 2020, that’s more than a year ago and in LLVM’s timeframes, an eternity.

That usually means you’ll have to re-write a good portion of your existing code, but I’m assuming you already knew that and is happy to proceed.

  • The test coverage is not broad enough.

Given that you pass the test-suite, I’m assuming you can generate a good portion of the use cases.

But it is important to also have extensive LIT tests (IR-to-IR, MIR, DAG, SRC-to-IR, etc) to avoid needing to run the test-suite for basic support testing.

  • Coding standard is not met.

I’m sure you know this is a deal breaker. But since you’re going to have to re-write good part of the code, I’m also assuming you’re happy making your new code meet the standards. :slight_smile:

The current status is that we have completed a series of 5 patches adding
triple, ELF machine, basic interger instructions and registers definition. We
will submit them for review later. Any comments are welcome and please do let
me know if you’d like to be added as a reviewer to future patches.

This sounds like a good start. Let’s get to lowering and parsing a function with a few arguments, instructions and a return value, and their respective tests.

Name those patches [X/N] with X being 1…N and N being the total number of patches in the first series. They need to be reviewed all at the same time and only when all are approved we can merge them all together.

This is important to make sure new targets start at the right place. From them on, you won’t need to number the patches, and can incrementally develop your target to reach maturity.

So, overall, I think this looks promising. Your target seems to meet the criteria we set for new targets, so looking forward to seeing the initial patches!

Thanks!
Renato

Thanks for your comments. Renato

Per your questions:

  1. Loongson Binary Translation (LBT) is targeting binary translation from other architectures(like X86, ARM) to LoongArch.

  2. Right, currently the documents for binary translation and vector extension are TBD. But those will be available before we bringing these extensions to LLVM.

  3. Hardware or emulator: AFAIK there are some PC based on 3A5000 can be bought at https://www.jd.com/ (a Chinese online shopping website. I’m not sure if there is an English version ).

Searching “3A5000” will show several products, like https://item.jd.com/100015866577.html and https://item.jd.com/100023656622.html

Beside this, qemu and CLFS are available at https://github.com/loongson/build-tools which are convenient to try on.

  1. The 5 initial patches are

https://reviews.llvm.org/D115857

https://reviews.llvm.org/D115859

https://reviews.llvm.org/D115860

https://reviews.llvm.org/D115861

https://reviews.llvm.org/D115862

Please help to reivew them or recommend other reviewers. Any comments are appreciate.

Thanks,

Weining

Excellent! Thanks for the answers.

As for the patches, if those are the only 5 initial patches, to make the arch work on its own initially, do you mind renaming them 1/5, 2/5 … 5/5?

It’s hard to know how many more patches are needed if you use ‘n’ and reviewers keep wondering if whatever is missing will come in a later patch or not.

If we ask for a split (on a large patch, for example), then just rename to however many patches there are. For example, if 2/5 splits in 2, then it becomes 2/6 and 3/6, and the rest accordingly.

Once we get through the initial phase, you don’t need to continue numbering the patches.

Thanks!

Yes, these are all the 5 initial patches. I will rename the number ‘n’ to 5.

Thanks!

Weining

-----Original Messages-----
From:“Renato Golin” rengolin@gmail.com
**Sent Time:**2021-12-17 18:07:15 (Friday)
To: “Weining Lu” luweining@loongson.cn
Cc: llvm-dev llvm-dev@lists.llvm.org, “余银” yuyin-hf@loongson.cn, “翟小娟” zhaixiaojuan@loongson.cn
Subject: Re: Re: [llvm-dev] [RFC] Add a new backend called LoongArch

Excellent! Thanks for the answers.

As for the patches, if those are the only 5 initial patches, to make the arch work on its own initially, do you mind renaming them 1/5, 2/5 … 5/5?

It’s hard to know how many more patches are needed if you use ‘n’ and reviewers keep wondering if whatever is missing will come in a later patch or not.

If we ask for a split (on a large patch, for example), then just rename to however many patches there are. For example, if 2/5 splits in 2, then it becomes 2/6 and 3/6, and the rest accordingly.

Once we get through the initial phase, you don’t need to continue numbering the patches.

Thanks!

Thanks for your comments. Renato

Per your questions:

  1. Loongson Binary Translation (LBT) is targeting binary translation from other architectures(like X86, ARM) to LoongArch.

  2. Right, currently the documents for binary translation and vector extension are TBD. But those will be available before we bringing these extensions to LLVM.

  3. Hardware or emulator: AFAIK there are some PC based on 3A5000 can be bought at https://www.jd.com/ (a Chinese online shopping website. I’m not sure if there is an English version ).

Searching “3A5000” will show several products, like https://item.jd.com/100015866577.html and https://item.jd.com/100023656622.html

Beside this, qemu and CLFS are available at https://github.com/loongson/build-tools which are convenient to try on.

  1. The 5 initial patches are

https://reviews.llvm.org/D115857

https://reviews.llvm.org/D115859

https://reviews.llvm.org/D115860

https://reviews.llvm.org/D115861

https://reviews.llvm.org/D115862

Please help to reivew them or recommend other reviewers. Any comments are appreciate.

Thanks,

Weining

发件人:“Renato Golin” <rengolin@gmail.com>
**发送时间:**2021-12-17 04:06:45 (星期五)
收件人: “陆伟宁” <luweining@loongson.cn>
抄送: llvm-dev <llvm-dev@lists.llvm.org>, “余银” <yuyin-hf@loongson.cn>, “翟小娟” <zhaixiaojuan@loongson.cn>
主题: Re: [llvm-dev] [RFC] Add a new backend called LoongArch

Hi Weining,

Welcome to the LLVM community!

I had a look at the documentation and your fork and the description you gave matches what the community expects of new targets, so thanks for making the effort to know what to do before proposing a new target!

Some more comments below…

  1. LoongArch intro
    LoongArch is a RISC style ISA which is independently designed by Loongson
    Technology in China. It is divided into two versions, the 32-bit version (LA32)
    and the 64-bit version (LA64). LA64 applications have application-level
    backward binary compatibility with LA32 applications. LoongArch is composed of
    a basic part (Loongson Base) and an expanded part. The expansion part includes
    Loongson Binary Translation (LBT), Loongson VirtualiZation (LVZ), Loongson SIMD
    EXtension (LSX) and Loongson Advanced SIMD EXtension(LASX).

That’s an interesting target. It seems very sensible on its instruction encoding, data sizes and alignment, etc.

I’m just curious about the binary translation unit. Is that to support LA32/LA64 interchangeably (like x86_64 and AArch64 do with their 32-bit counterparts), or is that for some other architecture (like MIPS or Arm)?

  1. Conform to the policy
    According to https://llvm.org/docs/DeveloperPolicy.html#adding-a-new-target
    a) Of couse it will be an experimental target at first.
    b) I’d like to be the code owner of this target.
    c) There is an active community behind the target: https://github.com/loongson
    And we will provide builbot support.

Sounds great!

d) Documentations:

Some documents there (binary translation, vector extension) are TBD.

Given that the current llvm fork you have is only for basic support, I imagine you’ll tackle that after the basic support is merged. Before bringing extensions, we’d need documents for those, too.

The one thing left is to know if there are existing implementations of the hardware (as a product or a dev board) and/or if there are emulators freely available.

This is important for people that want to test the back-end on your hardware (for example, while debugging unrelated changes that break on your target).

  1. Status
    We started to implement an out-of-tree LoongArch LLVM port since last year
    based on llvm-8/11 and posted it to https://github.com/loongson/llvm-project
    last month. This port also adds supports to clang front-end and we finally pass
    100% llvm-test-suite in O0/1/2/3 optimization levels.

This is actually really nice!

But in this port there
are a few issues we must handle to get it upstreamed.

  • The codebase is too old that means we may use some out-of-date interfaces.

Your fork is based on the tree as of Oct 2020, that’s more than a year ago and in LLVM’s timeframes, an eternity.

That usually means you’ll have to re-write a good portion of your existing code, but I’m assuming you already knew that and is happy to proceed.

  • The test coverage is not broad enough.

Given that you pass the test-suite, I’m assuming you can generate a good portion of the use cases.

But it is important to also have extensive LIT tests (IR-to-IR, MIR, DAG, SRC-to-IR, etc) to avoid needing to run the test-suite for basic support testing.

  • Coding standard is not met.

I’m sure you know this is a deal breaker. But since you’re going to have to re-write good part of the code, I’m also assuming you’re happy making your new code meet the standards. :slight_smile:

The current status is that we have completed a series of 5 patches adding
triple, ELF machine, basic interger instructions and registers definition. We
will submit them for review later. Any comments are welcome and please do let
me know if you’d like to be added as a reviewer to future patches.

This sounds like a good start. Let’s get to lowering and parsing a function with a few arguments, instructions and a return value, and their respective tests.

Name those patches [X/N] with X being 1…N and N being the total number of patches in the first series. They need to be reviewed all at the same time and only when all are approved we can merge them all together.

This is important to make sure new targets start at the right place. From them on, you won’t need to number the patches, and can incrementally develop your target to reach maturity.

So, overall, I think this looks promising. Your target seems to meet the criteria we set for new targets, so looking forward to seeing the initial patches!

Thanks!
Renato

本邮件及其附件含有龙芯中科的商业秘密信息,仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制或散发)本邮件及其附件中的信息。如果您错收本邮件,请您立即电话或邮件通知发件人并删除本邮件。
This email and its attachments contain confidential information from Loongson Technology , which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it.

本邮件及其附件含有龙芯中科的商业秘密信息,仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制或散发)本邮件及其附件中的信息。如果您错收本邮件,请您立即电话或邮件通知发件人并删除本邮件。
This email and its attachments contain confidential information from Loongson Technology , which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it.

Hi all,

The initial patches for upstraming LoongArch backend to LLVM are under review. Some of them have been approved and we’d like to get more inputs from you if interested. Comments are very appreciated.

Thanks,

Weining

-----Original Messages-----
From:“Weining Lu” luweining@loongson.cn
**Sent Time:**2021-12-17 15:23:33 (Friday)
To: “Renato Golin” rengolin@gmail.com
Cc: llvm-dev llvm-dev@lists.llvm.org, “余银” yuyin-hf@loongson.cn, “翟小娟” zhaixiaojuan@loongson.cn
Subject: Re: Re: [llvm-dev] [RFC] Add a new backend called LoongArch

Thanks for your comments. Renato

Per your questions:

  1. Loongson Binary Translation (LBT) is targeting binary translation from other architectures(like X86, ARM) to LoongArch.

  2. Right, currently the documents for binary translation and vector extension are TBD. But those will be available before we bringing these extensions to LLVM.

  3. Hardware or emulator: AFAIK there are some PC based on 3A5000 can be bought at https://www.jd.com/ (a Chinese online shopping website. I’m not sure if there is an English version ).

Searching “3A5000” will show several products, like https://item.jd.com/100015866577.html and https://item.jd.com/100023656622.html

Beside this, qemu and CLFS are available at https://github.com/loongson/build-tools which are convenient to try on.

  1. The 5 initial patches are

https://reviews.llvm.org/D115857

https://reviews.llvm.org/D115859

https://reviews.llvm.org/D115860

https://reviews.llvm.org/D115861

https://reviews.llvm.org/D115862

Please help to reivew them or recommend other reviewers. Any comments are appreciate.

Thanks,

Weining

发件人:“Renato Golin” rengolin@gmail.com
**发送时间:**2021-12-17 04:06:45 (星期五)
收件人: “陆伟宁” luweining@loongson.cn
抄送: llvm-dev llvm-dev@lists.llvm.org, “余银” yuyin-hf@loongson.cn, “翟小娟” zhaixiaojuan@loongson.cn
主题: Re: [llvm-dev] [RFC] Add a new backend called LoongArch

Hi Weining,

Welcome to the LLVM community!

I had a look at the documentation and your fork and the description you gave matches what the community expects of new targets, so thanks for making the effort to know what to do before proposing a new target!

Some more comments below…

  1. LoongArch intro
    LoongArch is a RISC style ISA which is independently designed by Loongson
    Technology in China. It is divided into two versions, the 32-bit version (LA32)
    and the 64-bit version (LA64). LA64 applications have application-level
    backward binary compatibility with LA32 applications. LoongArch is composed of
    a basic part (Loongson Base) and an expanded part. The expansion part includes
    Loongson Binary Translation (LBT), Loongson VirtualiZation (LVZ), Loongson SIMD
    EXtension (LSX) and Loongson Advanced SIMD EXtension(LASX).

That’s an interesting target. It seems very sensible on its instruction encoding, data sizes and alignment, etc.

I’m just curious about the binary translation unit. Is that to support LA32/LA64 interchangeably (like x86_64 and AArch64 do with their 32-bit counterparts), or is that for some other architecture (like MIPS or Arm)?

  1. Conform to the policy
    According to https://llvm.org/docs/DeveloperPolicy.html#adding-a-new-target
    a) Of couse it will be an experimental target at first.
    b) I’d like to be the code owner of this target.
    c) There is an active community behind the target: https://github.com/loongson
    And we will provide builbot support.

Sounds great!

d) Documentations:

Some documents there (binary translation, vector extension) are TBD.

Given that the current llvm fork you have is only for basic support, I imagine you’ll tackle that after the basic support is merged. Before bringing extensions, we’d need documents for those, too.

The one thing left is to know if there are existing implementations of the hardware (as a product or a dev board) and/or if there are emulators freely available.

This is important for people that want to test the back-end on your hardware (for example, while debugging unrelated changes that break on your target).

  1. Status
    We started to implement an out-of-tree LoongArch LLVM port since last year
    based on llvm-8/11 and posted it to https://github.com/loongson/llvm-project
    last month. This port also adds supports to clang front-end and we finally pass
    100% llvm-test-suite in O0/1/2/3 optimization levels.

This is actually really nice!

But in this port there
are a few issues we must handle to get it upstreamed.

  • The codebase is too old that means we may use some out-of-date interfaces.

Your fork is based on the tree as of Oct 2020, that’s more than a year ago and in LLVM’s timeframes, an eternity.

That usually means you’ll have to re-write a good portion of your existing code, but I’m assuming you already knew that and is happy to proceed.

  • The test coverage is not broad enough.

Given that you pass the test-suite, I’m assuming you can generate a good portion of the use cases.

But it is important to also have extensive LIT tests (IR-to-IR, MIR, DAG, SRC-to-IR, etc) to avoid needing to run the test-suite for basic support testing.

  • Coding standard is not met.

I’m sure you know this is a deal breaker. But since you’re going to have to re-write good part of the code, I’m also assuming you’re happy making your new code meet the standards. :slight_smile:

The current status is that we have completed a series of 5 patches adding
triple, ELF machine, basic interger instructions and registers definition. We
will submit them for review later. Any comments are welcome and please do let
me know if you’d like to be added as a reviewer to future patches.

This sounds like a good start. Let’s get to lowering and parsing a function with a few arguments, instructions and a return value, and their respective tests.

Name those patches [X/N] with X being 1…N and N being the total number of patches in the first series. They need to be reviewed all at the same time and only when all are approved we can merge them all together.

This is important to make sure new targets start at the right place. From them on, you won’t need to number the patches, and can incrementally develop your target to reach maturity.

So, overall, I think this looks promising. Your target seems to meet the criteria we set for new targets, so looking forward to seeing the initial patches!

Thanks!
Renato

本邮件及其附件含有龙芯中科的商业秘密信息,仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制或散发)本邮件及其附件中的信息。如果您错收本邮件,请您立即电话或邮件通知发件人并删除本邮件。
This email and its attachments contain confidential information from Loongson Technology , which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it.

本邮件及其附件含有龙芯中科的商业秘密信息,仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制或散发)本邮件及其附件中的信息。如果您错收本邮件,请您立即电话或邮件通知发件人并删除本邮件。
This email and its attachments contain confidential information from Loongson Technology , which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it.