maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Driver/riscv64-toolchain.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

331 lines
17 KiB
C
Raw Normal View History

[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 21:36:56 +08:00
// A basic clang -cc1 command-line, and simple environment check.
[clang][Driver] Handle risvc in Baremetal.cpp. I am working on a baremetal riscv toolchain using LLVM runtime and LLD linker. Baremetal.cpp provides most of the things needed for such toolchain. So I have modified it to also handle riscv64/32-unknown-elf targets alongside arm-none-eabi. Currently, targets like riscv64-unknown-elf are handled by RISCVToolChain which mostly expects a gcc toolchain to be present. If you dont want the dependency on gcc-toolchain/libgloss or want to use LLD, then RISCVToolChain is not a good fit. So in the toolchain selection code, I have made this dependency of RISCVToolChain on gcc toolchain explicit. It is created if gcc-toolchain option is present. Otherwise Baremetal toolchain is created. I will be happy to hear if there is a better way to choose between these two toolchains. Reviewed By: jroelofs Differential Revision: https://reviews.llvm.org/D91442
2020-11-26 19:31:45 +08:00
// RUN: %clang %s -### -no-canonical-prefixes -target riscv64 \
// RUN: --gcc-toolchain=%S/Inputs/basic_riscv64_tree 2>&1 \
// RUN: | FileCheck -check-prefix=CC1 %s
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 21:36:56 +08:00
// CC1: clang{{.*}} "-cc1" "-triple" "riscv64"
Support -fuse-ld=lld for riscv Add a configure feature test to filter out tests that explicitly depend on platform linker. Differential Revision: https://reviews.llvm.org/D74704
2020-02-17 20:42:00 +08:00
// Test interaction with -fuse-ld=lld, if lld is available.
[clang][Driver] Handle risvc in Baremetal.cpp. I am working on a baremetal riscv toolchain using LLVM runtime and LLD linker. Baremetal.cpp provides most of the things needed for such toolchain. So I have modified it to also handle riscv64/32-unknown-elf targets alongside arm-none-eabi. Currently, targets like riscv64-unknown-elf are handled by RISCVToolChain which mostly expects a gcc toolchain to be present. If you dont want the dependency on gcc-toolchain/libgloss or want to use LLD, then RISCVToolChain is not a good fit. So in the toolchain selection code, I have made this dependency of RISCVToolChain on gcc toolchain explicit. It is created if gcc-toolchain option is present. Otherwise Baremetal toolchain is created. I will be happy to hear if there is a better way to choose between these two toolchains. Reviewed By: jroelofs Differential Revision: https://reviews.llvm.org/D91442
2020-11-26 19:31:45 +08:00
// RUN: %clang %s -### -no-canonical-prefixes -target riscv32 -fuse-ld=lld \
// RUN: --gcc-toolchain=%S/Inputs/basic_riscv64_tree 2>&1 \
// RUN: | FileCheck -check-prefix=LLD %s
Support -fuse-ld=lld for riscv Add a configure feature test to filter out tests that explicitly depend on platform linker. Differential Revision: https://reviews.llvm.org/D74704
2020-02-17 20:42:00 +08:00
// LLD: {{(error: invalid linker name in argument '-fuse-ld=lld')|(ld.lld)}}
[RISCV] Use compiler-rt if no GCC installation detected If a GCC installation is not detected, then this attempts to use compiler-rt and the compiler-rt crtbegin/crtend implementations as a fallback. Differential Revision: https://reviews.llvm.org/D68407
2019-11-23 03:05:39 +08:00
// In the below tests, --rtlib=platform is used so that the driver ignores
// the configure-time CLANG_DEFAULT_RTLIB option when choosing the runtime lib
clang/test: Remove platform-linker feature By explicitly requesting the system linker with `-fuse-ld=`, the tests are able to CHECK for the system linker even with CLANG_DEFAULT_LINKER=lld. Alternative to D74704. Differential Revision: https://reviews.llvm.org/D92291
2020-11-30 09:17:56 +08:00
// RUN: %clang %s -### -no-canonical-prefixes -fuse-ld= \
[RISCV] Use compiler-rt if no GCC installation detected If a GCC installation is not detected, then this attempts to use compiler-rt and the compiler-rt crtbegin/crtend implementations as a fallback. Differential Revision: https://reviews.llvm.org/D68407
2019-11-23 03:05:39 +08:00
// RUN: -target riscv64-unknown-elf --rtlib=platform \
[RISCV] Collect library directories and triples for riscv64 triple too When setting up library and tools paths when detecting an accompanying GCC installation only riscv32 was handled. As a consequence when targetting riscv64 neither the linker nor libraries would be found. This adds handling and tests for riscv64. Differential Revision: https://reviews.llvm.org/D53392 Patch by Edward Jones. llvm-svn: 357699
2019-04-04 22:18:26 +08:00
// RUN: --gcc-toolchain=%S/Inputs/basic_riscv64_tree \
// RUN: --sysroot=%S/Inputs/basic_riscv64_tree/riscv64-unknown-elf 2>&1 \
// RUN: | FileCheck -check-prefix=C-RV64-BAREMETAL-LP64 %s
[RISCV] Fix up tests on Windows after new usage of sys::path::append
2019-11-08 01:53:56 +08:00
// C-RV64-BAREMETAL-LP64: "{{.*}}Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/../../..{{/|\\\\}}..{{/|\\\\}}bin{{/|\\\\}}riscv64-unknown-elf-ld"
[RISCV] Collect library directories and triples for riscv64 triple too When setting up library and tools paths when detecting an accompanying GCC installation only riscv32 was handled. As a consequence when targetting riscv64 neither the linker nor libraries would be found. This adds handling and tests for riscv64. Differential Revision: https://reviews.llvm.org/D53392 Patch by Edward Jones. llvm-svn: 357699
2019-04-04 22:18:26 +08:00
// C-RV64-BAREMETAL-LP64: "--sysroot={{.*}}/Inputs/basic_riscv64_tree/riscv64-unknown-elf"
// C-RV64-BAREMETAL-LP64: "{{.*}}/Inputs/basic_riscv64_tree/riscv64-unknown-elf/lib{{/|\\\\}}crt0.o"
// C-RV64-BAREMETAL-LP64: "{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1{{/|\\\\}}crtbegin.o"
Revert "[RISCV] Support mutilib in baremetal environment" This reverts commit df876a026981b7a125b31bbb85ba4b1144edb0f9. Clang::riscv32-toolchain.c Clang::riscv64-toolchain.c fails on Windows.
2019-11-21 20:34:10 +08:00
// C-RV64-BAREMETAL-LP64: "-L{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1"
[RISCV] Support mutilib in baremetal environment 1. Currently only support the set of multilibs same to riscv-gnu-toolchain. 2. Fix testcase typo causes fail on Windows. 3. Fix testcases to set empty sysroot. Reviewers: espindola, asb, kito-cheng, lenary Reviewed By: lenary Differential Revision: https://reviews.llvm.org/D67508
2019-11-21 17:12:48 +08:00
// C-RV64-BAREMETAL-LP64: "-L{{.*}}/Inputs/basic_riscv64_tree/riscv64-unknown-elf/lib"
[RISCV] Collect library directories and triples for riscv64 triple too When setting up library and tools paths when detecting an accompanying GCC installation only riscv32 was handled. As a consequence when targetting riscv64 neither the linker nor libraries would be found. This adds handling and tests for riscv64. Differential Revision: https://reviews.llvm.org/D53392 Patch by Edward Jones. llvm-svn: 357699
2019-04-04 22:18:26 +08:00
// C-RV64-BAREMETAL-LP64: "--start-group" "-lc" "-lgloss" "--end-group" "-lgcc"
// C-RV64-BAREMETAL-LP64: "{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1{{/|\\\\}}crtend.o"
clang/test: Remove platform-linker feature By explicitly requesting the system linker with `-fuse-ld=`, the tests are able to CHECK for the system linker even with CLANG_DEFAULT_LINKER=lld. Alternative to D74704. Differential Revision: https://reviews.llvm.org/D92291
2020-11-30 09:17:56 +08:00
// RUN: %clang %s -### -no-canonical-prefixes -fuse-ld= \
[RISCV] Use compiler-rt if no GCC installation detected If a GCC installation is not detected, then this attempts to use compiler-rt and the compiler-rt crtbegin/crtend implementations as a fallback. Differential Revision: https://reviews.llvm.org/D68407
2019-11-23 03:05:39 +08:00
// RUN: -target riscv64-unknown-elf --rtlib=platform \
[RISCV] Collect library directories and triples for riscv64 triple too When setting up library and tools paths when detecting an accompanying GCC installation only riscv32 was handled. As a consequence when targetting riscv64 neither the linker nor libraries would be found. This adds handling and tests for riscv64. Differential Revision: https://reviews.llvm.org/D53392 Patch by Edward Jones. llvm-svn: 357699
2019-04-04 22:18:26 +08:00
// RUN: --sysroot= \
// RUN: --gcc-toolchain=%S/Inputs/basic_riscv64_tree 2>&1 \
// RUN: | FileCheck -check-prefix=C-RV64-BAREMETAL-NOSYSROOT-LP64 %s
[RISCV] Fix up tests on Windows after new usage of sys::path::append
2019-11-08 01:53:56 +08:00
// C-RV64-BAREMETAL-NOSYSROOT-LP64: "{{.*}}Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/../../..{{/|\\\\}}..{{/|\\\\}}bin{{/|\\\\}}riscv64-unknown-elf-ld"
// C-RV64-BAREMETAL-NOSYSROOT-LP64: "{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/../../..{{/|\\\\}}..{{/|\\\\}}riscv64-unknown-elf/lib{{/|\\\\}}crt0.o"
[RISCV] Collect library directories and triples for riscv64 triple too When setting up library and tools paths when detecting an accompanying GCC installation only riscv32 was handled. As a consequence when targetting riscv64 neither the linker nor libraries would be found. This adds handling and tests for riscv64. Differential Revision: https://reviews.llvm.org/D53392 Patch by Edward Jones. llvm-svn: 357699
2019-04-04 22:18:26 +08:00
// C-RV64-BAREMETAL-NOSYSROOT-LP64: "{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1{{/|\\\\}}crtbegin.o"
Revert "[RISCV] Support mutilib in baremetal environment" This reverts commit df876a026981b7a125b31bbb85ba4b1144edb0f9. Clang::riscv32-toolchain.c Clang::riscv64-toolchain.c fails on Windows.
2019-11-21 20:34:10 +08:00
// C-RV64-BAREMETAL-NOSYSROOT-LP64: "-L{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1"
[RISCV] Support mutilib in baremetal environment 1. Currently only support the set of multilibs same to riscv-gnu-toolchain. 2. Fix testcase typo causes fail on Windows. 3. Fix testcases to set empty sysroot. Reviewers: espindola, asb, kito-cheng, lenary Reviewed By: lenary Differential Revision: https://reviews.llvm.org/D67508
2019-11-21 17:12:48 +08:00
// C-RV64-BAREMETAL-NOSYSROOT-LP64: "-L{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/../../..{{/|\\\\}}..{{/|\\\\}}riscv64-unknown-elf{{/|\\\\}}lib"
[RISCV] Collect library directories and triples for riscv64 triple too When setting up library and tools paths when detecting an accompanying GCC installation only riscv32 was handled. As a consequence when targetting riscv64 neither the linker nor libraries would be found. This adds handling and tests for riscv64. Differential Revision: https://reviews.llvm.org/D53392 Patch by Edward Jones. llvm-svn: 357699
2019-04-04 22:18:26 +08:00
// C-RV64-BAREMETAL-NOSYSROOT-LP64: "--start-group" "-lc" "-lgloss" "--end-group" "-lgcc"
// C-RV64-BAREMETAL-NOSYSROOT-LP64: "{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1{{/|\\\\}}crtend.o"
clang/test: Remove platform-linker feature By explicitly requesting the system linker with `-fuse-ld=`, the tests are able to CHECK for the system linker even with CLANG_DEFAULT_LINKER=lld. Alternative to D74704. Differential Revision: https://reviews.llvm.org/D92291
2020-11-30 09:17:56 +08:00
// RUN: %clangxx %s -### -no-canonical-prefixes -fuse-ld= \
[RISCV] Use compiler-rt if no GCC installation detected If a GCC installation is not detected, then this attempts to use compiler-rt and the compiler-rt crtbegin/crtend implementations as a fallback. Differential Revision: https://reviews.llvm.org/D68407
2019-11-23 03:05:39 +08:00
// RUN: -target riscv64-unknown-elf -stdlib=libstdc++ --rtlib=platform \
[RISCV] Collect library directories and triples for riscv64 triple too When setting up library and tools paths when detecting an accompanying GCC installation only riscv32 was handled. As a consequence when targetting riscv64 neither the linker nor libraries would be found. This adds handling and tests for riscv64. Differential Revision: https://reviews.llvm.org/D53392 Patch by Edward Jones. llvm-svn: 357699
2019-04-04 22:18:26 +08:00
// RUN: --gcc-toolchain=%S/Inputs/basic_riscv64_tree \
// RUN: --sysroot=%S/Inputs/basic_riscv64_tree/riscv64-unknown-elf 2>&1 \
// RUN: | FileCheck -check-prefix=CXX-RV64-BAREMETAL-LP64 %s
// CXX-RV64-BAREMETAL-LP64: "-internal-isystem" "{{.*}}Inputs/basic_riscv64_tree/riscv64-unknown-elf/include/c++{{/|\\\\}}8.0.1"
[RISCV] Fix up tests on Windows after new usage of sys::path::append
2019-11-08 01:53:56 +08:00
// CXX-RV64-BAREMETAL-LP64: "{{.*}}Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/../../..{{/|\\\\}}..{{/|\\\\}}bin{{/|\\\\}}riscv64-unknown-elf-ld"
[RISCV] Collect library directories and triples for riscv64 triple too When setting up library and tools paths when detecting an accompanying GCC installation only riscv32 was handled. As a consequence when targetting riscv64 neither the linker nor libraries would be found. This adds handling and tests for riscv64. Differential Revision: https://reviews.llvm.org/D53392 Patch by Edward Jones. llvm-svn: 357699
2019-04-04 22:18:26 +08:00
// CXX-RV64-BAREMETAL-LP64: "--sysroot={{.*}}/Inputs/basic_riscv64_tree/riscv64-unknown-elf"
// CXX-RV64-BAREMETAL-LP64: "{{.*}}/Inputs/basic_riscv64_tree/riscv64-unknown-elf/lib{{/|\\\\}}crt0.o"
// CXX-RV64-BAREMETAL-LP64: "{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1{{/|\\\\}}crtbegin.o"
Revert "[RISCV] Support mutilib in baremetal environment" This reverts commit df876a026981b7a125b31bbb85ba4b1144edb0f9. Clang::riscv32-toolchain.c Clang::riscv64-toolchain.c fails on Windows.
2019-11-21 20:34:10 +08:00
// CXX-RV64-BAREMETAL-LP64: "-L{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1"
[RISCV] Support mutilib in baremetal environment 1. Currently only support the set of multilibs same to riscv-gnu-toolchain. 2. Fix testcase typo causes fail on Windows. 3. Fix testcases to set empty sysroot. Reviewers: espindola, asb, kito-cheng, lenary Reviewed By: lenary Differential Revision: https://reviews.llvm.org/D67508
2019-11-21 17:12:48 +08:00
// CXX-RV64-BAREMETAL-LP64: "-L{{.*}}/Inputs/basic_riscv64_tree/riscv64-unknown-elf/lib"
[RISCV] Collect library directories and triples for riscv64 triple too When setting up library and tools paths when detecting an accompanying GCC installation only riscv32 was handled. As a consequence when targetting riscv64 neither the linker nor libraries would be found. This adds handling and tests for riscv64. Differential Revision: https://reviews.llvm.org/D53392 Patch by Edward Jones. llvm-svn: 357699
2019-04-04 22:18:26 +08:00
// CXX-RV64-BAREMETAL-LP64: "-lstdc++" "--start-group" "-lc" "-lgloss" "--end-group" "-lgcc"
// CXX-RV64-BAREMETAL-LP64: "{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1{{/|\\\\}}crtend.o"
clang/test: Remove platform-linker feature By explicitly requesting the system linker with `-fuse-ld=`, the tests are able to CHECK for the system linker even with CLANG_DEFAULT_LINKER=lld. Alternative to D74704. Differential Revision: https://reviews.llvm.org/D92291
2020-11-30 09:17:56 +08:00
// RUN: %clangxx %s -### -no-canonical-prefixes -fuse-ld= \
[RISCV] Use compiler-rt if no GCC installation detected If a GCC installation is not detected, then this attempts to use compiler-rt and the compiler-rt crtbegin/crtend implementations as a fallback. Differential Revision: https://reviews.llvm.org/D68407
2019-11-23 03:05:39 +08:00
// RUN: -target riscv64-unknown-elf -stdlib=libstdc++ --rtlib=platform \
[RISCV] Collect library directories and triples for riscv64 triple too When setting up library and tools paths when detecting an accompanying GCC installation only riscv32 was handled. As a consequence when targetting riscv64 neither the linker nor libraries would be found. This adds handling and tests for riscv64. Differential Revision: https://reviews.llvm.org/D53392 Patch by Edward Jones. llvm-svn: 357699
2019-04-04 22:18:26 +08:00
// RUN: --sysroot= \
// RUN: --gcc-toolchain=%S/Inputs/basic_riscv64_tree 2>&1 \
// RUN: | FileCheck -check-prefix=CXX-RV64-BAREMETAL-NOSYSROOT-LP64 %s
[RISCV] Fix up tests on Windows after new usage of sys::path::append
2019-11-08 01:53:56 +08:00
// CXX-RV64-BAREMETAL-NOSYSROOT-LP64: "-internal-isystem" "{{.*}}Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/../../..{{/|\\\\}}..{{/|\\\\}}riscv64-unknown-elf/include/c++{{/|\\\\}}8.0.1"
// CXX-RV64-BAREMETAL-NOSYSROOT-LP64: "{{.*}}Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/../../..{{/|\\\\}}..{{/|\\\\}}bin{{/|\\\\}}riscv64-unknown-elf-ld"
// CXX-RV64-BAREMETAL-NOSYSROOT-LP64: "{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/../../..{{/|\\\\}}..{{/|\\\\}}riscv64-unknown-elf/lib{{/|\\\\}}crt0.o"
[RISCV] Collect library directories and triples for riscv64 triple too When setting up library and tools paths when detecting an accompanying GCC installation only riscv32 was handled. As a consequence when targetting riscv64 neither the linker nor libraries would be found. This adds handling and tests for riscv64. Differential Revision: https://reviews.llvm.org/D53392 Patch by Edward Jones. llvm-svn: 357699
2019-04-04 22:18:26 +08:00
// CXX-RV64-BAREMETAL-NOSYSROOT-LP64: "{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1{{/|\\\\}}crtbegin.o"
Revert "[RISCV] Support mutilib in baremetal environment" This reverts commit df876a026981b7a125b31bbb85ba4b1144edb0f9. Clang::riscv32-toolchain.c Clang::riscv64-toolchain.c fails on Windows.
2019-11-21 20:34:10 +08:00
// CXX-RV64-BAREMETAL-NOSYSROOT-LP64: "-L{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1"
[RISCV] Support mutilib in baremetal environment 1. Currently only support the set of multilibs same to riscv-gnu-toolchain. 2. Fix testcase typo causes fail on Windows. 3. Fix testcases to set empty sysroot. Reviewers: espindola, asb, kito-cheng, lenary Reviewed By: lenary Differential Revision: https://reviews.llvm.org/D67508
2019-11-21 17:12:48 +08:00
// CXX-RV64-BAREMETAL-NOSYSROOT-LP64: "-L{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/../../..{{/|\\\\}}..{{/|\\\\}}riscv64-unknown-elf/lib"
[RISCV] Collect library directories and triples for riscv64 triple too When setting up library and tools paths when detecting an accompanying GCC installation only riscv32 was handled. As a consequence when targetting riscv64 neither the linker nor libraries would be found. This adds handling and tests for riscv64. Differential Revision: https://reviews.llvm.org/D53392 Patch by Edward Jones. llvm-svn: 357699
2019-04-04 22:18:26 +08:00
// CXX-RV64-BAREMETAL-NOSYSROOT-LP64: "-lstdc++" "--start-group" "-lc" "-lgloss" "--end-group" "-lgcc"
// CXX-RV64-BAREMETAL-NOSYSROOT-LP64: "{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1{{/|\\\\}}crtend.o"
clang/test: Remove platform-linker feature By explicitly requesting the system linker with `-fuse-ld=`, the tests are able to CHECK for the system linker even with CLANG_DEFAULT_LINKER=lld. Alternative to D74704. Differential Revision: https://reviews.llvm.org/D92291
2020-11-30 09:17:56 +08:00
// RUN: %clang %s -### -no-canonical-prefixes -fuse-ld=ld -fuse-ld= \
[RISCV] Use compiler-rt if no GCC installation detected If a GCC installation is not detected, then this attempts to use compiler-rt and the compiler-rt crtbegin/crtend implementations as a fallback. Differential Revision: https://reviews.llvm.org/D68407
2019-11-23 03:05:39 +08:00
// RUN: -target riscv64-unknown-linux-gnu --rtlib=platform -mabi=lp64 \
[RISCV] Collect library directories and triples for riscv64 triple too When setting up library and tools paths when detecting an accompanying GCC installation only riscv32 was handled. As a consequence when targetting riscv64 neither the linker nor libraries would be found. This adds handling and tests for riscv64. Differential Revision: https://reviews.llvm.org/D53392 Patch by Edward Jones. llvm-svn: 357699
2019-04-04 22:18:26 +08:00
// RUN: --gcc-toolchain=%S/Inputs/multilib_riscv_linux_sdk \
// RUN: --sysroot=%S/Inputs/multilib_riscv_linux_sdk/sysroot 2>&1 \
// RUN: | FileCheck -check-prefix=C-RV64-LINUX-MULTI-LP64 %s
[RISCV] Fix up tests on Windows after new usage of sys::path::append
2019-11-08 01:53:56 +08:00
// C-RV64-LINUX-MULTI-LP64: "{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/../../..{{/|\\\\}}..{{/|\\\\}}riscv64-unknown-linux-gnu/bin{{/|\\\\}}ld"
[RISCV] Collect library directories and triples for riscv64 triple too When setting up library and tools paths when detecting an accompanying GCC installation only riscv32 was handled. As a consequence when targetting riscv64 neither the linker nor libraries would be found. This adds handling and tests for riscv64. Differential Revision: https://reviews.llvm.org/D53392 Patch by Edward Jones. llvm-svn: 357699
2019-04-04 22:18:26 +08:00
// C-RV64-LINUX-MULTI-LP64: "--sysroot={{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot"
// C-RV64-LINUX-MULTI-LP64: "-m" "elf64lriscv"
// C-RV64-LINUX-MULTI-LP64: "-dynamic-linker" "/lib/ld-linux-riscv64-lp64.so.1"
// C-RV64-LINUX-MULTI-LP64: "{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib64/lp64{{/|\\\\}}crtbegin.o"
// C-RV64-LINUX-MULTI-LP64: "-L{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib64/lp64"
// C-RV64-LINUX-MULTI-LP64: "-L{{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot/lib64/lp64"
// C-RV64-LINUX-MULTI-LP64: "-L{{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib64/lp64"
// RUN: %clang %s -### -no-canonical-prefixes -fuse-ld=ld \
[RISCV] Use compiler-rt if no GCC installation detected If a GCC installation is not detected, then this attempts to use compiler-rt and the compiler-rt crtbegin/crtend implementations as a fallback. Differential Revision: https://reviews.llvm.org/D68407
2019-11-23 03:05:39 +08:00
// RUN: -target riscv64-unknown-linux-gnu --rtlib=platform -march=rv64imafd \
[RISCV] Collect library directories and triples for riscv64 triple too When setting up library and tools paths when detecting an accompanying GCC installation only riscv32 was handled. As a consequence when targetting riscv64 neither the linker nor libraries would be found. This adds handling and tests for riscv64. Differential Revision: https://reviews.llvm.org/D53392 Patch by Edward Jones. llvm-svn: 357699
2019-04-04 22:18:26 +08:00
// RUN: --gcc-toolchain=%S/Inputs/multilib_riscv_linux_sdk \
// RUN: --sysroot=%S/Inputs/multilib_riscv_linux_sdk/sysroot 2>&1 \
// RUN: | FileCheck -check-prefix=C-RV64-LINUX-MULTI-LP64D %s
[RISCV] Fix up tests on Windows after new usage of sys::path::append
2019-11-08 01:53:56 +08:00
// C-RV64-LINUX-MULTI-LP64D: "{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/../../..{{/|\\\\}}..{{/|\\\\}}riscv64-unknown-linux-gnu/bin{{/|\\\\}}ld"
[RISCV] Collect library directories and triples for riscv64 triple too When setting up library and tools paths when detecting an accompanying GCC installation only riscv32 was handled. As a consequence when targetting riscv64 neither the linker nor libraries would be found. This adds handling and tests for riscv64. Differential Revision: https://reviews.llvm.org/D53392 Patch by Edward Jones. llvm-svn: 357699
2019-04-04 22:18:26 +08:00
// C-RV64-LINUX-MULTI-LP64D: "--sysroot={{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot"
// C-RV64-LINUX-MULTI-LP64D: "-m" "elf64lriscv"
// C-RV64-LINUX-MULTI-LP64D: "-dynamic-linker" "/lib/ld-linux-riscv64-lp64d.so.1"
// C-RV64-LINUX-MULTI-LP64D: "{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib64/lp64d{{/|\\\\}}crtbegin.o"
// C-RV64-LINUX-MULTI-LP64D: "-L{{.*}}/Inputs/multilib_riscv_linux_sdk/lib/gcc/riscv64-unknown-linux-gnu/7.2.0/lib64/lp64d"
// C-RV64-LINUX-MULTI-LP64D: "-L{{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot/lib64/lp64d"
// C-RV64-LINUX-MULTI-LP64D: "-L{{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib64/lp64d"
[RISCV] Support mutilib in baremetal environment 1. Currently only support the set of multilibs same to riscv-gnu-toolchain. 2. Fix testcase typo causes fail on Windows. 3. Fix testcases to set empty sysroot. Reviewers: espindola, asb, kito-cheng, lenary Reviewed By: lenary Differential Revision: https://reviews.llvm.org/D67508
2019-11-21 17:12:48 +08:00
// RUN: %clang %s -### -no-canonical-prefixes -fuse-ld=ld \
[RISCV] Use compiler-rt if no GCC installation detected If a GCC installation is not detected, then this attempts to use compiler-rt and the compiler-rt crtbegin/crtend implementations as a fallback. Differential Revision: https://reviews.llvm.org/D68407
2019-11-23 03:05:39 +08:00
// RUN: -target riscv64-unknown-elf --rtlib=platform --sysroot= \
// RUN: -march=rv64imac -mabi=lp64\
[RISCV] Support mutilib in baremetal environment 1. Currently only support the set of multilibs same to riscv-gnu-toolchain. 2. Fix testcase typo causes fail on Windows. 3. Fix testcases to set empty sysroot. Reviewers: espindola, asb, kito-cheng, lenary Reviewed By: lenary Differential Revision: https://reviews.llvm.org/D67508
2019-11-21 17:12:48 +08:00
// RUN: --gcc-toolchain=%S/Inputs/multilib_riscv_elf_sdk 2>&1 \
// RUN: | FileCheck -check-prefix=C-RV64IMAC-BAREMETAL-MULTI-LP64 %s
// C-RV64IMAC-BAREMETAL-MULTI-LP64: "{{.*}}/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/../../..{{/|\\\\}}..{{/|\\\\}}riscv64-unknown-elf/bin{{/|\\\\}}ld"
// C-RV64IMAC-BAREMETAL-MULTI-LP64: "-m" "elf64lriscv"
// C-RV64IMAC-BAREMETAL-MULTI-LP64: "{{.*}}/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/../../..{{/|\\\\}}..{{/|\\\\}}riscv64-unknown-elf/lib/rv64imac/lp64{{/|\\\\}}crt0.o"
// C-RV64IMAC-BAREMETAL-MULTI-LP64: "{{.*}}/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv64imac/lp64{{/|\\\\}}crtbegin.o"
// C-RV64IMAC-BAREMETAL-MULTI-LP64: "-L{{.*}}/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0"
// C-RV64IMAC-BAREMETAL-MULTI-LP64: "-L{{.*}}/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/../../..{{/|\\\\}}..{{/|\\\\}}riscv64-unknown-elf/lib"
// C-RV64IMAC-BAREMETAL-MULTI-LP64: "--start-group" "-lc" "-lgloss" "--end-group" "-lgcc"
// C-RV64IMAC-BAREMETAL-MULTI-LP64: "{{.*}}/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv64imac/lp64{{/|\\\\}}crtend.o"
// RUN: %clang %s -### -no-canonical-prefixes -fuse-ld=ld \
[RISCV] Use compiler-rt if no GCC installation detected If a GCC installation is not detected, then this attempts to use compiler-rt and the compiler-rt crtbegin/crtend implementations as a fallback. Differential Revision: https://reviews.llvm.org/D68407
2019-11-23 03:05:39 +08:00
// RUN: -target riscv64-unknown-elf --rtlib=platform --sysroot= \
// RUN: -march=rv64imafdc -mabi=lp64d \
[RISCV] Support mutilib in baremetal environment 1. Currently only support the set of multilibs same to riscv-gnu-toolchain. 2. Fix testcase typo causes fail on Windows. 3. Fix testcases to set empty sysroot. Reviewers: espindola, asb, kito-cheng, lenary Reviewed By: lenary Differential Revision: https://reviews.llvm.org/D67508
2019-11-21 17:12:48 +08:00
// RUN: --gcc-toolchain=%S/Inputs/multilib_riscv_elf_sdk 2>&1 \
// RUN: | FileCheck -check-prefix=C-RV64IMAFDC-BAREMETAL-MULTI-ILP64D %s
// C-RV64IMAFDC-BAREMETAL-MULTI-ILP64D: "{{.*}}/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/../../..{{/|\\\\}}..{{/|\\\\}}riscv64-unknown-elf/bin{{/|\\\\}}ld"
// C-RV64IMAFDC-BAREMETAL-MULTI-ILP64D: "-m" "elf64lriscv"
// C-RV64IMAFDC-BAREMETAL-MULTI-ILP64D: "{{.*}}/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/../../..{{/|\\\\}}..{{/|\\\\}}riscv64-unknown-elf/lib/rv64imafdc/lp64d{{/|\\\\}}crt0.o"
// C-RV64IMAFDC-BAREMETAL-MULTI-ILP64D: "{{.*}}/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv64imafdc/lp64d{{/|\\\\}}crtbegin.o"
// C-RV64IMAFDC-BAREMETAL-MULTI-ILP64D: "-L{{.*}}/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0"
// C-RV64IMAFDC-BAREMETAL-MULTI-ILP64D: "-L{{.*}}/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/../../..{{/|\\\\}}..{{/|\\\\}}riscv64-unknown-elf/lib"
// C-RV64IMAFDC-BAREMETAL-MULTI-ILP64D: "--start-group" "-lc" "-lgloss" "--end-group" "-lgcc"
// C-RV64IMAFDC-BAREMETAL-MULTI-ILP64D: "{{.*}}/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv64imafdc/lp64d{{/|\\\\}}crtend.o"
[RISCV] Use compiler-rt if no GCC installation detected If a GCC installation is not detected, then this attempts to use compiler-rt and the compiler-rt crtbegin/crtend implementations as a fallback. Differential Revision: https://reviews.llvm.org/D68407
2019-11-23 03:05:39 +08:00
// Check that --rtlib can be used to override the used runtime library
// RUN: %clang %s -### -no-canonical-prefixes \
[clang][Driver] Handle risvc in Baremetal.cpp. I am working on a baremetal riscv toolchain using LLVM runtime and LLD linker. Baremetal.cpp provides most of the things needed for such toolchain. So I have modified it to also handle riscv64/32-unknown-elf targets alongside arm-none-eabi. Currently, targets like riscv64-unknown-elf are handled by RISCVToolChain which mostly expects a gcc toolchain to be present. If you dont want the dependency on gcc-toolchain/libgloss or want to use LLD, then RISCVToolChain is not a good fit. So in the toolchain selection code, I have made this dependency of RISCVToolChain on gcc toolchain explicit. It is created if gcc-toolchain option is present. Otherwise Baremetal toolchain is created. I will be happy to hear if there is a better way to choose between these two toolchains. Reviewed By: jroelofs Differential Revision: https://reviews.llvm.org/D91442
2020-11-26 19:31:45 +08:00
// RUN: --gcc-toolchain=%S/Inputs/multilib_riscv_elf_sdk \
[RISCV] Use compiler-rt if no GCC installation detected If a GCC installation is not detected, then this attempts to use compiler-rt and the compiler-rt crtbegin/crtend implementations as a fallback. Differential Revision: https://reviews.llvm.org/D68407
2019-11-23 03:05:39 +08:00
// RUN: -target riscv64-unknown-elf --rtlib=libgcc 2>&1 \
// RUN: | FileCheck -check-prefix=C-RV64-RTLIB-LIBGCC-LP64 %s
// C-RV64-RTLIB-LIBGCC-LP64: "{{.*}}crt0.o"
// C-RV64-RTLIB-LIBGCC-LP64: "{{.*}}crtbegin.o"
// C-RV64-RTLIB-LIBGCC-LP64: "--start-group" "-lc" "-lgloss" "--end-group" "-lgcc"
// C-RV64-RTLIB-LIBGCC-LP64: "{{.*}}crtend.o"
// RUN: %clang %s -### -no-canonical-prefixes \
[clang][Driver] Handle risvc in Baremetal.cpp. I am working on a baremetal riscv toolchain using LLVM runtime and LLD linker. Baremetal.cpp provides most of the things needed for such toolchain. So I have modified it to also handle riscv64/32-unknown-elf targets alongside arm-none-eabi. Currently, targets like riscv64-unknown-elf are handled by RISCVToolChain which mostly expects a gcc toolchain to be present. If you dont want the dependency on gcc-toolchain/libgloss or want to use LLD, then RISCVToolChain is not a good fit. So in the toolchain selection code, I have made this dependency of RISCVToolChain on gcc toolchain explicit. It is created if gcc-toolchain option is present. Otherwise Baremetal toolchain is created. I will be happy to hear if there is a better way to choose between these two toolchains. Reviewed By: jroelofs Differential Revision: https://reviews.llvm.org/D91442
2020-11-26 19:31:45 +08:00
// RUN: --gcc-toolchain=%S/Inputs/multilib_riscv_elf_sdk \
[RISCV] Use compiler-rt if no GCC installation detected If a GCC installation is not detected, then this attempts to use compiler-rt and the compiler-rt crtbegin/crtend implementations as a fallback. Differential Revision: https://reviews.llvm.org/D68407
2019-11-23 03:05:39 +08:00
// RUN: -target riscv64-unknown-elf --rtlib=compiler-rt 2>&1 \
// RUN: | FileCheck -check-prefix=C-RV64-RTLIB-COMPILERRT-LP64 %s
// C-RV64-RTLIB-COMPILERRT-LP64: "{{.*}}crt0.o"
// C-RV64-RTLIB-COMPILERRT-LP64: "{{.*}}clang_rt.crtbegin-riscv64.o"
// C-RV64-RTLIB-COMPILERRT-LP64: "--start-group" "-lc" "-lgloss" "--end-group" "{{.*}}libclang_rt.builtins-riscv64.a"
// C-RV64-RTLIB-COMPILERRT-LP64: "{{.*}}clang_rt.crtend-riscv64.o"
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 21:36:56 +08:00
// RUN: %clang -target riscv64 %s -emit-llvm -S -o - | FileCheck %s
typedef __builtin_va_list va_list;
typedef __SIZE_TYPE__ size_t;
typedef __PTRDIFF_TYPE__ ptrdiff_t;
typedef __WCHAR_TYPE__ wchar_t;
[RISCV] Set MaxAtomicInlineWidth and MaxAtomicPromoteWidth for RV32/RV64 targets with atomics Summary: This ensures that libcalls aren't generated when the target supports atomics. Atomics aren't in the base RV32I/RV64I instruction sets, so MaxAtomicInlineWidth and MaxAtomicPromoteWidth are set only when the atomics extension is being targeted. This must be done in setMaxAtomicWidth, as this should be done after handleTargetFeatures has been called. Reviewers: jfb, jyknight, wmi, asb Reviewed By: asb Subscribers: pzheng, MaskRay, s.egerton, lenary, dexonsmith, psnobl, benna, Jim, JohnLLVM, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, lewis-revill, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57450 llvm-svn: 370073
2019-08-27 23:41:16 +08:00
typedef __WINT_TYPE__ wint_t;
// Check Alignments
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 21:36:56 +08:00
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: @align_c = dso_local global i32 1
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 21:36:56 +08:00
int align_c = __alignof(char);
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: @align_s = dso_local global i32 2
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 21:36:56 +08:00
int align_s = __alignof(short);
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: @align_i = dso_local global i32 4
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 21:36:56 +08:00
int align_i = __alignof(int);
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: @align_wc = dso_local global i32 4
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 21:36:56 +08:00
int align_wc = __alignof(wchar_t);
[RISCV] Set MaxAtomicInlineWidth and MaxAtomicPromoteWidth for RV32/RV64 targets with atomics Summary: This ensures that libcalls aren't generated when the target supports atomics. Atomics aren't in the base RV32I/RV64I instruction sets, so MaxAtomicInlineWidth and MaxAtomicPromoteWidth are set only when the atomics extension is being targeted. This must be done in setMaxAtomicWidth, as this should be done after handleTargetFeatures has been called. Reviewers: jfb, jyknight, wmi, asb Reviewed By: asb Subscribers: pzheng, MaskRay, s.egerton, lenary, dexonsmith, psnobl, benna, Jim, JohnLLVM, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, lewis-revill, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57450 llvm-svn: 370073
2019-08-27 23:41:16 +08:00
// CHECK: @align_wi = dso_local global i32 4
int align_wi = __alignof(wint_t);
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: @align_l = dso_local global i32 8
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 21:36:56 +08:00
int align_l = __alignof(long);
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: @align_ll = dso_local global i32 8
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 21:36:56 +08:00
int align_ll = __alignof(long long);
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: @align_p = dso_local global i32 8
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 21:36:56 +08:00
int align_p = __alignof(void*);
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: @align_f = dso_local global i32 4
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 21:36:56 +08:00
int align_f = __alignof(float);
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: @align_d = dso_local global i32 8
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 21:36:56 +08:00
int align_d = __alignof(double);
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: @align_ld = dso_local global i32 16
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 21:36:56 +08:00
int align_ld = __alignof(long double);
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: @align_vl = dso_local global i32 8
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 21:36:56 +08:00
int align_vl = __alignof(va_list);
[RISCV] Implement RISCV ABI lowering RISCVABIInfo is implemented in terms of XLen, supporting both RV32 and RV64. Unfortunately we need to count argument registers in the frontend in order to determine when to emit signext and zeroext attributes. Integer scalars are extended according to their type up to 32-bits and then sign-extended to XLen when passed in registers, but are anyext when passed on the stack. This patch only implements the base integer (soft float) ABIs. For more information on the RISC-V ABI, see [the ABI doc](https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md), my [golden model](https://github.com/lowRISC/riscv-calling-conv-model), and the [LLVM RISC-V calling convention patch](https://reviews.llvm.org/D39898#2d1595b4) (specifically the comment documenting frontend expectations). Differential Revision: https://reviews.llvm.org/D40023 llvm-svn: 322494
2018-01-16 01:54:52 +08:00
[RISCV] Set MaxAtomicInlineWidth and MaxAtomicPromoteWidth for RV32/RV64 targets with atomics Summary: This ensures that libcalls aren't generated when the target supports atomics. Atomics aren't in the base RV32I/RV64I instruction sets, so MaxAtomicInlineWidth and MaxAtomicPromoteWidth are set only when the atomics extension is being targeted. This must be done in setMaxAtomicWidth, as this should be done after handleTargetFeatures has been called. Reviewers: jfb, jyknight, wmi, asb Reviewed By: asb Subscribers: pzheng, MaskRay, s.egerton, lenary, dexonsmith, psnobl, benna, Jim, JohnLLVM, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, lewis-revill, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57450 llvm-svn: 370073
2019-08-27 23:41:16 +08:00
// CHECK: @align_a_c = dso_local global i32 1
int align_a_c = __alignof(_Atomic(char));
// CHECK: @align_a_s = dso_local global i32 2
int align_a_s = __alignof(_Atomic(short));
// CHECK: @align_a_i = dso_local global i32 4
int align_a_i = __alignof(_Atomic(int));
// CHECK: @align_a_wc = dso_local global i32 4
int align_a_wc = __alignof(_Atomic(wchar_t));
// CHECK: @align_a_wi = dso_local global i32 4
int align_a_wi = __alignof(_Atomic(wint_t));
// CHECK: @align_a_l = dso_local global i32 8
int align_a_l = __alignof(_Atomic(long));
// CHECK: @align_a_ll = dso_local global i32 8
int align_a_ll = __alignof(_Atomic(long long));
// CHECK: @align_a_p = dso_local global i32 8
int align_a_p = __alignof(_Atomic(void*));
[clang] Add missing FileCheck colons
2020-04-15 00:46:21 +08:00
// CHECK: @align_a_f = dso_local global i32 4
[RISCV] Set MaxAtomicInlineWidth and MaxAtomicPromoteWidth for RV32/RV64 targets with atomics Summary: This ensures that libcalls aren't generated when the target supports atomics. Atomics aren't in the base RV32I/RV64I instruction sets, so MaxAtomicInlineWidth and MaxAtomicPromoteWidth are set only when the atomics extension is being targeted. This must be done in setMaxAtomicWidth, as this should be done after handleTargetFeatures has been called. Reviewers: jfb, jyknight, wmi, asb Reviewed By: asb Subscribers: pzheng, MaskRay, s.egerton, lenary, dexonsmith, psnobl, benna, Jim, JohnLLVM, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, lewis-revill, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57450 llvm-svn: 370073
2019-08-27 23:41:16 +08:00
int align_a_f = __alignof(_Atomic(float));
// CHECK: @align_a_d = dso_local global i32 8
int align_a_d = __alignof(_Atomic(double));
// CHECK: @align_a_ld = dso_local global i32 16
int align_a_ld = __alignof(_Atomic(long double));
// CHECK: @align_a_s4 = dso_local global i32 4
int align_a_s4 = __alignof(_Atomic(struct { char _[4]; }));
// CHECK: @align_a_s8 = dso_local global i32 8
int align_a_s8 = __alignof(_Atomic(struct { char _[8]; }));
// CHECK: @align_a_s16 = dso_local global i32 16
int align_a_s16 = __alignof(_Atomic(struct { char _[16]; }));
// CHECK: @align_a_s32 = dso_local global i32 1
int align_a_s32 = __alignof(_Atomic(struct { char _[32]; }));
// Check Sizes
// CHECK: @size_a_c = dso_local global i32 1
int size_a_c = sizeof(_Atomic(char));
// CHECK: @size_a_s = dso_local global i32 2
int size_a_s = sizeof(_Atomic(short));
// CHECK: @size_a_i = dso_local global i32 4
int size_a_i = sizeof(_Atomic(int));
// CHECK: @size_a_wc = dso_local global i32 4
int size_a_wc = sizeof(_Atomic(wchar_t));
// CHECK: @size_a_wi = dso_local global i32 4
int size_a_wi = sizeof(_Atomic(wint_t));
// CHECK: @size_a_l = dso_local global i32 8
int size_a_l = sizeof(_Atomic(long));
// CHECK: @size_a_ll = dso_local global i32 8
int size_a_ll = sizeof(_Atomic(long long));
// CHECK: @size_a_p = dso_local global i32 8
int size_a_p = sizeof(_Atomic(void*));
// CHECK: @size_a_f = dso_local global i32 4
int size_a_f = sizeof(_Atomic(float));
// CHECK: @size_a_d = dso_local global i32 8
int size_a_d = sizeof(_Atomic(double));
// CHECK: @size_a_ld = dso_local global i32 16
int size_a_ld = sizeof(_Atomic(long double));
[RISCV] Implement RISCV ABI lowering RISCVABIInfo is implemented in terms of XLen, supporting both RV32 and RV64. Unfortunately we need to count argument registers in the frontend in order to determine when to emit signext and zeroext attributes. Integer scalars are extended according to their type up to 32-bits and then sign-extended to XLen when passed in registers, but are anyext when passed on the stack. This patch only implements the base integer (soft float) ABIs. For more information on the RISC-V ABI, see [the ABI doc](https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md), my [golden model](https://github.com/lowRISC/riscv-calling-conv-model), and the [LLVM RISC-V calling convention patch](https://reviews.llvm.org/D39898#2d1595b4) (specifically the comment documenting frontend expectations). Differential Revision: https://reviews.llvm.org/D40023 llvm-svn: 322494
2018-01-16 01:54:52 +08:00
// Check types
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: define dso_local zeroext i8 @check_char()
[RISCV] Implement RISCV ABI lowering RISCVABIInfo is implemented in terms of XLen, supporting both RV32 and RV64. Unfortunately we need to count argument registers in the frontend in order to determine when to emit signext and zeroext attributes. Integer scalars are extended according to their type up to 32-bits and then sign-extended to XLen when passed in registers, but are anyext when passed on the stack. This patch only implements the base integer (soft float) ABIs. For more information on the RISC-V ABI, see [the ABI doc](https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md), my [golden model](https://github.com/lowRISC/riscv-calling-conv-model), and the [LLVM RISC-V calling convention patch](https://reviews.llvm.org/D39898#2d1595b4) (specifically the comment documenting frontend expectations). Differential Revision: https://reviews.llvm.org/D40023 llvm-svn: 322494
2018-01-16 01:54:52 +08:00
char check_char() { return 0; }
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: define dso_local signext i16 @check_short()
[RISCV] Implement RISCV ABI lowering RISCVABIInfo is implemented in terms of XLen, supporting both RV32 and RV64. Unfortunately we need to count argument registers in the frontend in order to determine when to emit signext and zeroext attributes. Integer scalars are extended according to their type up to 32-bits and then sign-extended to XLen when passed in registers, but are anyext when passed on the stack. This patch only implements the base integer (soft float) ABIs. For more information on the RISC-V ABI, see [the ABI doc](https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md), my [golden model](https://github.com/lowRISC/riscv-calling-conv-model), and the [LLVM RISC-V calling convention patch](https://reviews.llvm.org/D39898#2d1595b4) (specifically the comment documenting frontend expectations). Differential Revision: https://reviews.llvm.org/D40023 llvm-svn: 322494
2018-01-16 01:54:52 +08:00
short check_short() { return 0; }
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: define dso_local signext i32 @check_int()
[RISCV] Implement RISCV ABI lowering RISCVABIInfo is implemented in terms of XLen, supporting both RV32 and RV64. Unfortunately we need to count argument registers in the frontend in order to determine when to emit signext and zeroext attributes. Integer scalars are extended according to their type up to 32-bits and then sign-extended to XLen when passed in registers, but are anyext when passed on the stack. This patch only implements the base integer (soft float) ABIs. For more information on the RISC-V ABI, see [the ABI doc](https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md), my [golden model](https://github.com/lowRISC/riscv-calling-conv-model), and the [LLVM RISC-V calling convention patch](https://reviews.llvm.org/D39898#2d1595b4) (specifically the comment documenting frontend expectations). Differential Revision: https://reviews.llvm.org/D40023 llvm-svn: 322494
2018-01-16 01:54:52 +08:00
int check_int() { return 0; }
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: define dso_local signext i32 @check_wchar_t()
[RISCV] Implement RISCV ABI lowering RISCVABIInfo is implemented in terms of XLen, supporting both RV32 and RV64. Unfortunately we need to count argument registers in the frontend in order to determine when to emit signext and zeroext attributes. Integer scalars are extended according to their type up to 32-bits and then sign-extended to XLen when passed in registers, but are anyext when passed on the stack. This patch only implements the base integer (soft float) ABIs. For more information on the RISC-V ABI, see [the ABI doc](https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md), my [golden model](https://github.com/lowRISC/riscv-calling-conv-model), and the [LLVM RISC-V calling convention patch](https://reviews.llvm.org/D39898#2d1595b4) (specifically the comment documenting frontend expectations). Differential Revision: https://reviews.llvm.org/D40023 llvm-svn: 322494
2018-01-16 01:54:52 +08:00
int check_wchar_t() { return 0; }
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: define dso_local i64 @check_long()
[RISCV] Implement RISCV ABI lowering RISCVABIInfo is implemented in terms of XLen, supporting both RV32 and RV64. Unfortunately we need to count argument registers in the frontend in order to determine when to emit signext and zeroext attributes. Integer scalars are extended according to their type up to 32-bits and then sign-extended to XLen when passed in registers, but are anyext when passed on the stack. This patch only implements the base integer (soft float) ABIs. For more information on the RISC-V ABI, see [the ABI doc](https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md), my [golden model](https://github.com/lowRISC/riscv-calling-conv-model), and the [LLVM RISC-V calling convention patch](https://reviews.llvm.org/D39898#2d1595b4) (specifically the comment documenting frontend expectations). Differential Revision: https://reviews.llvm.org/D40023 llvm-svn: 322494
2018-01-16 01:54:52 +08:00
long check_long() { return 0; }
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: define dso_local i64 @check_longlong()
[RISCV] Implement RISCV ABI lowering RISCVABIInfo is implemented in terms of XLen, supporting both RV32 and RV64. Unfortunately we need to count argument registers in the frontend in order to determine when to emit signext and zeroext attributes. Integer scalars are extended according to their type up to 32-bits and then sign-extended to XLen when passed in registers, but are anyext when passed on the stack. This patch only implements the base integer (soft float) ABIs. For more information on the RISC-V ABI, see [the ABI doc](https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md), my [golden model](https://github.com/lowRISC/riscv-calling-conv-model), and the [LLVM RISC-V calling convention patch](https://reviews.llvm.org/D39898#2d1595b4) (specifically the comment documenting frontend expectations). Differential Revision: https://reviews.llvm.org/D40023 llvm-svn: 322494
2018-01-16 01:54:52 +08:00
long long check_longlong() { return 0; }
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: define dso_local zeroext i8 @check_uchar()
[RISCV] Implement RISCV ABI lowering RISCVABIInfo is implemented in terms of XLen, supporting both RV32 and RV64. Unfortunately we need to count argument registers in the frontend in order to determine when to emit signext and zeroext attributes. Integer scalars are extended according to their type up to 32-bits and then sign-extended to XLen when passed in registers, but are anyext when passed on the stack. This patch only implements the base integer (soft float) ABIs. For more information on the RISC-V ABI, see [the ABI doc](https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md), my [golden model](https://github.com/lowRISC/riscv-calling-conv-model), and the [LLVM RISC-V calling convention patch](https://reviews.llvm.org/D39898#2d1595b4) (specifically the comment documenting frontend expectations). Differential Revision: https://reviews.llvm.org/D40023 llvm-svn: 322494
2018-01-16 01:54:52 +08:00
unsigned char check_uchar() { return 0; }
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: define dso_local zeroext i16 @check_ushort()
[RISCV] Implement RISCV ABI lowering RISCVABIInfo is implemented in terms of XLen, supporting both RV32 and RV64. Unfortunately we need to count argument registers in the frontend in order to determine when to emit signext and zeroext attributes. Integer scalars are extended according to their type up to 32-bits and then sign-extended to XLen when passed in registers, but are anyext when passed on the stack. This patch only implements the base integer (soft float) ABIs. For more information on the RISC-V ABI, see [the ABI doc](https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md), my [golden model](https://github.com/lowRISC/riscv-calling-conv-model), and the [LLVM RISC-V calling convention patch](https://reviews.llvm.org/D39898#2d1595b4) (specifically the comment documenting frontend expectations). Differential Revision: https://reviews.llvm.org/D40023 llvm-svn: 322494
2018-01-16 01:54:52 +08:00
unsigned short check_ushort() { return 0; }
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: define dso_local signext i32 @check_uint()
[RISCV] Implement RISCV ABI lowering RISCVABIInfo is implemented in terms of XLen, supporting both RV32 and RV64. Unfortunately we need to count argument registers in the frontend in order to determine when to emit signext and zeroext attributes. Integer scalars are extended according to their type up to 32-bits and then sign-extended to XLen when passed in registers, but are anyext when passed on the stack. This patch only implements the base integer (soft float) ABIs. For more information on the RISC-V ABI, see [the ABI doc](https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md), my [golden model](https://github.com/lowRISC/riscv-calling-conv-model), and the [LLVM RISC-V calling convention patch](https://reviews.llvm.org/D39898#2d1595b4) (specifically the comment documenting frontend expectations). Differential Revision: https://reviews.llvm.org/D40023 llvm-svn: 322494
2018-01-16 01:54:52 +08:00
unsigned int check_uint() { return 0; }
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: define dso_local i64 @check_ulong()
[RISCV] Implement RISCV ABI lowering RISCVABIInfo is implemented in terms of XLen, supporting both RV32 and RV64. Unfortunately we need to count argument registers in the frontend in order to determine when to emit signext and zeroext attributes. Integer scalars are extended according to their type up to 32-bits and then sign-extended to XLen when passed in registers, but are anyext when passed on the stack. This patch only implements the base integer (soft float) ABIs. For more information on the RISC-V ABI, see [the ABI doc](https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md), my [golden model](https://github.com/lowRISC/riscv-calling-conv-model), and the [LLVM RISC-V calling convention patch](https://reviews.llvm.org/D39898#2d1595b4) (specifically the comment documenting frontend expectations). Differential Revision: https://reviews.llvm.org/D40023 llvm-svn: 322494
2018-01-16 01:54:52 +08:00
unsigned long check_ulong() { return 0; }
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: define dso_local i64 @check_ulonglong()
[RISCV] Implement RISCV ABI lowering RISCVABIInfo is implemented in terms of XLen, supporting both RV32 and RV64. Unfortunately we need to count argument registers in the frontend in order to determine when to emit signext and zeroext attributes. Integer scalars are extended according to their type up to 32-bits and then sign-extended to XLen when passed in registers, but are anyext when passed on the stack. This patch only implements the base integer (soft float) ABIs. For more information on the RISC-V ABI, see [the ABI doc](https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md), my [golden model](https://github.com/lowRISC/riscv-calling-conv-model), and the [LLVM RISC-V calling convention patch](https://reviews.llvm.org/D39898#2d1595b4) (specifically the comment documenting frontend expectations). Differential Revision: https://reviews.llvm.org/D40023 llvm-svn: 322494
2018-01-16 01:54:52 +08:00
unsigned long long check_ulonglong() { return 0; }
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: define dso_local i64 @check_size_t()
[RISCV] Implement RISCV ABI lowering RISCVABIInfo is implemented in terms of XLen, supporting both RV32 and RV64. Unfortunately we need to count argument registers in the frontend in order to determine when to emit signext and zeroext attributes. Integer scalars are extended according to their type up to 32-bits and then sign-extended to XLen when passed in registers, but are anyext when passed on the stack. This patch only implements the base integer (soft float) ABIs. For more information on the RISC-V ABI, see [the ABI doc](https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md), my [golden model](https://github.com/lowRISC/riscv-calling-conv-model), and the [LLVM RISC-V calling convention patch](https://reviews.llvm.org/D39898#2d1595b4) (specifically the comment documenting frontend expectations). Differential Revision: https://reviews.llvm.org/D40023 llvm-svn: 322494
2018-01-16 01:54:52 +08:00
size_t check_size_t() { return 0; }
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: define dso_local float @check_float()
[RISCV] Implement RISCV ABI lowering RISCVABIInfo is implemented in terms of XLen, supporting both RV32 and RV64. Unfortunately we need to count argument registers in the frontend in order to determine when to emit signext and zeroext attributes. Integer scalars are extended according to their type up to 32-bits and then sign-extended to XLen when passed in registers, but are anyext when passed on the stack. This patch only implements the base integer (soft float) ABIs. For more information on the RISC-V ABI, see [the ABI doc](https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md), my [golden model](https://github.com/lowRISC/riscv-calling-conv-model), and the [LLVM RISC-V calling convention patch](https://reviews.llvm.org/D39898#2d1595b4) (specifically the comment documenting frontend expectations). Differential Revision: https://reviews.llvm.org/D40023 llvm-svn: 322494
2018-01-16 01:54:52 +08:00
float check_float() { return 0; }
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: define dso_local double @check_double()
[RISCV] Implement RISCV ABI lowering RISCVABIInfo is implemented in terms of XLen, supporting both RV32 and RV64. Unfortunately we need to count argument registers in the frontend in order to determine when to emit signext and zeroext attributes. Integer scalars are extended according to their type up to 32-bits and then sign-extended to XLen when passed in registers, but are anyext when passed on the stack. This patch only implements the base integer (soft float) ABIs. For more information on the RISC-V ABI, see [the ABI doc](https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md), my [golden model](https://github.com/lowRISC/riscv-calling-conv-model), and the [LLVM RISC-V calling convention patch](https://reviews.llvm.org/D39898#2d1595b4) (specifically the comment documenting frontend expectations). Differential Revision: https://reviews.llvm.org/D40023 llvm-svn: 322494
2018-01-16 01:54:52 +08:00
double check_double() { return 0; }
Recommit r324107 again. The difference from the previous try is that we no longer directly access function declarations from position independent executables. It should work, but currently doesn't with some linkers. It now includes a fix to not mark available_externally definitions as dso_local. Original message: Start setting dso_local in clang. This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324535
2018-02-08 06:15:33 +08:00
// CHECK: define dso_local fp128 @check_longdouble()
[RISCV] Implement RISCV ABI lowering RISCVABIInfo is implemented in terms of XLen, supporting both RV32 and RV64. Unfortunately we need to count argument registers in the frontend in order to determine when to emit signext and zeroext attributes. Integer scalars are extended according to their type up to 32-bits and then sign-extended to XLen when passed in registers, but are anyext when passed on the stack. This patch only implements the base integer (soft float) ABIs. For more information on the RISC-V ABI, see [the ABI doc](https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md), my [golden model](https://github.com/lowRISC/riscv-calling-conv-model), and the [LLVM RISC-V calling convention patch](https://reviews.llvm.org/D39898#2d1595b4) (specifically the comment documenting frontend expectations). Differential Revision: https://reviews.llvm.org/D40023 llvm-svn: 322494
2018-01-16 01:54:52 +08:00
long double check_longdouble() { return 0; }