[VE][compiler-rt] Add VE as a target of crt

[kaz7]

Summary

SX Aurora VE is an experimental target. We upstreamed many part of
ported llvm and clang. In order to continue this move, we need to
support libraries next, then we need to show the ability of llvm for
VE through test cases. As a first step for that, we need to use
crt in compiler-rt. VE has it's own crt but they are a part of
proprietary compiler. So, we want to use crt in compiler-rt as an
alternative.

This patch enables VE as a candidate of crt in compiler-rt.

[kaz7]

VE is on the way to upstream, so it is an experimental target at the moment. This time, I'd like to add this VE as a candidate of crt/profile target in config-ix.cmake. I think it's better to be reviewed by people who are working on config-ix.cmake. So, I add people working on this file. Please review these modifications. Thanks!

[compnerd]

Maybe I am missing something, but it doesn't seem to be supported in llvm yet:
https://github.com/llvm/llvm-project/blob/main/llvm/CMakeLists.txt#L302-L320

Is this target supported by gcc perhaps?

[kaz7]

In D92748#2437671, @compnerd wrote:

Maybe I am missing something, but it doesn't seem to be supported in llvm yet:
https://github.com/llvm/llvm-project/blob/main/llvm/CMakeLists.txt#L302-L320

Thank you for your comment. No, it isn't supported yet. It is being upstreamed:
https://lists.llvm.org/pipermail/llvm-dev/2019-April/131580.html
https://github.com/llvm/llvm-project/tree/main/llvm/lib/Target/VE

So, it is not officially supported yet. It is an experimental target at the moment. However, in order to compile crt/profile for VE using LLVM for VE, we need above modifications. I'm not sure whether it is OK to add experimental target like above or not. It's the reason I add several people who know config-ix.cmake a lot as reviewers of this patch.

If it is OK to add experimental target, please review above as is. If not, please let me know how to add such a experimental target to config-ix.cmake. Thanks in advance.

[compnerd]

I think that once the LLVM backend target is merged, it would be reasonable to commit this change. The target being experimental is fine, but it should be available. (Marking as requesting changes until the backend is merged).

[kaz7]

Thank you for your comment. Well, I'll continue merging backend first. The backend of VE is almost merged, so I wanted to show it compiles compiler-rt, libcxxabi, libcxx, and openmp before making VE as an official target. I change my mind. I try to make it as an official target first. Thanks.

[kaz7]

@compnerd , I have a question. I'm thinking that you might misunderstand my explanations. VE is almost merged. I can compile llvm-project using already upstreamed llvm/clang. Now, in order to continue the upstreaming, I need crtbegin.o and crtend.o in compiler-rt. It is a reason why I submit this patch. Didn't you misunderstand the situation? Thanks!

[kaz7]

ping

[rengolin]

In D92748#2454376, @kaz7 wrote:

@compnerd , I have a question. I'm thinking that you might misunderstand my explanations. VE is almost merged. I can compile llvm-project using already upstreamed llvm/clang. Now, in order to continue the upstreaming, I need crtbegin.o and crtend.o in compiler-rt. It is a reason why I submit this patch. Didn't you misunderstand the situation? Thanks!

Hi @kaz7,

I re-read @compnerd reply and I agree with you that it's confusing. :)

Your target is available to build (via experimental flags) and it's not on the default list because it's not in production yet.

@compnerd, the VE code has landed already on both LLVM and Clang, and it's on its way to gain production quality before it's moved to the default list. But for that, it needs a runtime library.

I'm not sure what's the reason behind holing until it's in production. This only works for targets that have alternative libraries (in GCC or proprietary).

If you fear is dead code, IIUC, it should be pretty trivial to remove the RT VE side of things if the target is ultimately rejected (I'm not expecting it, but...), just like Clang and LLVM.

Makes sense?

[kaz7]

In D92748#2478794, @rengolin wrote:

Hi @kaz7,

If I understand correctly, this is a chicken-egg problem. You can't upstream the back-end without the RT changes because you have no other RT to rely on (unlike other targets that can use the GCC toolchain). In this case, I think it makes sense that we merge at least some bootstrapping code in RT before the back-end.

Hi @rengolin,

Thank you for the response. Your description is correct. That is what I tried to describe. Thanks.

[rengolin]

In D92748#2478802, @kaz7 wrote:

Thank you for the response. Your description is correct. That is what I tried to describe. Thanks.

Perfect! I re-read the comments and I see your point. I have edited my answer to fit the new understanding, sorry for the mess. :)

[kaz7]

Remove modification on the candidates of profilers.
Leave only modification on the candidates of crt and rebase.
Add explanations too.

[kaz7]

Not sure what is the problem... Remove profile support to make this patch as simple as possible.

[phosek]

LGTM

[kaz7]

In D92748#2485401, @phosek wrote:

LGTM

Thanks. But the status of this patch is still Needs Review. I guess this patch requires @compnerd's acceptance (please let me know if I misunderstand).

@compnerd , please review this patch if you have time. Thanks.

compiler-rt/cmake/config-ix.cmake

 set(PPC64 powerpc64 powerpc64le)
 set(RISCV32 riscv32)
 set(RISCV64 riscv64)
 set(S390X s390x)
 set(SPARC sparc)
 set(SPARCV9 sparcv9)
 set(WASM32 wasm32)
 set(WASM64 wasm64)
+set(VE ve)
 
 if(APPLE)
   set(ARM64 arm64)
   set(ARM32 armv7 armv7s armv7k)
   set(X86_64 x86_64 x86_64h)
 endif()
 
 set(ALL_SANITIZER_COMMON_SUPPORTED_ARCH ${X86} ${X86_64} ${PPC64} ${RISCV64}
     ${ARM32} ${ARM64} ${MIPS32} ${MIPS64} ${S390X} ${SPARC} ${SPARCV9})
 set(ALL_ASAN_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32} ${ARM64} ${RISCV64}
     ${MIPS32} ${MIPS64} ${PPC64} ${S390X} ${SPARC} ${SPARCV9})
-set(ALL_CRT_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32} ${ARM64} ${RISCV32} ${RISCV64})
+set(ALL_CRT_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32} ${ARM64} ${RISCV32} ${RISCV64} ${VE})
 set(ALL_DFSAN_SUPPORTED_ARCH ${X86_64} ${MIPS64} ${ARM64})
 
 if(ANDROID)
   set(OS_NAME "Android")
 else()
   set(OS_NAME "${CMAKE_SYSTEM_NAME}")
 endif()