<div dir="ltr">Hi Weining,<div><br></div><div>Welcome to the LLVM community!</div><div><br></div><div>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!</div><div><br></div><div>Some more comments below...</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 16 Dec 2021 at 07:55, 陆伟宁 via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-family:SimSun">1. LoongArch intro</span><br>
<span style="font-family:SimSun">LoongArch is a RISC style ISA which is independently designed by Loongson</span><br>
<span style="font-family:SimSun">Technology in China. It is divided into two versions, the 32-bit version (LA32)</span><br>
<span style="font-family:SimSun">and the 64-bit version (LA64). LA64 applications have application-level</span><br>
<span style="font-family:SimSun">backward binary compatibility with LA32 applications. LoongArch is composed of</span><br>
<span style="font-family:SimSun">a basic part (Loongson Base) and an expanded part. The expansion part includes</span><br>
<span style="font-family:SimSun">Loongson Binary Translation (LBT), Loongson VirtualiZation (LVZ), Loongson SIMD</span><br>
<span style="font-family:SimSun">EXtension (LSX) and Loongson Advanced SIMD EXtension(LASX).</span></blockquote><div><br></div><div>That's an interesting target. It seems very sensible on its instruction encoding, data sizes and alignment, etc.</div><div><br></div><div>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)?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-family:SimSun">2. Conform to the policy</span><br>
<span style="font-family:SimSun">According to <a href="https://llvm.org/docs/DeveloperPolicy.html#adding-a-new-target" target="_blank">https://llvm.org/docs/DeveloperPolicy.html#adding-a-new-target</a></span><br>
<span style="font-family:SimSun">a) Of couse it will be an experimental target at first.</span><br>
<span style="font-family:SimSun">b) I'd like to be the code owner of this target.</span><br>
<span style="font-family:SimSun">c) There is an active community behind the target: <a href="https://github.com/loongson" target="_blank">https://github.com/loongson</a></span><br>
<span style="font-family:SimSun"> And we will provide builbot support.</span></blockquote><div><br></div><div>Sounds great!</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-family:SimSun">d) Documentations:</span><br>
<span style="font-family:SimSun"> - ISA:</span><br>
<span style="font-family:SimSun"> <a href="https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html" target="_blank">https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html</a></span><br>
<span style="font-family:SimSun"> - ABI:</span><br>
<span style="font-family:SimSun"> <a href="https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html" target="_blank">https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html</a></span><br>
<span style="font-family:SimSun"> - More docs can be found at:</span><br>
<span style="font-family:SimSun"> <a href="https://loongson.github.io/LoongArch-Documentation/README-EN.html" target="_blank">https://loongson.github.io/LoongArch-Documentation/README-EN.html</a></span></blockquote><div><br></div><div>Some documents there (binary translation, vector extension) are TBD.</div><div><br></div><div>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.</div><div> <br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-family:SimSun">3. Status</span><br>
<span style="font-family:SimSun">We started to implement an out-of-tree LoongArch LLVM port since last year</span><br>
<span style="font-family:SimSun">based on llvm-8/11 and posted it to <a href="https://github.com/loongson/llvm-project" target="_blank">https://github.com/loongson/llvm-project</a></span><br>
<span style="font-family:SimSun">last month. This port also adds supports to clang front-end and we finally pass</span><br>
<span style="font-family:SimSun">100% llvm-test-suite in O0/1/2/3 optimization levels.</span></blockquote><div><br></div><div>This is actually really nice!</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-family:SimSun"> But in this port there</span><br>
<span style="font-family:SimSun">are a few issues we must handle to get it upstreamed.</span><br>
<span style="font-family:SimSun"> - The codebase is too old that means we may use some out-of-date interfaces.</span></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-family:SimSun"> - The test coverage is not broad enough.</span></blockquote><div><br></div><div>Given that you pass the test-suite, I'm assuming you can generate a good portion of the use cases. </div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-family:SimSun"> - Coding standard is not met.</span></blockquote><div><br></div><div>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. :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-family:SimSun">The current status is that we have completed a series of 5 patches adding</span><br>
<span style="font-family:SimSun">triple, ELF machine, basic interger instructions and registers definition. We</span><br>
<span style="font-family:SimSun">will submit them for review later. Any comments are welcome and please do let</span><br>
<span style="font-family:SimSun">me know if you'd like to be added as a reviewer to future patches.</span></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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!</div><div><br></div><div>Thanks!</div><div>Renato</div></div></div></div>