r367403 - [RISCV] Support 'f' Inline Assembly Constraint
Author: lenary
Date: Wed Jul 31 02:45:55 2019
New Revision: 367403
URL: http://llvm.org/viewvc/llvm-project?rev=367403&view=rev
Log:
[RISCV] Support 'f' Inline Assembly Constraint
Summary:
This adds the 'f' inline assembly constraint, as supported by GCC. An
'f'-constrained operand is passed in a floating point register. Exactly
which kind of floating-point register (32-bit or 64-bit) is decided
based on the operand type and the available standard extensions (-f and
-d, respectively).
This patch adds support in both the clang frontend, and LLVM itself.
Reviewers: asb, lewis-revill
Reviewed By: asb
Subscribers: hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD,
kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01,
MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim,
s.egerton, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D65500
Modified:
cfe/trunk/lib/Basic/Targets/RISCV.cpp
cfe/trunk/test/CodeGen/riscv-inline-asm.c
Modified: cfe/trunk/lib/Basic/Targets/RISCV.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/RISCV.cpp?rev=367403&r1=367402&r2=367403&view=diff
==
--- cfe/trunk/lib/Basic/Targets/RISCV.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/RISCV.cpp Wed Jul 31 02:45:55 2019
@@ -71,6 +71,10 @@ bool RISCVTargetInfo::validateAsmConstra
// A 5-bit unsigned immediate for CSR access instructions.
Info.setRequiresImmediate(0, 31);
return true;
+ case 'f':
+// A floating-point register.
+Info.setAllowsRegister();
+return true;
}
}
Modified: cfe/trunk/test/CodeGen/riscv-inline-asm.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/riscv-inline-asm.c?rev=367403&r1=367402&r2=367403&view=diff
==
--- cfe/trunk/test/CodeGen/riscv-inline-asm.c (original)
+++ cfe/trunk/test/CodeGen/riscv-inline-asm.c Wed Jul 31 02:45:55 2019
@@ -26,3 +26,15 @@ void test_K() {
// CHECK: call void asm sideeffect "", "K"(i32 0)
asm volatile ("" :: "K"(0));
}
+
+float f;
+double d;
+void test_f() {
+// CHECK-LABEL: define void @test_f()
+// CHECK: [[FLT_ARG:%[a-zA-Z_0-9]+]] = load float, float* @f
+// CHECK: call void asm sideeffect "", "f"(float [[FLT_ARG]])
+ asm volatile ("" :: "f"(f));
+// CHECK: [[FLT_ARG:%[a-zA-Z_0-9]+]] = load double, double* @d
+// CHECK: call void asm sideeffect "", "f"(double [[FLT_ARG]])
+ asm volatile ("" :: "f"(d));
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r367557 - [RISCV] Add FreeBSD targets
Author: lenary
Date: Thu Aug 1 06:14:30 2019
New Revision: 367557
URL: http://llvm.org/viewvc/llvm-project?rev=367557&view=rev
Log:
[RISCV] Add FreeBSD targets
Reviewers: asb
Reviewed By: asb
Subscribers: simoncook, s.egerton, lenary, psnobl, benna, mhorne, emaste,
kito-cheng, shiva0217, rogfer01, rkruppe, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57795
Patch by James Clarke (jrtc27)
Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/lib/Driver/ToolChains/FreeBSD.cpp
cfe/trunk/test/Driver/freebsd.c
Modified: cfe/trunk/lib/Basic/Targets.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=367557&r1=367556&r2=367557&view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Thu Aug 1 06:14:30 2019
@@ -363,15 +363,26 @@ TargetInfo *AllocateTarget(const llvm::T
return new AMDGPUTargetInfo(Triple, Opts);
case llvm::Triple::riscv32:
-// TODO: add cases for FreeBSD, NetBSD, RTEMS once tested.
-if (os == llvm::Triple::Linux)
+// TODO: add cases for NetBSD, RTEMS once tested.
+switch (os) {
+case llvm::Triple::FreeBSD:
+ return new FreeBSDTargetInfo(Triple, Opts);
+case llvm::Triple::Linux:
return new LinuxTargetInfo(Triple, Opts);
-return new RISCV32TargetInfo(Triple, Opts);
+default:
+ return new RISCV32TargetInfo(Triple, Opts);
+}
+
case llvm::Triple::riscv64:
-// TODO: add cases for FreeBSD, NetBSD, RTEMS once tested.
-if (os == llvm::Triple::Linux)
+// TODO: add cases for NetBSD, RTEMS once tested.
+switch (os) {
+case llvm::Triple::FreeBSD:
+ return new FreeBSDTargetInfo(Triple, Opts);
+case llvm::Triple::Linux:
return new LinuxTargetInfo(Triple, Opts);
-return new RISCV64TargetInfo(Triple, Opts);
+default:
+ return new RISCV64TargetInfo(Triple, Opts);
+}
case llvm::Triple::sparc:
switch (os) {
Modified: cfe/trunk/lib/Driver/ToolChains/FreeBSD.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/FreeBSD.cpp?rev=367557&r1=367556&r2=367557&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/FreeBSD.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/FreeBSD.cpp Thu Aug 1 06:14:30 2019
@@ -197,6 +197,14 @@ void freebsd::Linker::ConstructJob(Compi
else
CmdArgs.push_back("elf64ltsmip_fbsd");
break;
+ case llvm::Triple::riscv32:
+CmdArgs.push_back("-m");
+CmdArgs.push_back("elf32lriscv");
+break;
+ case llvm::Triple::riscv64:
+CmdArgs.push_back("-m");
+CmdArgs.push_back("elf64lriscv");
+break;
default:
break;
}
Modified: cfe/trunk/test/Driver/freebsd.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/freebsd.c?rev=367557&r1=367556&r2=367557&view=diff
==
--- cfe/trunk/test/Driver/freebsd.c (original)
+++ cfe/trunk/test/Driver/freebsd.c Thu Aug 1 06:14:30 2019
@@ -63,6 +63,15 @@
// RUN: | FileCheck --check-prefix=CHECK-MIPSN32EL-LD %s
// CHECK-MIPSN32EL-LD: ld{{.*}}" {{.*}} "-m" "elf32ltsmipn32_fbsd"
//
+// Check that RISC-V passes the correct linker emulation.
+//
+// RUN: %clang -target riscv32-freebsd %s -### %s 2>&1 \
+// RUN: | FileCheck --check-prefix=CHECK-RV32I-LD %s
+// CHECK-RV32I-LD: ld{{.*}}" {{.*}} "-m" "elf32lriscv"
+// RUN: %clang -target riscv64-freebsd %s -### %s 2>&1 \
+// RUN: | FileCheck --check-prefix=CHECK-RV64I-LD %s
+// CHECK-RV64I-LD: ld{{.*}}" {{.*}} "-m" "elf64lriscv"
+//
// Check that the new linker flags are passed to FreeBSD
// RUN: %clang -no-canonical-prefixes -target x86_64-pc-freebsd8 -m32 %s \
// RUN: --sysroot=%S/Inputs/multiarch_freebsd64_tree -### 2>&1 \
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r367565 - Add support for openSUSE RISC-V triple
Author: lenary
Date: Thu Aug 1 07:23:56 2019
New Revision: 367565
URL: http://llvm.org/viewvc/llvm-project?rev=367565&view=rev
Log:
Add support for openSUSE RISC-V triple
Reviewers: asb
Reviewed By: asb
Subscribers: lenary, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD,
jrtc27, zzheng, edward-jones, MartinMosbeck, brucehoult, the_o, PkmX, jocewei,
lebedev.ri, kito-cheng, shiva0217, rogfer01, dexonsmith, rkruppe, cfe-commits,
llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D63497
Patch by Andreas Schwab (schwab)
Added:
cfe/trunk/test/Driver/Inputs/opensuse_tumbleweed_riscv64_tree/
cfe/trunk/test/Driver/Inputs/opensuse_tumbleweed_riscv64_tree/usr/
cfe/trunk/test/Driver/Inputs/opensuse_tumbleweed_riscv64_tree/usr/lib64/
cfe/trunk/test/Driver/Inputs/opensuse_tumbleweed_riscv64_tree/usr/lib64/crt1.o
cfe/trunk/test/Driver/Inputs/opensuse_tumbleweed_riscv64_tree/usr/lib64/crti.o
cfe/trunk/test/Driver/Inputs/opensuse_tumbleweed_riscv64_tree/usr/lib64/crtn.o
cfe/trunk/test/Driver/Inputs/opensuse_tumbleweed_riscv64_tree/usr/lib64/gcc/
cfe/trunk/test/Driver/Inputs/opensuse_tumbleweed_riscv64_tree/usr/lib64/gcc/riscv64-suse-linux/
cfe/trunk/test/Driver/Inputs/opensuse_tumbleweed_riscv64_tree/usr/lib64/gcc/riscv64-suse-linux/9/
cfe/trunk/test/Driver/Inputs/opensuse_tumbleweed_riscv64_tree/usr/lib64/gcc/riscv64-suse-linux/9/crtbegin.o
cfe/trunk/test/Driver/Inputs/opensuse_tumbleweed_riscv64_tree/usr/lib64/gcc/riscv64-suse-linux/9/crtend.o
Modified:
cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
cfe/trunk/test/Driver/linux-ld.c
Modified: cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Gnu.cpp?rev=367565&r1=367564&r2=367565&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Gnu.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Gnu.cpp Thu Aug 1 07:23:56 2019
@@ -2017,7 +2017,8 @@ void Generic_GCC::GCCInstallationDetecto
static const char *const RISCV64LibDirs[] = {"/lib64", "/lib"};
static const char *const RISCV64Triples[] = {"riscv64-unknown-linux-gnu",
"riscv64-linux-gnu",
- "riscv64-unknown-elf"};
+ "riscv64-unknown-elf",
+ "riscv64-suse-linux"};
static const char *const SPARCv8LibDirs[] = {"/lib32", "/lib"};
static const char *const SPARCv8Triples[] = {"sparc-linux-gnu",
Added:
cfe/trunk/test/Driver/Inputs/opensuse_tumbleweed_riscv64_tree/usr/lib64/crt1.o
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/opensuse_tumbleweed_riscv64_tree/usr/lib64/crt1.o?rev=367565&view=auto
==
(empty)
Added:
cfe/trunk/test/Driver/Inputs/opensuse_tumbleweed_riscv64_tree/usr/lib64/crti.o
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/opensuse_tumbleweed_riscv64_tree/usr/lib64/crti.o?rev=367565&view=auto
==
(empty)
Added:
cfe/trunk/test/Driver/Inputs/opensuse_tumbleweed_riscv64_tree/usr/lib64/crtn.o
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/opensuse_tumbleweed_riscv64_tree/usr/lib64/crtn.o?rev=367565&view=auto
==
(empty)
Added:
cfe/trunk/test/Driver/Inputs/opensuse_tumbleweed_riscv64_tree/usr/lib64/gcc/riscv64-suse-linux/9/crtbegin.o
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/opensuse_tumbleweed_riscv64_tree/usr/lib64/gcc/riscv64-suse-linux/9/crtbegin.o?rev=367565&view=auto
==
(empty)
Added:
cfe/trunk/test/Driver/Inputs/opensuse_tumbleweed_riscv64_tree/usr/lib64/gcc/riscv64-suse-linux/9/crtend.o
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/opensuse_tumbleweed_riscv64_tree/usr/lib64/gcc/riscv64-suse-linux/9/crtend.o?rev=367565&view=auto
==
(empty)
Modified: cfe/trunk/test/Driver/linux-ld.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/linux-ld.c?rev=367565&r1=367564&r2=367565&view=diff
==
--- cfe/trunk/test/Driver/linux-ld.c (original)
+++ cfe/trunk/test/Driver/linux-ld.c Thu Aug 1 07:23:56 2019
@@ -859,6 +859,26 @@
// CHECK-OPENSUSE-TW-ARMV7HL:
"{{.*}}/usr/lib/gcc/armv7hl-suse-linux-gnueabi/5{{/|}}crtend.o"
// CHECK-OPENSUSE-TW-ARMV7HL:
"{{.*}}/usr/lib/gcc/armv7hl-suse-linux-gnueabi/5/../../../../lib{{/|}}crtn.o"
//
+// Check openSUSE Tumbleweed on riscv64
+// RUN
r364018 - [RISC-V] Add -msave-restore and -mno-save-restore to clang driver
Author: lenary
Date: Fri Jun 21 03:03:31 2019
New Revision: 364018
URL: http://llvm.org/viewvc/llvm-project?rev=364018&view=rev
Log:
[RISC-V] Add -msave-restore and -mno-save-restore to clang driver
Summary:
The GCC RISC-V toolchain accepts `-msave-restore` and `-mno-save-restore`
to control whether libcalls are used for saving and restoring the stack within
prologues and epilogues.
Clang currently errors if someone passes -msave-restore or -mno-save-restore.
This means that people need to change build configurations to use clang. This
patch adds these flags, so that clang invocations can now match gcc.
As the RISC-V backend does not currently have a `save-restore` target feature,
we emit a warning if someone requests `-msave-restore`. LLVM does not error if
we pass the (unimplemented) target features `+save-restore` or `-save-restore`.
Reviewers: asb, luismarques
Reviewed By: asb
Subscribers: rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng,
shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult,
the_o, rkruppe, PkmX, jocewei, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D63498
Modified:
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp
cfe/trunk/test/Driver/riscv-features.c
Modified: cfe/trunk/include/clang/Driver/Options.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=364018&r1=364017&r2=364018&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Fri Jun 21 03:03:31 2019
@@ -2130,6 +2130,10 @@ def mrelax : Flag<["-"], "mrelax">, Grou
HelpText<"Enable linker relaxation">;
def mno_relax : Flag<["-"], "mno-relax">, Group,
HelpText<"Disable linker relaxation">;
+def msave_restore : Flag<["-"], "msave-restore">,
Group,
+ HelpText<"Enable using library calls for save and restore">;
+def mno_save_restore : Flag<["-"], "mno-save-restore">,
Group,
+ HelpText<"Disable using library calls for save and restore">;
def munaligned_access : Flag<["-"], "munaligned-access">,
Group,
HelpText<"Allow memory accesses to be unaligned (AArch32/AArch64 only)">;
Modified: cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp?rev=364018&r1=364017&r2=364018&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp Fri Jun 21 03:03:31 2019
@@ -358,6 +358,16 @@ void riscv::getRISCVTargetFeatures(const
else
Features.push_back("-relax");
+ // -mno-save-restore is default, unless -msave-restore is specified.
+ if (Args.hasFlag(options::OPT_msave_restore, options::OPT_mno_save_restore,
false)) {
+Features.push_back("+save-restore");
+// ... but we don't yet support +save-restore, so issue a warning.
+D.Diag(diag::warn_drv_clang_unsupported)
+ << Args.getLastArg(options::OPT_msave_restore)->getAsString(Args);
+ } else {
+Features.push_back("-save-restore");
+ }
+
// Now add any that the user explicitly requested on the command line,
// which may override the defaults.
handleTargetFeaturesGroup(Args, Features,
options::OPT_m_riscv_Features_Group);
Modified: cfe/trunk/test/Driver/riscv-features.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/riscv-features.c?rev=364018&r1=364017&r2=364018&view=diff
==
--- cfe/trunk/test/Driver/riscv-features.c (original)
+++ cfe/trunk/test/Driver/riscv-features.c Fri Jun 21 03:03:31 2019
@@ -3,11 +3,23 @@
// CHECK: fno-signed-char
+// RUN: %clang -target riscv32-unknown-elf -### %s 2>&1 | FileCheck %s
-check-prefix=DEFAULT
+
// RUN: %clang -target riscv32-unknown-elf -### %s -mrelax 2>&1 | FileCheck %s
-check-prefix=RELAX
// RUN: %clang -target riscv32-unknown-elf -### %s -mno-relax 2>&1 | FileCheck
%s -check-prefix=NO-RELAX
-// RUN: %clang -target riscv32-unknown-elf -### %s 2>&1 | FileCheck %s
-check-prefix=DEFAULT
// RELAX: "-target-feature" "+relax"
// NO-RELAX: "-target-feature" "-relax"
// DEFAULT: "-target-feature" "+relax"
// DEFAULT-NOT: "-target-feature" "-relax"
+
+// RUN: %clang -target riscv32-unknown-elf -### %s -msave-restore 2>&1 |
FileCheck %s -check-prefix=SAVE-RESTORE
+// RUN: %clang -target riscv32-unknown-elf -### %s -mno-save-restore 2>&1 |
FileCheck %s -check-prefix=NO-SAVE-RESTORE
+
+// SAVE-RESTORE: warning: the clang compiler does not support '-msave-restore'
+// DEFAULT-NOT: warning: the clang compiler does not support
+
+// SAVE-RESTORE: "-target-feature" "+save-restore"
+// NO-SAVE-RESTORE: "-target-feature" "-save-restore"
+// DEFAULT: "-target-feature" "-save-restore"
+//
r364777 - [RISCV] Avoid save-restore target feature warning
Author: lenary
Date: Mon Jul 1 07:53:56 2019
New Revision: 364777
URL: http://llvm.org/viewvc/llvm-project?rev=364777&view=rev
Log:
[RISCV] Avoid save-restore target feature warning
Summary:
LLVM issues a warning if passed unknown target features. Neither I nor
@asb noticed this until after https://reviews.llvm.org/D63498 landed.
This patch stops passing the (unknown) "save-restore" target feature to
the LLVM backend, but continues to emit a warning if a driver asks for
`-msave-restore`. The default of assuming `-mno-save-restore` (and
emitting no warnings) remains.
Reviewers: asb
Reviewed By: asb
Subscribers: rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng,
shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult,
the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, cfe-commits, asb
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64008
Modified:
cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp
cfe/trunk/test/Driver/riscv-features.c
Modified: cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp?rev=364777&r1=364776&r2=364777&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp Mon Jul 1 07:53:56 2019
@@ -358,14 +358,12 @@ void riscv::getRISCVTargetFeatures(const
else
Features.push_back("-relax");
- // -mno-save-restore is default, unless -msave-restore is specified.
+ // GCC Compatibility: -mno-save-restore is default, unless -msave-restore is
+ // specified...
if (Args.hasFlag(options::OPT_msave_restore, options::OPT_mno_save_restore,
false)) {
-Features.push_back("+save-restore");
-// ... but we don't yet support +save-restore, so issue a warning.
+// ... but we don't support -msave-restore, so issue a warning.
D.Diag(diag::warn_drv_clang_unsupported)
<< Args.getLastArg(options::OPT_msave_restore)->getAsString(Args);
- } else {
-Features.push_back("-save-restore");
}
// Now add any that the user explicitly requested on the command line,
Modified: cfe/trunk/test/Driver/riscv-features.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/riscv-features.c?rev=364777&r1=364776&r2=364777&view=diff
==
--- cfe/trunk/test/Driver/riscv-features.c (original)
+++ cfe/trunk/test/Driver/riscv-features.c Mon Jul 1 07:53:56 2019
@@ -17,9 +17,5 @@
// RUN: %clang -target riscv32-unknown-elf -### %s -mno-save-restore 2>&1 |
FileCheck %s -check-prefix=NO-SAVE-RESTORE
// SAVE-RESTORE: warning: the clang compiler does not support '-msave-restore'
-// DEFAULT-NOT: warning: the clang compiler does not support
-
-// SAVE-RESTORE: "-target-feature" "+save-restore"
-// NO-SAVE-RESTORE: "-target-feature" "-save-restore"
-// DEFAULT: "-target-feature" "-save-restore"
-// DEFAULT-NOT: "-target-feature" "+save-restore"
\ No newline at end of file
+// NO-SAVE-RESTORE-NOT: warning: the clang compiler does not support
+// DEFAULT-NOT: warning: the clang compiler does not support
\ No newline at end of file
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r374774 - [RISCV] enable LTO support, pass some options to linker.
Author: lenary
Date: Mon Oct 14 07:00:13 2019
New Revision: 374774
URL: http://llvm.org/viewvc/llvm-project?rev=374774&view=rev
Log:
[RISCV] enable LTO support, pass some options to linker.
Summary:
1. enable LTO need to pass target feature and abi to LTO code generation
RISCV backend need the target feature to decide which extension used in
code generation.
2. move getTargetFeatures to CommonArgs.h and add ForLTOPlugin flag
3. add general tools::getTargetABI in CommonArgs.h because different target
uses different
way to get the target ABI.
Patch by Kuan Hsu Chen (khchen)
Reviewers: lenary, lewis-revill, asb, MaskRay
Reviewed By: lenary
Subscribers: hiraditya, dschuff, aheejin, fedor.sergeev, mehdi_amini,
inglorion, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD,
kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, steven_wu,
rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, rkruppe, PkmX, jocewei,
psnobl, benna, Jim, lenary, s.egerton, pzheng, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67409
Modified:
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
cfe/trunk/lib/Driver/ToolChains/CommonArgs.h
cfe/trunk/lib/Driver/ToolChains/RISCVToolchain.cpp
cfe/trunk/lib/Driver/ToolChains/RISCVToolchain.h
cfe/trunk/test/Driver/gold-lto.c
Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=374774&r1=374773&r2=374774&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Mon Oct 14 07:00:13 2019
@@ -302,95 +302,6 @@ static void ParseMPreferVectorWidth(cons
}
}
-static void getWebAssemblyTargetFeatures(const ArgList &Args,
- std::vector &Features) {
- handleTargetFeaturesGroup(Args, Features,
options::OPT_m_wasm_Features_Group);
-}
-
-static void getTargetFeatures(const ToolChain &TC, const llvm::Triple &Triple,
- const ArgList &Args, ArgStringList &CmdArgs,
- bool ForAS) {
- const Driver &D = TC.getDriver();
- std::vector Features;
- switch (Triple.getArch()) {
- default:
-break;
- case llvm::Triple::mips:
- case llvm::Triple::mipsel:
- case llvm::Triple::mips64:
- case llvm::Triple::mips64el:
-mips::getMIPSTargetFeatures(D, Triple, Args, Features);
-break;
-
- case llvm::Triple::arm:
- case llvm::Triple::armeb:
- case llvm::Triple::thumb:
- case llvm::Triple::thumbeb:
-arm::getARMTargetFeatures(TC, Triple, Args, CmdArgs, Features, ForAS);
-break;
-
- case llvm::Triple::ppc:
- case llvm::Triple::ppc64:
- case llvm::Triple::ppc64le:
-ppc::getPPCTargetFeatures(D, Triple, Args, Features);
-break;
- case llvm::Triple::riscv32:
- case llvm::Triple::riscv64:
-riscv::getRISCVTargetFeatures(D, Triple, Args, Features);
-break;
- case llvm::Triple::systemz:
-systemz::getSystemZTargetFeatures(Args, Features);
-break;
- case llvm::Triple::aarch64:
- case llvm::Triple::aarch64_be:
-aarch64::getAArch64TargetFeatures(D, Triple, Args, Features);
-break;
- case llvm::Triple::x86:
- case llvm::Triple::x86_64:
-x86::getX86TargetFeatures(D, Triple, Args, Features);
-break;
- case llvm::Triple::hexagon:
-hexagon::getHexagonTargetFeatures(D, Args, Features);
-break;
- case llvm::Triple::wasm32:
- case llvm::Triple::wasm64:
-getWebAssemblyTargetFeatures(Args, Features);
-break;
- case llvm::Triple::sparc:
- case llvm::Triple::sparcel:
- case llvm::Triple::sparcv9:
-sparc::getSparcTargetFeatures(D, Args, Features);
-break;
- case llvm::Triple::r600:
- case llvm::Triple::amdgcn:
-amdgpu::getAMDGPUTargetFeatures(D, Args, Features);
-break;
- case llvm::Triple::msp430:
-msp430::getMSP430TargetFeatures(D, Args, Features);
- }
-
- // Find the last of each feature.
- llvm::StringMap LastOpt;
- for (unsigned I = 0, N = Features.size(); I < N; ++I) {
-StringRef Name = Features[I];
-assert(Name[0] == '-' || Name[0] == '+');
-LastOpt[Name.drop_front(1)] = I;
- }
-
- for (unsigned I = 0, N = Features.size(); I < N; ++I) {
-// If this feature was overridden, ignore it.
-StringRef Name = Features[I];
-llvm::StringMap::iterator LastI =
LastOpt.find(Name.drop_front(1));
-assert(LastI != LastOpt.end());
-unsigned Last = LastI->second;
-if (Last != I)
- continue;
-
-CmdArgs.push_back("-target-feature");
-CmdArgs.push_back(Name.data());
- }
-}
-
static bool
shouldUseExceptionTablesForObjCExceptions(const ObjCRuntime &runtime,
const llvm::Triple &Triple) {
Modified: cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Dri
[llvm] [flang] [clang] [NFC][AMDGPU] Move address space enum to LLVM directory (PR #73944)
lenary wrote: The reason TargetParser exists is because Target directories are only added to the include path if you enable that target, but some cross-project target code needs to always be available, such as the code for Triples, even when the relevant targets are disabled. I think these address space constants have the same needs, so this location makes sense to me, but I could be wrong. It is strange that the AMDGPU stuff is in the file called TargetParser.h, but that's because I wasn't able to move that code around when I originally split out TargetParser. Now might be a good time to put it in its own header, like was done for all other targets. https://github.com/llvm/llvm-project/pull/73944 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r370073 - [RISCV] Set MaxAtomicInlineWidth and MaxAtomicPromoteWidth for RV32/RV64 targets with atomics
Author: lenary
Date: Tue Aug 27 08:41:16 2019
New Revision: 370073
URL: http://llvm.org/viewvc/llvm-project?rev=370073&view=rev
Log:
[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
Added:
cfe/trunk/test/CodeGen/riscv-atomics.c
Modified:
cfe/trunk/lib/Basic/Targets/RISCV.h
cfe/trunk/test/Driver/riscv32-toolchain.c
cfe/trunk/test/Driver/riscv64-toolchain.c
Modified: cfe/trunk/lib/Basic/Targets/RISCV.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/RISCV.h?rev=370073&r1=370072&r2=370073&view=diff
==
--- cfe/trunk/lib/Basic/Targets/RISCV.h (original)
+++ cfe/trunk/lib/Basic/Targets/RISCV.h Tue Aug 27 08:41:16 2019
@@ -93,6 +93,13 @@ public:
}
return false;
}
+
+ void setMaxAtomicWidth() override {
+MaxAtomicPromoteWidth = 128;
+
+if (HasA)
+ MaxAtomicInlineWidth = 32;
+ }
};
class LLVM_LIBRARY_VISIBILITY RISCV64TargetInfo : public RISCVTargetInfo {
public:
@@ -110,6 +117,13 @@ public:
}
return false;
}
+
+ void setMaxAtomicWidth() override {
+MaxAtomicPromoteWidth = 128;
+
+if (HasA)
+ MaxAtomicInlineWidth = 64;
+ }
};
} // namespace targets
} // namespace clang
Added: cfe/trunk/test/CodeGen/riscv-atomics.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/riscv-atomics.c?rev=370073&view=auto
==
--- cfe/trunk/test/CodeGen/riscv-atomics.c (added)
+++ cfe/trunk/test/CodeGen/riscv-atomics.c Tue Aug 27 08:41:16 2019
@@ -0,0 +1,68 @@
+// RUN: %clang_cc1 -triple riscv32 -O1 -emit-llvm %s -o - \
+// RUN: | FileCheck %s -check-prefix=RV32I
+// RUN: %clang_cc1 -triple riscv32 -target-feature +a -O1 -emit-llvm %s -o - \
+// RUN: | FileCheck %s -check-prefix=RV32IA
+// RUN: %clang_cc1 -triple riscv64 -O1 -emit-llvm %s -o - \
+// RUN: | FileCheck %s -check-prefix=RV64I
+// RUN: %clang_cc1 -triple riscv64 -target-feature +a -O1 -emit-llvm %s -o - \
+// RUN: | FileCheck %s -check-prefix=RV64IA
+
+// This test demonstrates that MaxAtomicInlineWidth is set appropriately when
+// the atomics instruction set extension is enabled.
+
+#include
+#include
+
+void test_i8_atomics(_Atomic(int8_t) * a, int8_t b) {
+ // RV32I: call zeroext i8 @__atomic_load_1
+ // RV32I: call void @__atomic_store_1
+ // RV32I: call zeroext i8 @__atomic_fetch_add_1
+ // RV32IA: load atomic i8, i8* %a seq_cst, align 1
+ // RV32IA: store atomic i8 %b, i8* %a seq_cst, align 1
+ // RV32IA: atomicrmw add i8* %a, i8 %b seq_cst
+ // RV64I: call zeroext i8 @__atomic_load_1
+ // RV64I: call void @__atomic_store_1
+ // RV64I: call zeroext i8 @__atomic_fetch_add_1
+ // RV64IA: load atomic i8, i8* %a seq_cst, align 1
+ // RV64IA: store atomic i8 %b, i8* %a seq_cst, align 1
+ // RV64IA: atomicrmw add i8* %a, i8 %b seq_cst
+ __c11_atomic_load(a, memory_order_seq_cst);
+ __c11_atomic_store(a, b, memory_order_seq_cst);
+ __c11_atomic_fetch_add(a, b, memory_order_seq_cst);
+}
+
+void test_i32_atomics(_Atomic(int32_t) * a, int32_t b) {
+ // RV32I: call i32 @__atomic_load_4
+ // RV32I: call void @__atomic_store_4
+ // RV32I: call i32 @__atomic_fetch_add_4
+ // RV32IA: load atomic i32, i32* %a seq_cst, align 4
+ // RV32IA: store atomic i32 %b, i32* %a seq_cst, align 4
+ // RV32IA: atomicrmw add i32* %a, i32 %b seq_cst
+ // RV64I: call signext i32 @__atomic_load_4
+ // RV64I: call void @__atomic_store_4
+ // RV64I: call signext i32 @__atomic_fetch_add_4
+ // RV64IA: load atomic i32, i32* %a seq_cst, align 4
+ // RV64IA: store atomic i32 %b, i32* %a seq_cst, align 4
+ // RV64IA: atomicrmw add i32* %a, i32 %b seq_cst
+ __c11_atomic_load(a, memory_order_seq_cst);
+ __c11_atomic_store(a, b, memory_order_seq_cst);
+ __c11_atomic_fetch_add(a, b, memory_order_seq_cst);
+}
+
+void test_i64_atomics(_Atomic(int64_t) * a, int64_t b) {
+ // RV32I: call i64 @__atomic_load_8
+ // RV32I: call void @__atomic_store_8
+ // RV32I: call i64 @__atomic_fetch_add_8
+ // RV32IA: call i64 @__atomic_load_8
+ // RV32IA: call void @__atomic_store_8
+ // RV32I
r370709 - [RISCV] Correct Logic around ilp32e macros
Author: lenary
Date: Tue Sep 3 01:47:58 2019
New Revision: 370709
URL: http://llvm.org/viewvc/llvm-project?rev=370709&view=rev
Log:
[RISCV] Correct Logic around ilp32e macros
Summary:
GCC seperates the `__riscv_float_abi_*` macros and the
`__riscv_abi_rve` macro. If the chosen abi is ilp32e, `gcc -march=rv32i
-mabi=ilp32i -E -dM` shows that both `__riscv_float_abi_soft` and
`__riscv_abi_rve` are set.
This patch corrects the compiler logic around these defines.
At the moment, this patch will not change clang's behaviour, because we do not
accept the `ilp32e` abi yet.
Reviewers: luismarques, asb
Reviewed By: luismarques
Subscribers: rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng,
shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck,
brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton,
pzheng, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66591
Modified:
cfe/trunk/lib/Basic/Targets/RISCV.cpp
Modified: cfe/trunk/lib/Basic/Targets/RISCV.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/RISCV.cpp?rev=370709&r1=370708&r2=370709&view=diff
==
--- cfe/trunk/lib/Basic/Targets/RISCV.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/RISCV.cpp Tue Sep 3 01:47:58 2019
@@ -96,11 +96,12 @@ void RISCVTargetInfo::getTargetDefines(c
Builder.defineMacro("__riscv_float_abi_single");
else if (ABIName == "ilp32d" || ABIName == "lp64d")
Builder.defineMacro("__riscv_float_abi_double");
- else if (ABIName == "ilp32e")
-Builder.defineMacro("__riscv_abi_rve");
else
Builder.defineMacro("__riscv_float_abi_soft");
+ if (ABIName == "ilp32e")
+Builder.defineMacro("__riscv_abi_rve");
+
if (HasM) {
Builder.defineMacro("__riscv_mul");
Builder.defineMacro("__riscv_div");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r311347 - [clang] Fix tests for Emitting Single Inline Remark
Author: lenary
Date: Mon Aug 21 09:40:35 2017
New Revision: 311347
URL: http://llvm.org/viewvc/llvm-project?rev=311347&view=rev
Log:
[clang] Fix tests for Emitting Single Inline Remark
Summary: This change depends on https://reviews.llvm.org/D36054 and should be
landed at the same time.
Reviewers: anemet
Reviewed By: anemet
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D36949
Modified:
cfe/trunk/test/Frontend/optimization-remark-with-hotness.c
cfe/trunk/test/Frontend/optimization-remark.c
Modified: cfe/trunk/test/Frontend/optimization-remark-with-hotness.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/optimization-remark-with-hotness.c?rev=311347&r1=311346&r2=311347&view=diff
==
--- cfe/trunk/test/Frontend/optimization-remark-with-hotness.c (original)
+++ cfe/trunk/test/Frontend/optimization-remark-with-hotness.c Mon Aug 21
09:40:35 2017
@@ -56,8 +56,7 @@ void bar(int x) {
// THRESHOLD-NOT: hotness
// NO_PGO: '-fdiagnostics-show-hotness' requires profile-guided optimization
information
// NO_PGO: '-fdiagnostics-hotness-threshold=' requires profile-guided
optimization information
- // expected-remark@+2 {{foo should always be inlined (cost=always) (hotness:
30)}}
- // expected-remark@+1 {{foo inlined into bar (hotness: 30)}}
+ // expected-remark@+1 {{foo inlined into bar with cost=always}}
sum += foo(x, x - 2);
}
Modified: cfe/trunk/test/Frontend/optimization-remark.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/optimization-remark.c?rev=311347&r1=311346&r2=311347&view=diff
==
--- cfe/trunk/test/Frontend/optimization-remark.c (original)
+++ cfe/trunk/test/Frontend/optimization-remark.c Mon Aug 21 09:40:35 2017
@@ -42,9 +42,8 @@ float foz(int x, int y) { return x * y;
// twice.
//
int bar(int j) {
-// expected-remark@+4 {{foz not inlined into bar because it should never be
inlined (cost=never)}}
// expected-remark@+3 {{foz not inlined into bar because it should never be
inlined (cost=never)}}
-// expected-remark@+2 {{foo should always be inlined}}
+// expected-remark@+2 {{foz not inlined into bar because it should never be
inlined (cost=never)}}
// expected-remark@+1 {{foo inlined into bar}}
return foo(j, j - 2) * foz(j - 2, j);
}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] e3d5ff5 - [RISCV] Match GCC `-march`/`-mabi` driver defaults
Author: Sam Elliott
Date: 2019-11-15T15:10:42Z
New Revision: e3d5ff5a0b102febcddd9d58f24f18b00d4ecb4e
URL:
https://github.com/llvm/llvm-project/commit/e3d5ff5a0b102febcddd9d58f24f18b00d4ecb4e
DIFF:
https://github.com/llvm/llvm-project/commit/e3d5ff5a0b102febcddd9d58f24f18b00d4ecb4e.diff
LOG: [RISCV] Match GCC `-march`/`-mabi` driver defaults
Summary:
Clang/LLVM is a cross-compiler, and so we don't have to make a choice
about `-march`/`-mabi` at build-time, but we may have to compute a
default `-march`/`-mabi` when compiling a program. Until now, each
place that has needed a default `-march` has calculated one itself.
This patch adds a single place where a default `-march` is calculated,
in order to avoid calculating different defaults in different places.
This patch adds a new function `riscv::getRISCVArch` which encapsulates
this logic based on GCC's for computing a default `-march` value
when none is provided. This patch also updates the logic in
`riscv::getRISCVABI` to match the logic in GCC's build system for
computing a default `-mabi`.
This patch also updates anywhere that `-march` is used to now use the
new function which can compute a default. In particular, we now
explicitly pass a `-march` value down to the gnu assembler.
GCC has convoluted logic in its build system to choose a default
`-march`/`-mabi` based on build options, which would be good to match.
This patch is based on the logic in GCC 9.2.0. This commit's logic is
different to GCC's only for baremetal targets, where we default
to rv32imac/ilp32 or rv64imac/lp64 depending on the target triple.
Tests have been updated to match the new logic.
Reviewers: asb, luismarques, rogfer01, kito-cheng, khchen
Reviewed By: asb, luismarques
Subscribers: sameer.abuasal, rbar, johnrusso, simoncook, apazos, sabuasal,
niosHD, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, MartinMosbeck,
brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton,
pzheng, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69383
Added:
Modified:
clang/docs/ReleaseNotes.rst
clang/lib/Driver/ToolChains/Arch/RISCV.cpp
clang/lib/Driver/ToolChains/Arch/RISCV.h
clang/lib/Driver/ToolChains/Gnu.cpp
clang/test/Driver/riscv-abi.c
clang/test/Driver/riscv-gnutools.c
Removed:
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 1139116ed101..aa0d88db1c9f 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -223,6 +223,15 @@ ABI Changes in Clang
element. Clang now matches the gcc behavior on Linux and NetBSD. You can
switch back to old API behavior with flag: -fclang-abi-compat=9.0.
+- RISC-V now chooses a default ``-march=`` and ``-mabi=`` to match (in almost
+ all cases) the GCC defaults. On baremetal targets, where neither ``-march=``
+ nor ``-mabi=`` are specified, Clang now
diff ers from GCC by defaulting to
+ ``-march=rv32imac -mabi=ilp32`` or ``-march=rv64imac -mabi=lp64`` depending
on
+ the architecture in the target triple. These do not always match the defaults
+ in Clang 9. We strongly suggest that you explicitly pass `-march=` and
+ `-mabi=` when compiling for RISC-V, due to how extensible this architecture
+ is.
+
OpenMP Support in Clang
---
diff --git a/clang/lib/Driver/ToolChains/Arch/RISCV.cpp
b/clang/lib/Driver/ToolChains/Arch/RISCV.cpp
index a26f723a5073..8c343b8693f3 100644
--- a/clang/lib/Driver/ToolChains/Arch/RISCV.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/RISCV.cpp
@@ -357,14 +357,9 @@ static bool getArchFeatures(const Driver &D, StringRef
MArch,
void riscv::getRISCVTargetFeatures(const Driver &D, const llvm::Triple &Triple,
const ArgList &Args,
std::vector &Features) {
- llvm::Optional MArch;
- if (const Arg *A = Args.getLastArg(options::OPT_march_EQ))
-MArch = A->getValue();
- else if (Triple.getOS() == llvm::Triple::Linux)
-// RISC-V Linux defaults to rv{32,64}gc.
-MArch = Triple.getArch() == llvm::Triple::riscv32 ? "rv32gc" : "rv64gc";
+ StringRef MArch = getRISCVArch(Args, Triple);
- if (MArch.hasValue() && !getArchFeatures(D, *MArch, Features, Args))
+ if (!getArchFeatures(D, MArch, Features, Args))
return;
// Handle features corresponding to "-ffixed-X" options
@@ -455,12 +450,132 @@ StringRef riscv::getRISCVABI(const ArgList &Args, const
llvm::Triple &Triple) {
Triple.getArch() == llvm::Triple::riscv64) &&
"Unexpected triple");
+ // GCC's logic around choosing a default `-mabi=` is complex. If GCC is not
+ // configured using `--with-abi=`, then the logic for the default choice is
+ // defined in config.gcc. This function is based on the logic in GCC 9.2.0.
We
+ // deviate from GCC's default only on baremetal targets (UnknownOS) where
+ // neither `-march
[libunwind] ce3d1c6 - [libunwind][RISCV] Add 64-bit RISC-V support
Author: Sam Elliott
Date: 2019-12-16T16:36:56Z
New Revision: ce3d1c6d61dcd96f44492516f8b613bbcadaeb8e
URL:
https://github.com/llvm/llvm-project/commit/ce3d1c6d61dcd96f44492516f8b613bbcadaeb8e
DIFF:
https://github.com/llvm/llvm-project/commit/ce3d1c6d61dcd96f44492516f8b613bbcadaeb8e.diff
LOG: [libunwind][RISCV] Add 64-bit RISC-V support
Summary:
Add unwinding support for 64-bit RISC-V.
This is from the FreeBSD implementation with the following minor
changes:
- Renamed and renumbered DWARF registers to match the RISC-V ABI [1]
- Use the ABI mneumonics in getRegisterName() instead of the exact
register names
- Include checks for __riscv_xlen == 64 to facilitate adding the 32-bit
ABI in the future.
[1] https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md
Patch by Mitchell Horne (mhorne)
Reviewers: lenary, luismarques, compnerd, phosek
Reviewed By: lenary, luismarques
Subscribers: arichardson, sameer.abuasal, abidh, asb, aprantl, krytarowski,
simoncook, kito-cheng, christof, shiva0217, rogfer01, rkruppe, PkmX, psnobl,
benna, lenary, s.egerton, luismarques, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D68362
Added:
Modified:
libunwind/include/__libunwind_config.h
libunwind/include/libunwind.h
libunwind/src/Registers.hpp
libunwind/src/UnwindCursor.hpp
libunwind/src/UnwindRegistersRestore.S
libunwind/src/UnwindRegistersSave.S
libunwind/src/config.h
libunwind/src/libunwind.cpp
Removed:
diff --git a/libunwind/include/__libunwind_config.h
b/libunwind/include/__libunwind_config.h
index 6e7e5e6f7f86..4d03bd83d8c6 100644
--- a/libunwind/include/__libunwind_config.h
+++ b/libunwind/include/__libunwind_config.h
@@ -23,6 +23,7 @@
#define _LIBUNWIND_HIGHEST_DWARF_REGISTER_OR1K 32
#define _LIBUNWIND_HIGHEST_DWARF_REGISTER_MIPS 65
#define _LIBUNWIND_HIGHEST_DWARF_REGISTER_SPARC 31
+#define _LIBUNWIND_HIGHEST_DWARF_REGISTER_RISCV 64
#if defined(_LIBUNWIND_IS_NATIVE_ONLY)
# if defined(__i386__)
@@ -118,6 +119,15 @@
#define _LIBUNWIND_HIGHEST_DWARF_REGISTER
_LIBUNWIND_HIGHEST_DWARF_REGISTER_SPARC
#define _LIBUNWIND_CONTEXT_SIZE 16
#define _LIBUNWIND_CURSOR_SIZE 23
+# elif defined(__riscv)
+# if __riscv_xlen == 64
+#define _LIBUNWIND_TARGET_RISCV 1
+#define _LIBUNWIND_CONTEXT_SIZE 64
+#define _LIBUNWIND_CURSOR_SIZE 76
+# else
+#error "Unsupported RISC-V ABI"
+# endif
+# define _LIBUNWIND_HIGHEST_DWARF_REGISTER
_LIBUNWIND_HIGHEST_DWARF_REGISTER_RISCV
# else
# error "Unsupported architecture."
# endif
@@ -132,6 +142,7 @@
# define _LIBUNWIND_TARGET_MIPS_O32 1
# define _LIBUNWIND_TARGET_MIPS_NEWABI 1
# define _LIBUNWIND_TARGET_SPARC 1
+# define _LIBUNWIND_TARGET_RISCV 1
# define _LIBUNWIND_CONTEXT_SIZE 167
# define _LIBUNWIND_CURSOR_SIZE 179
# define _LIBUNWIND_HIGHEST_DWARF_REGISTER 287
diff --git a/libunwind/include/libunwind.h b/libunwind/include/libunwind.h
index d06724d3c31f..1a501b867dda 100644
--- a/libunwind/include/libunwind.h
+++ b/libunwind/include/libunwind.h
@@ -832,4 +832,75 @@ enum {
UNW_SPARC_I7 = 31,
};
+// RISC-V registers. These match the DWARF register numbers defined by section
+// 4 of the RISC-V ELF psABI specification, which can be found at:
+//
+// https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md
+enum {
+ UNW_RISCV_X0 = 0,
+ UNW_RISCV_X1 = 1,
+ UNW_RISCV_X2 = 2,
+ UNW_RISCV_X3 = 3,
+ UNW_RISCV_X4 = 4,
+ UNW_RISCV_X5 = 5,
+ UNW_RISCV_X6 = 6,
+ UNW_RISCV_X7 = 7,
+ UNW_RISCV_X8 = 8,
+ UNW_RISCV_X9 = 9,
+ UNW_RISCV_X10 = 10,
+ UNW_RISCV_X11 = 11,
+ UNW_RISCV_X12 = 12,
+ UNW_RISCV_X13 = 13,
+ UNW_RISCV_X14 = 14,
+ UNW_RISCV_X15 = 15,
+ UNW_RISCV_X16 = 16,
+ UNW_RISCV_X17 = 17,
+ UNW_RISCV_X18 = 18,
+ UNW_RISCV_X19 = 19,
+ UNW_RISCV_X20 = 20,
+ UNW_RISCV_X21 = 21,
+ UNW_RISCV_X22 = 22,
+ UNW_RISCV_X23 = 23,
+ UNW_RISCV_X24 = 24,
+ UNW_RISCV_X25 = 25,
+ UNW_RISCV_X26 = 26,
+ UNW_RISCV_X27 = 27,
+ UNW_RISCV_X28 = 28,
+ UNW_RISCV_X29 = 29,
+ UNW_RISCV_X30 = 30,
+ UNW_RISCV_X31 = 31,
+ UNW_RISCV_F0 = 32,
+ UNW_RISCV_F1 = 33,
+ UNW_RISCV_F2 = 34,
+ UNW_RISCV_F3 = 35,
+ UNW_RISCV_F4 = 36,
+ UNW_RISCV_F5 = 37,
+ UNW_RISCV_F6 = 38,
+ UNW_RISCV_F7 = 39,
+ UNW_RISCV_F8 = 40,
+ UNW_RISCV_F9 = 41,
+ UNW_RISCV_F10 = 42,
+ UNW_RISCV_F11 = 43,
+ UNW_RISCV_F12 = 44,
+ UNW_RISCV_F13 = 45,
+ UNW_RISCV_F14 = 46,
+ UNW_RISCV_F15 = 47,
+ UNW_RISCV_F16 = 48,
+ UNW_RISCV_F17 = 49,
+ UNW_RISCV_F18 = 50,
+ UNW_RISCV_F19 = 51,
+ UNW_RISCV_F20 = 52,
+ UNW_RISCV_F21 = 53,
+ UNW_RISCV_F22 = 54,
+ UNW_RISCV_F23 = 55,
+ UNW_RISCV_F24 = 56,
+ UNW_RISCV_F25 = 57,
+ UNW_RISCV_F26 = 58,
+ UNW_RISCV_F27 = 59,
+ UNW_RISCV_F28 = 60,
+ UNW_RISCV_F29 = 61,
+ UNW_RISCV_F30 = 62,
+ UNW_RISCV_F31 = 63,
+};
+
#endif
diff --git a/libunwind/src/Registers.hpp b/libunwind/src/Registers.hpp
in
[clang] [llvm] [AArch64] Implement GCS ACLE intrinsics (PR #96903)
@@ -855,6 +863,25 @@ __rndrrs(uint64_t *__p) {
}
#endif
+/* 11.2 Guarded Control Stack intrinsics */
+#if defined(__ARM_64BIT_STATE) && __ARM_64BIT_STATE
+static __inline__ void * __attribute__((__always_inline__, __nodebug__))
+__gcspr() {
+ return (void *)__builtin_arm_rsr64("gcspr_el0");
+}
+
+static __inline__ uint64_t __attribute__((__always_inline__, __nodebug__,
target("gcs")))
+__gcspopm() {
+ return __builtin_arm_gcspopm(0);
+}
+
+static __inline__ const void * __attribute__((__always_inline__, __nodebug__,
target("gcs")))
+__gcsss(const void *__stack) {
+ __builtin_arm_gcsss1(__stack);
+ return __builtin_arm_gcsss2(0);
+}
lenary wrote:
My concerns are:
- builtins eventually become a defacto compiler interface, with users using
them directly outside of compiler-only headers (and potentially expecting them
to be compatible between gcc and clang). Maybe this is fine, as we can reserve
the right to break them (but doing so is still not easy)? The other obvious
option is to match the builtin to the ACLE intrinsic, and write C++, as you
say, which is not as easy but also not necessarily any better as an
implementation.
- What happens if the compiler ends up separating these two operations? I guess
maybe we can leave this until it is a reported problem. Even if we had one
operation until isel, we might still have to make sure that reasonable
optimisations were prevented post-isel. I realise that the `sideEffects = 1` on
the instructions should prevent a lot of these, but I'm not clear on things
that should be side-effect safe but might interact with GCS such as Machine
Outliner.
https://github.com/llvm/llvm-project/pull/96903
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [RISCV] Allow YAML file to control multilib selection (PR #98856)
lenary wrote: @ArcaneNibble have you seen this RFC from Arm https://discourse.llvm.org/t/rfc-multilib-custom-flags/81058?u=lenary which I think would be useful for RISC-V too? https://github.com/llvm/llvm-project/pull/98856 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [RISCV] Add testcase for -mcmodel= (PR #107816)
https://github.com/lenary approved this pull request. https://github.com/llvm/llvm-project/pull/107816 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [RISCV] Allow -mcmodel= to accept large for RV64 (PR #107817)
lenary wrote: What's the status of backend support for the large code model? That would presumably be a prerequisite to landing this. https://github.com/llvm/llvm-project/pull/107817 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [RISCV] Allow -mcmodel= to accept large for RV64 (PR #107817)
lenary wrote: > > What's the status of backend support for the large code model? That would > > presumably be a prerequisite to landing this. > > It was just merged: #70308. I expected I was out of date, thanks for the link. The psABI says the large code model is not compatible with PIC - this presumably still applies to LLVM's implementation? If so, I think we need to add an unsupported error message in this case. https://github.com/llvm/llvm-project/pull/107817 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [RISCV] Emit predefined macro __riscv_cmodel_large for large code model (PR #108131)
lenary wrote: Reviewing on the basis this is stacked on top of #107817 https://github.com/llvm/llvm-project/pull/108131 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [RISCV] Emit predefined macro __riscv_cmodel_large for large code model (PR #108131)
https://github.com/lenary approved this pull request. https://github.com/llvm/llvm-project/pull/108131 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [RISCV] Allow -mcmodel= to accept large for RV64 (PR #107817)
https://github.com/lenary approved this pull request. LGTM, on the basis the preprocessor changes are in a different PR. https://github.com/llvm/llvm-project/pull/107817 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Add Hazard3 CPU (PR #102452)
lenary wrote: I've reached out to Luke to ask his/RPi's opinion (but I think he might be away at the moment, so a reply might be slow). My preference remains `raspberrypi-rp2350` because it matches our `-` approach taken so far (for everything except rocket). https://github.com/llvm/llvm-project/pull/102452 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][test] Split invalid-cpu-note tests (PR #104601)
https://github.com/lenary created https://github.com/llvm/llvm-project/pull/104601 This change does two kinds of splits: - Splits each target into a different file. Some targets are left in the same files, such as riscv32/64 and x86/_64 as these tests and lists are very similar. - Splits up the very long 'note:' lines which contain a list of CPUs, using `CHECK-SAME`. There was a note about this not being possible before, but with `--implicit-check-not`, this is now possible -- I have verified that this does the right thing if a single CPU anywhere in the list is left out. These tests had become quite annoying to change when adding a CPU, and I believe this change makes these easier to maintain, and should cut down on conflicts in these files (or at least makes conflicts easier to resolve). I apologise in advance for downstream conflicts, but hopefully that's a small amount of short term pain, in return for fewer conflicts in future. >From 0e9579c91242fc63eb2cb686adc105fd248fef91 Mon Sep 17 00:00:00 2001 From: Sam Elliott Date: Fri, 16 Aug 2024 07:52:53 -0700 Subject: [PATCH] [clang][test] Split invalid-cpu-note tests This change does two kinds of splits: - Splits each target into a different file. Some targets are left in the same files, such as riscv32/64 and x86/_64 as these tests and lists are very similar. - Splits up the very long 'note:' lines which contain a list of CPUs, using `CHECK-SAME`. There was a note about this not being possible before, but with `--implicit-check-not`, this is now possible -- I have verified that this does the right thing if a single CPU anywhere in the list is left out. These tests had become quite annoying to change when adding a CPU, and I believe this change makes these easier to maintain, and should cut down on conflicts in these files (or at least makes conflicts easier to resolve). I apologise in advance for downstream conflicts, but hopefully that's a small amount of short term pain, in return for fewer conflicts in future. --- clang/test/Misc/target-invalid-cpu-note.c | 96 - .../Misc/target-invalid-cpu-note/aarch64.c| 90 + .../Misc/target-invalid-cpu-note/amdgcn.c | 74 clang/test/Misc/target-invalid-cpu-note/arm.c | 98 + clang/test/Misc/target-invalid-cpu-note/avr.c | 320 +++ clang/test/Misc/target-invalid-cpu-note/bpf.c | 13 + .../Misc/target-invalid-cpu-note/hexagon.c| 19 + .../test/Misc/target-invalid-cpu-note/lanai.c | 7 + .../test/Misc/target-invalid-cpu-note/mips.c | 24 ++ .../test/Misc/target-invalid-cpu-note/nvptx.c | 78 .../Misc/target-invalid-cpu-note/powerpc.c| 71 .../test/Misc/target-invalid-cpu-note/r600.c | 32 ++ .../test/Misc/target-invalid-cpu-note/riscv.c | 89 .../test/Misc/target-invalid-cpu-note/sparc.c | 52 +++ .../Misc/target-invalid-cpu-note/systemz.c| 20 + .../test/Misc/target-invalid-cpu-note/wasm.c | 9 + clang/test/Misc/target-invalid-cpu-note/x86.c | 382 ++ 17 files changed, 1378 insertions(+), 96 deletions(-) delete mode 100644 clang/test/Misc/target-invalid-cpu-note.c create mode 100644 clang/test/Misc/target-invalid-cpu-note/aarch64.c create mode 100644 clang/test/Misc/target-invalid-cpu-note/amdgcn.c create mode 100644 clang/test/Misc/target-invalid-cpu-note/arm.c create mode 100644 clang/test/Misc/target-invalid-cpu-note/avr.c create mode 100644 clang/test/Misc/target-invalid-cpu-note/bpf.c create mode 100644 clang/test/Misc/target-invalid-cpu-note/hexagon.c create mode 100644 clang/test/Misc/target-invalid-cpu-note/lanai.c create mode 100644 clang/test/Misc/target-invalid-cpu-note/mips.c create mode 100644 clang/test/Misc/target-invalid-cpu-note/nvptx.c create mode 100644 clang/test/Misc/target-invalid-cpu-note/powerpc.c create mode 100644 clang/test/Misc/target-invalid-cpu-note/r600.c create mode 100644 clang/test/Misc/target-invalid-cpu-note/riscv.c create mode 100644 clang/test/Misc/target-invalid-cpu-note/sparc.c create mode 100644 clang/test/Misc/target-invalid-cpu-note/systemz.c create mode 100644 clang/test/Misc/target-invalid-cpu-note/wasm.c create mode 100644 clang/test/Misc/target-invalid-cpu-note/x86.c diff --git a/clang/test/Misc/target-invalid-cpu-note.c b/clang/test/Misc/target-invalid-cpu-note.c deleted file mode 100644 index b1783f3917a350..00 --- a/clang/test/Misc/target-invalid-cpu-note.c +++ /dev/null @@ -1,96 +0,0 @@ -// Use CHECK-NEXT instead of multiple CHECK-SAME to ensure we will fail if there is anything extra in the output. -// RUN: not %clang_cc1 -triple armv5--- -target-cpu not-a-cpu -fsyntax-only %s 2>&1 | FileCheck %s --check-prefix ARM -// ARM: error: unknown target CPU 'not-a-cpu' -// ARM-NEXT: note: valid target CPU values are: arm8, arm810, strongarm, strongarm110, strongarm1100, strongarm1110, arm7tdmi, arm7tdmi-s, arm710t, arm720t, arm9, arm9tdmi, arm920, arm920t, arm922t, arm940t, ep9312, arm10tdmi, arm1020t, arm9
[clang] [RISCV] Allow YAML file to control multilib selection (PR #98856)
https://github.com/lenary approved this pull request. I'm happy with this as a good first step to adopting the multilib YAML. Have you, using this patch, managed to reimplement the hardcoded multilib behaviour? This is not a blocking question, but it might give an indication of whether more work will be needed before this is widely usable. https://github.com/llvm/llvm-project/pull/98856 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][test] Split invalid-cpu-note tests (PR #104601)
@@ -0,0 +1,382 @@
+// Use --implicit-check-not={{[a-zA-Z0-9]}} to ensure no additional CPUs are
in these lists
+
+// RUN: not %clang_cc1 -triple i386--- -target-cpu not-a-cpu -fsyntax-only %s
2>&1 | FileCheck %s --check-prefix X86 --implicit-check-not={{[a-zA-Z0-9]}}
+// X86: error: unknown target CPU 'not-a-cpu'
+// X86-NEXT: note: valid target CPU values are:
+// X86-SAME: i386,
+// X86-SAME: i486,
+// X86-SAME: winchip-c6,
+// X86-SAME: winchip2,
+// X86-SAME: c3,
+// X86-SAME: i586,
+// X86-SAME: pentium,
+// X86-SAME: pentium-mmx,
+// X86-SAME: pentiumpro,
+// X86-SAME: i686,
+// X86-SAME: pentium2,
+// X86-SAME: pentium3,
+// X86-SAME: pentium3m,
+// X86-SAME: pentium-m,
+// X86-SAME: c3-2,
+// X86-SAME: yonah,
+// X86-SAME: pentium4,
+// X86-SAME: pentium4m,
+// X86-SAME: prescott,
+// X86-SAME: nocona,
+// X86-SAME: core2,
+// X86-SAME: penryn,
+// X86-SAME: bonnell,
+// X86-SAME: atom,
+// X86-SAME: silvermont,
+// X86-SAME: slm,
+// X86-SAME: goldmont,
+// X86-SAME: goldmont-plus,
+// X86-SAME: tremont,
+// X86-SAME: nehalem,
+// X86-SAME: corei7,
+// X86-SAME: westmere,
+// X86-SAME: sandybridge,
+// X86-SAME: corei7-avx,
+// X86-SAME: ivybridge,
+// X86-SAME: core-avx-i,
+// X86-SAME: haswell,
+// X86-SAME: core-avx2,
+// X86-SAME: broadwell,
+// X86-SAME: skylake,
+// X86-SAME: skylake-avx512,
+// X86-SAME: skx,
+// X86-SAME: cascadelake,
+// X86-SAME: cooperlake,
+// X86-SAME: cannonlake,
+// X86-SAME: icelake-client,
+// X86-SAME: rocketlake,
+// X86-SAME: icelake-server,
+// X86-SAME: tigerlake,
+// X86-SAME: sapphirerapids,
+// X86-SAME: alderlake,
+// X86-SAME: raptorlake,
+// X86-SAME: meteorlake,
+// X86-SAME: arrowlake,
+// X86-SAME: arrowlake-s,
+// X86-SAME: lunarlake,
+// X86-SAME: gracemont,
+// X86-SAME: pantherlake,
+// X86-SAME: sierraforest,
+// X86-SAME: grandridge,
+// X86-SAME: graniterapids,
+// X86-SAME: graniterapids-d,
+// X86-SAME: emeraldrapids,
+// X86-SAME: clearwaterforest,
+// X86-SAME: knl,
+// X86-SAME: knm,
+// X86-SAME: lakemont,
+// X86-SAME: k6,
+// X86-SAME: k6-2,
+// X86-SAME: k6-3,
+// X86-SAME: athlon,
+// X86-SAME: athlon-tbird,
+// X86-SAME: athlon-xp,
+// X86-SAME: athlon-mp,
+// X86-SAME: athlon-4,
+// X86-SAME: k8,
+// X86-SAME: athlon64,
+// X86-SAME: athlon-fx,
+// X86-SAME: opteron,
+// X86-SAME: k8-sse3,
+// X86-SAME: athlon64-sse3,
+// X86-SAME: opteron-sse3,
+// X86-SAME: amdfam10,
+// X86-SAME: barcelona,
+// X86-SAME: btver1,
+// X86-SAME: btver2,
+// X86-SAME: bdver1,
+// X86-SAME: bdver2,
+// X86-SAME: bdver3,
+// X86-SAME: bdver4,
+// X86-SAME: znver1,
+// X86-SAME: znver2,
+// X86-SAME: znver3,
+// X86-SAME: znver4,
+// X86-SAME: x86-64,
+// X86-SAME: x86-64-v2,
+// X86-SAME: x86-64-v3,
+// X86-SAME: x86-64-v4,
+// X86-SAME: geode
+// X86-SAME: {{$}}
+
+// RUN: not %clang_cc1 -triple x86_64--- -target-cpu not-a-cpu -fsyntax-only
%s 2>&1 | FileCheck %s --check-prefix=X86_64
--implicit-check-not={{[a-zA-Z0-9]}}
lenary wrote:
I'm keeping them "beside" their check lines, as was in the original tests. I
think this is more obvious when something breaks.
https://github.com/llvm/llvm-project/pull/104601
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Add Hazard3 CPU (PR #102452)
https://github.com/lenary updated
https://github.com/llvm/llvm-project/pull/102452
>From 0e9579c91242fc63eb2cb686adc105fd248fef91 Mon Sep 17 00:00:00 2001
From: Sam Elliott
Date: Fri, 16 Aug 2024 07:52:53 -0700
Subject: [PATCH 1/2] [clang][test] Split invalid-cpu-note tests
This change does two kinds of splits:
- Splits each target into a different file. Some targets are left in the
same files, such as riscv32/64 and x86/_64 as these tests and lists
are very similar.
- Splits up the very long 'note:' lines which contain a list of CPUs,
using `CHECK-SAME`. There was a note about this not being possible
before, but with `--implicit-check-not`, this is now possible -- I
have verified that this does the right thing if a single CPU anywhere
in the list is left out.
These tests had become quite annoying to change when adding a CPU, and I
believe this change makes these easier to maintain, and should cut down
on conflicts in these files (or at least makes conflicts easier to
resolve).
I apologise in advance for downstream conflicts, but hopefully that's a
small amount of short term pain, in return for fewer conflicts in
future.
---
clang/test/Misc/target-invalid-cpu-note.c | 96 -
.../Misc/target-invalid-cpu-note/aarch64.c| 90 +
.../Misc/target-invalid-cpu-note/amdgcn.c | 74
clang/test/Misc/target-invalid-cpu-note/arm.c | 98 +
clang/test/Misc/target-invalid-cpu-note/avr.c | 320 +++
clang/test/Misc/target-invalid-cpu-note/bpf.c | 13 +
.../Misc/target-invalid-cpu-note/hexagon.c| 19 +
.../test/Misc/target-invalid-cpu-note/lanai.c | 7 +
.../test/Misc/target-invalid-cpu-note/mips.c | 24 ++
.../test/Misc/target-invalid-cpu-note/nvptx.c | 78
.../Misc/target-invalid-cpu-note/powerpc.c| 71
.../test/Misc/target-invalid-cpu-note/r600.c | 32 ++
.../test/Misc/target-invalid-cpu-note/riscv.c | 89
.../test/Misc/target-invalid-cpu-note/sparc.c | 52 +++
.../Misc/target-invalid-cpu-note/systemz.c| 20 +
.../test/Misc/target-invalid-cpu-note/wasm.c | 9 +
clang/test/Misc/target-invalid-cpu-note/x86.c | 382 ++
17 files changed, 1378 insertions(+), 96 deletions(-)
delete mode 100644 clang/test/Misc/target-invalid-cpu-note.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/aarch64.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/amdgcn.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/arm.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/avr.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/bpf.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/hexagon.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/lanai.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/mips.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/nvptx.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/powerpc.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/r600.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/riscv.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/sparc.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/systemz.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/wasm.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/x86.c
diff --git a/clang/test/Misc/target-invalid-cpu-note.c
b/clang/test/Misc/target-invalid-cpu-note.c
deleted file mode 100644
index b1783f3917a350..00
--- a/clang/test/Misc/target-invalid-cpu-note.c
+++ /dev/null
@@ -1,96 +0,0 @@
-// Use CHECK-NEXT instead of multiple CHECK-SAME to ensure we will fail if
there is anything extra in the output.
-// RUN: not %clang_cc1 -triple armv5--- -target-cpu not-a-cpu -fsyntax-only %s
2>&1 | FileCheck %s --check-prefix ARM
-// ARM: error: unknown target CPU 'not-a-cpu'
-// ARM-NEXT: note: valid target CPU values are: arm8, arm810, strongarm,
strongarm110, strongarm1100, strongarm1110, arm7tdmi, arm7tdmi-s, arm710t,
arm720t, arm9, arm9tdmi, arm920, arm920t, arm922t, arm940t, ep9312, arm10tdmi,
arm1020t, arm9e, arm946e-s, arm966e-s, arm968e-s, arm10e, arm1020e, arm1022e,
arm926ej-s, arm1136j-s, arm1136jf-s, mpcore, mpcorenovfp, arm1176jz-s,
arm1176jzf-s, arm1156t2-s, arm1156t2f-s, cortex-m0, cortex-m0plus, cortex-m1,
sc000, cortex-a5, cortex-a7, cortex-a8, cortex-a9, cortex-a12, cortex-a15,
cortex-a17, krait, cortex-r4, cortex-r4f, cortex-r5, cortex-r7, cortex-r8,
cortex-r52, cortex-r52plus, sc300, cortex-m3, cortex-m4, cortex-m7, cortex-m23,
cortex-m33, cortex-m35p, cortex-m55, cortex-m85, cortex-m52, cortex-a32,
cortex-a35, cortex-a53, cortex-a55, cortex-a57, cortex-a72, cortex-a73,
cortex-a75, cortex-a76, cortex-a76ae, cortex-a77, cortex-a78, cortex-a78ae,
cortex-a78c, cortex-a710, cortex-x1, cortex-x1c, neoverse-n1, neoverse-n2,
neoverse-v1, cyclone, exynos-m3, exynos-m4, exynos-m5, kryo, iwmmxt, xscale,
swift{{$}}
-
-// RUN: not %clang_cc1 -tripl
[clang] [llvm] [RISCV] Add Hazard3 CPU (PR #102452)
https://github.com/lenary updated
https://github.com/llvm/llvm-project/pull/102452
>From 0e9579c91242fc63eb2cb686adc105fd248fef91 Mon Sep 17 00:00:00 2001
From: Sam Elliott
Date: Fri, 16 Aug 2024 07:52:53 -0700
Subject: [PATCH 1/2] [clang][test] Split invalid-cpu-note tests
This change does two kinds of splits:
- Splits each target into a different file. Some targets are left in the
same files, such as riscv32/64 and x86/_64 as these tests and lists
are very similar.
- Splits up the very long 'note:' lines which contain a list of CPUs,
using `CHECK-SAME`. There was a note about this not being possible
before, but with `--implicit-check-not`, this is now possible -- I
have verified that this does the right thing if a single CPU anywhere
in the list is left out.
These tests had become quite annoying to change when adding a CPU, and I
believe this change makes these easier to maintain, and should cut down
on conflicts in these files (or at least makes conflicts easier to
resolve).
I apologise in advance for downstream conflicts, but hopefully that's a
small amount of short term pain, in return for fewer conflicts in
future.
---
clang/test/Misc/target-invalid-cpu-note.c | 96 -
.../Misc/target-invalid-cpu-note/aarch64.c| 90 +
.../Misc/target-invalid-cpu-note/amdgcn.c | 74
clang/test/Misc/target-invalid-cpu-note/arm.c | 98 +
clang/test/Misc/target-invalid-cpu-note/avr.c | 320 +++
clang/test/Misc/target-invalid-cpu-note/bpf.c | 13 +
.../Misc/target-invalid-cpu-note/hexagon.c| 19 +
.../test/Misc/target-invalid-cpu-note/lanai.c | 7 +
.../test/Misc/target-invalid-cpu-note/mips.c | 24 ++
.../test/Misc/target-invalid-cpu-note/nvptx.c | 78
.../Misc/target-invalid-cpu-note/powerpc.c| 71
.../test/Misc/target-invalid-cpu-note/r600.c | 32 ++
.../test/Misc/target-invalid-cpu-note/riscv.c | 89
.../test/Misc/target-invalid-cpu-note/sparc.c | 52 +++
.../Misc/target-invalid-cpu-note/systemz.c| 20 +
.../test/Misc/target-invalid-cpu-note/wasm.c | 9 +
clang/test/Misc/target-invalid-cpu-note/x86.c | 382 ++
17 files changed, 1378 insertions(+), 96 deletions(-)
delete mode 100644 clang/test/Misc/target-invalid-cpu-note.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/aarch64.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/amdgcn.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/arm.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/avr.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/bpf.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/hexagon.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/lanai.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/mips.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/nvptx.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/powerpc.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/r600.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/riscv.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/sparc.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/systemz.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/wasm.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/x86.c
diff --git a/clang/test/Misc/target-invalid-cpu-note.c
b/clang/test/Misc/target-invalid-cpu-note.c
deleted file mode 100644
index b1783f3917a350..00
--- a/clang/test/Misc/target-invalid-cpu-note.c
+++ /dev/null
@@ -1,96 +0,0 @@
-// Use CHECK-NEXT instead of multiple CHECK-SAME to ensure we will fail if
there is anything extra in the output.
-// RUN: not %clang_cc1 -triple armv5--- -target-cpu not-a-cpu -fsyntax-only %s
2>&1 | FileCheck %s --check-prefix ARM
-// ARM: error: unknown target CPU 'not-a-cpu'
-// ARM-NEXT: note: valid target CPU values are: arm8, arm810, strongarm,
strongarm110, strongarm1100, strongarm1110, arm7tdmi, arm7tdmi-s, arm710t,
arm720t, arm9, arm9tdmi, arm920, arm920t, arm922t, arm940t, ep9312, arm10tdmi,
arm1020t, arm9e, arm946e-s, arm966e-s, arm968e-s, arm10e, arm1020e, arm1022e,
arm926ej-s, arm1136j-s, arm1136jf-s, mpcore, mpcorenovfp, arm1176jz-s,
arm1176jzf-s, arm1156t2-s, arm1156t2f-s, cortex-m0, cortex-m0plus, cortex-m1,
sc000, cortex-a5, cortex-a7, cortex-a8, cortex-a9, cortex-a12, cortex-a15,
cortex-a17, krait, cortex-r4, cortex-r4f, cortex-r5, cortex-r7, cortex-r8,
cortex-r52, cortex-r52plus, sc300, cortex-m3, cortex-m4, cortex-m7, cortex-m23,
cortex-m33, cortex-m35p, cortex-m55, cortex-m85, cortex-m52, cortex-a32,
cortex-a35, cortex-a53, cortex-a55, cortex-a57, cortex-a72, cortex-a73,
cortex-a75, cortex-a76, cortex-a76ae, cortex-a77, cortex-a78, cortex-a78ae,
cortex-a78c, cortex-a710, cortex-x1, cortex-x1c, neoverse-n1, neoverse-n2,
neoverse-v1, cyclone, exynos-m3, exynos-m4, exynos-m5, kryo, iwmmxt, xscale,
swift{{$}}
-
-// RUN: not %clang_cc1 -tripl
[clang] [llvm] [RISCV] Add Hazard3 CPU (PR #102452)
lenary wrote: I've updated this and gone with `rp2350-hazard3` as that's the prevailing consensus. This is stacked on #104601 because i got fed up with the invalid cpu note tests. Otherwise it's ready to review. https://github.com/llvm/llvm-project/pull/102452 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Add Hazard3 CPU (PR #102452)
https://github.com/lenary ready_for_review https://github.com/llvm/llvm-project/pull/102452 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Driver] Default -msmall-data-limit= to 0 and clean up code (PR #83093)
lenary wrote: I was a reviewer on the original patch, and I can see that I let some not great things through - claiming options that should not have been claimed, etc. I also do think that the situation has changed since then - more platform defaults are opting out of the sbss/sdata optimisation than opting into it, and the GP relaxation is now off-by-default in LLD. I'm not sure how the default was chosen, or how representative it is, so I'm happy with this, as any toolchains can use configuration files for e.g. baremetal configurations. A lot of choice around the "right" value is going to heavily depend on the specific application, I expect (and probably also the word size, which hasn't been taken into account by this default anyway). https://github.com/llvm/llvm-project/pull/83093 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Driver] Default -msmall-data-limit= to 0 and clean up code (PR #83093)
https://github.com/lenary approved this pull request. https://github.com/llvm/llvm-project/pull/83093 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][NFC] Split invalid-cpu-note tests (PR #104601)
https://github.com/lenary edited https://github.com/llvm/llvm-project/pull/104601 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Driver] Rearrange some Apple version testing (PR #94514)
@@ -0,0 +1,9 @@ +; Test emitting version_min directives. + +; RUN: llc %s -filetype=asm -o - --mtriple arm64-apple-tvos9.0.0 | FileCheck %s --check-prefix=TVOS lenary wrote: This is not the right directory for AArch64 tests (which apple calls `arm64` in its triples), these tests will only be run if the ARM backend is enabled, whereas I think this line only wants to be run if the AArch64 backend is enabled. https://github.com/llvm/llvm-project/pull/94514 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Driver] Rearrange some Apple version testing (PR #94514)
@@ -0,0 +1,9 @@ +; Test emitting version_min directives. + +; RUN: llc %s -filetype=asm -o - --mtriple arm64-apple-tvos9.0.0 | FileCheck %s --check-prefix=TVOS lenary wrote: That fix makes sense to me. Thanks! https://github.com/llvm/llvm-project/pull/94514 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64] Implement GCS ACLE intrinsics (PR #96903)
https://github.com/lenary approved this pull request. Thanks, LGTM. As a follow-up, can you check that the instructions generated from this builtin do inhibit the machine outliner? Maybe all GCS-modifying functions have to inhibit the machine outliner, I'm not 100% sure. https://github.com/llvm/llvm-project/pull/96903 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64] Implement GCS ACLE intrinsics (PR #96903)
https://github.com/lenary approved this pull request. LGTM. https://github.com/llvm/llvm-project/pull/96903 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [llvm][AArch64] apple-m4 is armv9.2-a (PR #98267)
https://github.com/lenary approved this pull request. https://github.com/llvm/llvm-project/pull/98267 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64] Make user-visible Arm architecture version strings consistent (PR #98550)
@@ -89,14 +89,14 @@ def FeatureCrypto : ExtensionWithMArch<"crypto", "Crypto", "FEAT_Crypto", "Enable cryptographic instructions", [FeatureNEON, FeatureSHA2, FeatureAES]>; def FeatureCRC : ExtensionWithMArch<"crc", "CRC", "FEAT_CRC32", - "Enable ARMv8 CRC-32 checksum instructions">; + "Enable Armv8.0-A CRC-32 checksum instructions">; // This SubtargetFeature is special. It controls only whether codegen will turn // `llvm.readcyclecounter()` into an access to a PMUv3 System Register. The // `FEAT_PMUv3*` system registers are always available for assembly/disassembly. let UserVisibleName = "pmuv3" in def FeaturePerfMon : ExtensionWithMArch<"perfmon", "PerfMon", "FEAT_PMUv3", - "Enable Code Generation for ARMv8 PMUv3 Performance Monitors extension">; + "Enable Armv8.0-A Code Generation for PMUv3 Performance Monitors extension">; lenary wrote: This feature is different to the rest. the system registers for PMUv3 are always enabled for asm/disasm, this feature just says whether some intrinsics generate system register accesses. https://github.com/llvm/llvm-project/pull/98550 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [FMV][AArch64] Don't optimize backward compatible features in resolver. (PR #90928)
lenary wrote: Is this check even right for MTE? FEAT_MTE uses encodings that are undefined (rather than nop-compatible) in the base architecture, even though those encodings are not doing tag checking until you enable at least FEAT_MTE2 - so I cannot execute e.g. `IRG` on a base armv8.0a architecture. https://github.com/llvm/llvm-project/pull/90928 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] [RISCV] Allow libunwind to build for rv32e (PR #98855)
@@ -1169,7 +1169,11 @@ DEFINE_LIBUNWIND_FUNCTION(_ZN9libunwind15Registers_riscv6jumptoEv) ILOAD x\i, (RISCV_ISIZE * \i)(a0) .endr // skip a0 for now +#if defined(__riscv_abi_rve) lenary wrote: I don't understand how the non-e version of this list relates to either the ABI or the architecture, so it's really hard to know what this should be doing in the e case. I'm also somewhat surprised that the list in this function is different from the one below, in save function. Shouldn't these be somewhat symmetric (barring having to do things with a few registers which represent unwinder state, like in this case `a0`). The non-e version is restoring all the argument registers, some (not all) of the callee-saves, and some (not all) of the temporary registers. Are there good docs as to why it is doing so? I think we might need to restore according to the architecture rather than the ABI, so that we restore live temporary registers correctly, but I'm not entirely sure, and if i could understand what the non-e case was doing better, I'd be able to give a clearer steer as to which this should be based on. https://github.com/llvm/llvm-project/pull/98855 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [RISCV] Allow YAML file to control multilib selection (PR #98856)
@@ -258,6 +259,13 @@ static void getARMMultilibFlags(const Driver &D,
}
}
+static void getRISCVMultilibFlags(const Driver &D, const llvm::Triple &Triple,
+ const llvm::opt::ArgList &Args,
+ Multilib::flags_list &Result) {
+ Result.push_back("-march=" + riscv::getRISCVArch(Args, Triple));
lenary wrote:
I think that the arch string used here should be normalised using RISCVISAInfo
- so that matching is much easier. I think this might throw up some issues when
clang changes the version of an extension it implements, but likely you have to
check your library build/configuration when that happens anyway, i think.
https://github.com/llvm/llvm-project/pull/98856
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] [RISCV] Allow libunwind to build for rv32e (PR #98855)
@@ -1169,7 +1169,11 @@ DEFINE_LIBUNWIND_FUNCTION(_ZN9libunwind15Registers_riscv6jumptoEv) ILOAD x\i, (RISCV_ISIZE * \i)(a0) .endr // skip a0 for now +#if defined(__riscv_abi_rve) lenary wrote: > The non-e case seems to be saving/restoring all registers (just like every > other architecture)? I'm not sure where you're seeing that it doesn't save > all of them? Sorry, my fault, I didn't realise there were two loops in this function and thus two different lists of registers. > > The reason the lists aren't symmetric is because register a0 is x10, so > restoring it is deferred until the end. I'm not sure why it doesn't just use > one list, but this pattern is also used for MIPS and LoongArch. Yeah, I'm happy with this. Broadly, going back to your/craig's original question: I feel this should be keyed on architecture, not ABI. This function is restoring all registers, including temporaries, not just caller-saves, so on the e-abi it should be restoring all temporaries as well. (This is different to my change to the save/restore routines, which only touch callee-saves). https://github.com/llvm/llvm-project/pull/98855 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] [RISCV] Allow libunwind to build for rv32e (PR #98855)
@@ -1169,7 +1169,11 @@ DEFINE_LIBUNWIND_FUNCTION(_ZN9libunwind15Registers_riscv6jumptoEv) ILOAD x\i, (RISCV_ISIZE * \i)(a0) .endr // skip a0 for now +#if defined(__riscv_abi_rve) lenary wrote: > Okay, I apparently did not realize that you can explicitly force > `-march=rv32i -mabi=ilp32e` in which case clang will indeed start using > x16-x31 as temporaries. This means that `__riscv_32e` is probably the correct > define to be checking. I will update the PR. Yeah, the intention here is that you should be able to use an E-abi library on the I architecture, without modification. If you compile your app for the I architecture to get additional temporaries, then you need to make sure you use a libunwind that knows about the additional temporaries it might need to restore. > Incidentally, does this mean that MIPS soft-float-ABI-but-FPU-enabled might > be buggy? Sounds like it could be, but I'm no MIPS expert. https://github.com/llvm/llvm-project/pull/98855 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] [RISCV] Allow libunwind to build for rv32e (PR #98855)
https://github.com/lenary approved this pull request. I'm happy with this from a RISC-V arch/abi point of view. https://github.com/llvm/llvm-project/pull/98855 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [RISCV] Allow YAML file to control multilib selection (PR #98856)
@@ -258,6 +259,13 @@ static void getARMMultilibFlags(const Driver &D,
}
}
+static void getRISCVMultilibFlags(const Driver &D, const llvm::Triple &Triple,
+ const llvm::opt::ArgList &Args,
+ Multilib::flags_list &Result) {
+ Result.push_back("-march=" + riscv::getRISCVArch(Args, Triple));
lenary wrote:
the discourse thread also contains suggestions about splitting up each
extension into a different flag - I'm not opposed to an approach like that
either, and it might make creating a multilib config which matches the existing
behaviour a lot easier.
https://github.com/llvm/llvm-project/pull/98856
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] [RISCV] Allow libunwind to build for rv32e (PR #98855)
lenary wrote: @ArcaneNibble your contributions now definitely meet the threshold for commit access - please request it following the instructions in the Developer Policy: https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access (also take a read of the rest of the policy to understand how the processes are expected to work once you have it) https://github.com/llvm/llvm-project/pull/98855 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][docs] Update Include Options Help (PR #101192)
https://github.com/lenary updated https://github.com/llvm/llvm-project/pull/101192 >From d9fc0576afc4ad2521e92166f8e4b7a56da97230 Mon Sep 17 00:00:00 2001 From: Sam Elliott Date: Tue, 30 Jul 2024 07:06:05 -0700 Subject: [PATCH 1/2] [clang][docs] Update Include Options Help This adds HelpTexts for some clang options that relate to include directory handling, to sync them up with what's in clang.rst (and therefore the man page). --- clang/docs/CommandGuide/clang.rst | 4 clang/include/clang/Driver/Options.td | 8 +--- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/clang/docs/CommandGuide/clang.rst b/clang/docs/CommandGuide/clang.rst index a0c2594d06c61..ca8176f854729 100644 --- a/clang/docs/CommandGuide/clang.rst +++ b/clang/docs/CommandGuide/clang.rst @@ -703,6 +703,10 @@ Preprocessor Options Do not search clang's builtin directory for include files. +.. option:: -nostdinc++ + + Do not search the system C++ standard library directory for include files. + .. option:: -fkeep-system-includes Usable only with :option:`-E`. Do not copy the preprocessed content of diff --git a/clang/include/clang/Driver/Options.td b/clang/include/clang/Driver/Options.td index 9bc84168c2960..a4159443acd0d 100644 --- a/clang/include/clang/Driver/Options.td +++ b/clang/include/clang/Driver/Options.td @@ -5507,7 +5507,7 @@ def no__dead__strip__inits__and__terms : Flag<["-"], "no_dead_strip_inits_and_te def nobuiltininc : Flag<["-"], "nobuiltininc">, Visibility<[ClangOption, CC1Option, CLOption, DXCOption]>, Group, - HelpText<"Disable builtin #include directories">, + HelpText<"Disable builtin #include directories only">, MarshallingInfoNegativeFlag>; def nogpuinc : Flag<["-"], "nogpuinc">, Group, HelpText<"Do not add include paths for CUDA/HIP and" @@ -5534,8 +5534,10 @@ def noprofilelib : Flag<["-"], "noprofilelib">; def noseglinkedit : Flag<["-"], "noseglinkedit">; def nostartfiles : Flag<["-"], "nostartfiles">, Group; def nostdinc : Flag<["-"], "nostdinc">, - Visibility<[ClangOption, CLOption, DXCOption]>, Group; -def nostdlibinc : Flag<["-"], "nostdlibinc">, Group; + Visibility<[ClangOption, CLOption, DXCOption]>, Group + HelpText<"Disable both standard system #include directories and builtin #include directores">; +def nostdlibinc : Flag<["-"], "nostdlibinc">, Group, + HelpText<"Disable standard system #include directories only">; def nostdincxx : Flag<["-"], "nostdinc++">, Visibility<[ClangOption, CC1Option]>, Group, HelpText<"Disable standard #include directories for the C++ standard library">, >From f883903cd77d7b6241723b64a3d3e1ace897c7f8 Mon Sep 17 00:00:00 2001 From: Sam Elliott Date: Tue, 30 Jul 2024 07:19:49 -0700 Subject: [PATCH 2/2] fixup! [clang][docs] Update Include Options Help --- clang/include/clang/Driver/Options.td | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/clang/include/clang/Driver/Options.td b/clang/include/clang/Driver/Options.td index a4159443acd0d..51ec29f1dc321 100644 --- a/clang/include/clang/Driver/Options.td +++ b/clang/include/clang/Driver/Options.td @@ -5534,7 +5534,7 @@ def noprofilelib : Flag<["-"], "noprofilelib">; def noseglinkedit : Flag<["-"], "noseglinkedit">; def nostartfiles : Flag<["-"], "nostartfiles">, Group; def nostdinc : Flag<["-"], "nostdinc">, - Visibility<[ClangOption, CLOption, DXCOption]>, Group + Visibility<[ClangOption, CLOption, DXCOption]>, Group, HelpText<"Disable both standard system #include directories and builtin #include directores">; def nostdlibinc : Flag<["-"], "nostdlibinc">, Group, HelpText<"Disable standard system #include directories only">; ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][docs] Update Include Options Help (PR #101192)
https://github.com/lenary closed https://github.com/llvm/llvm-project/pull/101192 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Add Hazard3 CPU (PR #102452)
https://github.com/lenary created
https://github.com/llvm/llvm-project/pull/102452
Luke Wren's Hazard3 is an open-source 32-bit RISC-V core. The core's source
code and docs are available on github:
https://github.com/wren6991/hazard3
The core has just hit 1.0 today, which seems to me to be a good time to add it
as a named CPU in LLVM.
>From af4b4eba72c98c12b4e1afa1db58d68bf46d38e8 Mon Sep 17 00:00:00 2001
From: Sam Elliott
Date: Thu, 8 Aug 2024 04:03:36 -0700
Subject: [PATCH] [RISCV] Add Hazard3 CPU
Luke Wren's Hazard3 is an open-source 32-bit RISC-V core. The core's
source code and docs are available on github:
https://github.com/wren6991/hazard3
The core has just hit 1.0 today, which seems to me to be a good time to
add it as a named CPU in LLVM.
---
clang/test/Driver/riscv-cpus.c| 17 +
clang/test/Misc/target-invalid-cpu-note.c | 4 ++--
llvm/docs/ReleaseNotes.rst| 1 +
llvm/lib/Target/RISCV/RISCVProcessors.td | 18 ++
4 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/clang/test/Driver/riscv-cpus.c b/clang/test/Driver/riscv-cpus.c
index 29687ac4e1c83..dd135bb85ea84 100644
--- a/clang/test/Driver/riscv-cpus.c
+++ b/clang/test/Driver/riscv-cpus.c
@@ -402,6 +402,23 @@
// MCPU-SIFIVE-P670-SAME: "-target-feature" "+zvkt"
// MCPU-SIFIVE-P670-SAME: "-target-abi" "lp64d"
+// RUN: %clang -target riscv32 -### -c %s 2>&1 -mcpu=hazard3 | FileCheck
-check-prefix=MCPU-HAZARD3 %s
+// MCPU-HAZARD3: "-target-cpu" "hazard3"
+// MCPU-HAZARD3-SAME: "-target-feature" "+m"
+// MCPU-HAZARD3-SAME: "-target-feature" "+a"
+// MCPU-HAZARD3-SAME: "-target-feature" "+c"
+// MCPU-HAZARD3-SAME: "-target-feature" "+b"
+// MCPU-HAZARD3-SAME: "-target-feature" "+zicsr"
+// MCPU-HAZARD3-SAME: "-target-feature" "+zifencei"
+// MCPU-HAZARD3-SAME: "-target-feature" "+zcb"
+// MCPU-HAZARD3-SAME: "-target-feature" "+zcmp"
+// MCPU-HAZARD3-SAME: "-target-feature" "+zba"
+// MCPU-HAZARD3-SAME: "-target-feature" "+zbb"
+// MCPU-HAZARD3-SAME: "-target-feature" "+zbc"
+// MCPU-HAZARD3-SAME: "-target-feature" "+zbkb"
+// MCPU-HAZARD3-SAME: "-target-feature" "+zbs"
+// MCPU-HAZARD3-SAME: "-target-abi" "ilp32"
+
// Check failed cases
// RUN: not %clang --target=riscv32 -### -c %s 2>&1 -mcpu=generic-rv321 |
FileCheck -check-prefix=FAIL-MCPU-NAME %s
diff --git a/clang/test/Misc/target-invalid-cpu-note.c
b/clang/test/Misc/target-invalid-cpu-note.c
index 249bea2311549..7485730296e09 100644
--- a/clang/test/Misc/target-invalid-cpu-note.c
+++ b/clang/test/Misc/target-invalid-cpu-note.c
@@ -81,7 +81,7 @@
// RUN: not %clang_cc1 -triple riscv32 -target-cpu not-a-cpu -fsyntax-only %s
2>&1 | FileCheck %s --check-prefix RISCV32
// RISCV32: error: unknown target CPU 'not-a-cpu'
-// RISCV32-NEXT: note: valid target CPU values are: generic-rv32, rocket-rv32,
sifive-e20, sifive-e21, sifive-e24, sifive-e31, sifive-e34, sifive-e76,
syntacore-scr1-base, syntacore-scr1-max, syntacore-scr3-rv32,
syntacore-scr4-rv32{{$}}
+// RISCV32-NEXT: note: valid target CPU values are: generic-rv32, hazard3,
rocket-rv32, sifive-e20, sifive-e21, sifive-e24, sifive-e31, sifive-e34,
sifive-e76, syntacore-scr1-base, syntacore-scr1-max, syntacore-scr3-rv32,
syntacore-scr4-rv32{{$}}
// RUN: not %clang_cc1 -triple riscv64 -target-cpu not-a-cpu -fsyntax-only %s
2>&1 | FileCheck %s --check-prefix RISCV64
// RISCV64: error: unknown target CPU 'not-a-cpu'
@@ -89,7 +89,7 @@
// RUN: not %clang_cc1 -triple riscv32 -tune-cpu not-a-cpu -fsyntax-only %s
2>&1 | FileCheck %s --check-prefix TUNE-RISCV32
// TUNE-RISCV32: error: unknown target CPU 'not-a-cpu'
-// TUNE-RISCV32-NEXT: note: valid target CPU values are: generic-rv32,
rocket-rv32, sifive-e20, sifive-e21, sifive-e24, sifive-e31, sifive-e34,
sifive-e76, syntacore-scr1-base, syntacore-scr1-max, syntacore-scr3-rv32,
syntacore-scr4-rv32, generic, rocket, sifive-7-series{{$}}
+// TUNE-RISCV32-NEXT: note: valid target CPU values are: generic-rv32,
hazard3, rocket-rv32, sifive-e20, sifive-e21, sifive-e24, sifive-e31,
sifive-e34, sifive-e76, syntacore-scr1-base, syntacore-scr1-max,
syntacore-scr3-rv32, syntacore-scr4-rv32, generic, rocket, sifive-7-series{{$}}
// RUN: not %clang_cc1 -triple riscv64 -tune-cpu not-a-cpu -fsyntax-only %s
2>&1 | FileCheck %s --check-prefix TUNE-RISCV64
// TUNE-RISCV64: error: unknown target CPU 'not-a-cpu'
diff --git a/llvm/docs/ReleaseNotes.rst b/llvm/docs/ReleaseNotes.rst
index 1ed860de6b9dc..579c1c1a37aab 100644
--- a/llvm/docs/ReleaseNotes.rst
+++ b/llvm/docs/ReleaseNotes.rst
@@ -108,6 +108,7 @@ Changes to the RISC-V Backend
fill value) rather than NOPs.
* Added Syntacore SCR4 CPUs: ``-mcpu=syntacore-scr4-rv32/64``
* ``-mcpu=sifive-p470`` was added.
+* Added Hazard3 CPU: ``-mcpu=hazard3`` (32-bit only).
Changes to the WebAssembly Backend
--
diff --git a/llvm/lib/Target/RISCV/RISCVProcessors.td
b/llvm/lib/Target/RISCV/RISCVProcessors.td
index ec9322f3
[clang] [llvm] [RISCV] Add Hazard3 CPU (PR #102452)
https://github.com/lenary converted_to_draft https://github.com/llvm/llvm-project/pull/102452 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Add Hazard3 CPU (PR #102452)
lenary wrote: I am happy to be point person on maintaining this core definition in LLVM, I communicate regularly with Luke, the core designer. As for the core itself, it's obviously maintained by Luke, and as Alex points out, it's just been announced to be in commercial products released by Raspberry Pi (the RP2350 series of boards, which is the basis for the Pico 2). I realise this means its profile has changed significantly today, away from just being on the hobby end of the open-source core spectrum. https://github.com/llvm/llvm-project/pull/102452 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Add Hazard3 CPU (PR #102452)
lenary wrote: I do have some worries about the definition as-is, as the core in the repo has optional features (configurable at tape-out time). Reading the RP2350 datasheet, not all of the optional features for Hazard3 are enabled (and I'm of the opinion that the lack of arm-like `-mcpu=++no` equivalent for RISC-V is a good thing) so I'm not sure exactly what we do here. Maybe a better approach would be to abandon this PR and contribute a `-mcpu=raspberrypi-rp2350`, which would make it clearer which HDL configuration the compiler option specifically corresponds to? Happy to discuss this next week, thought I'd put some ideas about specific directions down in advance of that. https://github.com/llvm/llvm-project/pull/102452 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Add Hazard3 Core as taped out for RP2350 (PR #102452)
https://github.com/lenary edited https://github.com/llvm/llvm-project/pull/102452 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Add Hazard3 Core as taped out for RP2350 (PR #102452)
https://github.com/lenary edited https://github.com/llvm/llvm-project/pull/102452 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Add Hazard3 Core as taped out for RP2350 (PR #102452)
@@ -108,6 +108,7 @@ Changes to the RISC-V Backend fill value) rather than NOPs. * Added Syntacore SCR4 and SCR5 CPUs: ``-mcpu=syntacore-scr4/5-rv32/64`` * ``-mcpu=sifive-p470`` was added. +* Added Hazard3 CPU: ``-mcpu=hazard3`` (32-bit only). lenary wrote: Definitely does. Well spotted, thanks. https://github.com/llvm/llvm-project/pull/102452 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][NFC] Split invalid-cpu-note tests (PR #104601)
@@ -0,0 +1,90 @@
+// Use --implicit-check-not to ensure no additional CPUs are in this list
+
+// RUN: not %clang_cc1 -triple arm64--- -target-cpu not-a-cpu -fsyntax-only %s
2>&1 | FileCheck %s --implicit-check-not={{[a-zA-Z0-9]}}
+// RUN: not %clang_cc1 -triple arm64--- -tune-cpu not-a-cpu -fsyntax-only %s
2>&1 | FileCheck %s --implicit-check-not={{[a-zA-Z0-9]}}
+
+// CHECK: error: unknown target CPU 'not-a-cpu'
+// CHECK-NEXT: note: valid target CPU values are:
+// CHECK-SAME: a64fx,
lenary wrote:
I can use the caret pattern, but i'm keen to leave each CPU on one line to make
diffs easier and clearer (so there's no rewrapping diffs)
https://github.com/llvm/llvm-project/pull/104601
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64] Add a check for invalid default features (PR #104435)
lenary wrote: Just closing a loop because I didn't have the info until today: the Oryon info in this patch is correct, the core does have SSBS and CCIDX. https://github.com/llvm/llvm-project/pull/104435 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][NFC] Split invalid-cpu-note tests (PR #104601)
https://github.com/lenary updated
https://github.com/llvm/llvm-project/pull/104601
>From b125071eeb35ee4a76e126967b7c29d86a1fae56 Mon Sep 17 00:00:00 2001
From: Sam Elliott
Date: Fri, 16 Aug 2024 07:52:53 -0700
Subject: [PATCH] [clang][test] Split invalid-cpu-note tests
This change does two kinds of splits:
- Splits each target into a different file. Some targets are left in the
same files, such as riscv32/64 and x86/_64 as these tests and lists
are very similar.
- Splits up the very long 'note:' lines which contain a list of CPUs,
using `CHECK-SAME`. There was a note about this not being possible
before, but with `--implicit-check-not`, this is now possible -- I
have verified that this does the right thing if a single CPU anywhere
in the list is left out.
These tests had become quite annoying to change when adding a CPU, and I
believe this change makes these easier to maintain, and should cut down
on conflicts in these files (or at least makes conflicts easier to
resolve).
I apologise in advance for downstream conflicts, but hopefully that's a
small amount of short term pain, in return for fewer conflicts in
future.
---
clang/test/Misc/target-invalid-cpu-note.c | 96 -
.../Misc/target-invalid-cpu-note/aarch64.c| 92 +
.../Misc/target-invalid-cpu-note/amdgcn.c | 76
clang/test/Misc/target-invalid-cpu-note/arm.c | 100 +
clang/test/Misc/target-invalid-cpu-note/avr.c | 322 +++
clang/test/Misc/target-invalid-cpu-note/bpf.c | 15 +
.../Misc/target-invalid-cpu-note/hexagon.c| 21 +
.../test/Misc/target-invalid-cpu-note/lanai.c | 9 +
.../test/Misc/target-invalid-cpu-note/mips.c | 26 ++
.../test/Misc/target-invalid-cpu-note/nvptx.c | 80
.../Misc/target-invalid-cpu-note/powerpc.c| 73
.../test/Misc/target-invalid-cpu-note/r600.c | 34 ++
.../test/Misc/target-invalid-cpu-note/riscv.c | 91 +
.../test/Misc/target-invalid-cpu-note/sparc.c | 54 +++
.../Misc/target-invalid-cpu-note/systemz.c| 22 +
.../test/Misc/target-invalid-cpu-note/wasm.c | 11 +
clang/test/Misc/target-invalid-cpu-note/x86.c | 384 ++
17 files changed, 1410 insertions(+), 96 deletions(-)
delete mode 100644 clang/test/Misc/target-invalid-cpu-note.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/aarch64.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/amdgcn.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/arm.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/avr.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/bpf.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/hexagon.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/lanai.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/mips.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/nvptx.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/powerpc.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/r600.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/riscv.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/sparc.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/systemz.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/wasm.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/x86.c
diff --git a/clang/test/Misc/target-invalid-cpu-note.c
b/clang/test/Misc/target-invalid-cpu-note.c
deleted file mode 100644
index b1783f3917a350..00
--- a/clang/test/Misc/target-invalid-cpu-note.c
+++ /dev/null
@@ -1,96 +0,0 @@
-// Use CHECK-NEXT instead of multiple CHECK-SAME to ensure we will fail if
there is anything extra in the output.
-// RUN: not %clang_cc1 -triple armv5--- -target-cpu not-a-cpu -fsyntax-only %s
2>&1 | FileCheck %s --check-prefix ARM
-// ARM: error: unknown target CPU 'not-a-cpu'
-// ARM-NEXT: note: valid target CPU values are: arm8, arm810, strongarm,
strongarm110, strongarm1100, strongarm1110, arm7tdmi, arm7tdmi-s, arm710t,
arm720t, arm9, arm9tdmi, arm920, arm920t, arm922t, arm940t, ep9312, arm10tdmi,
arm1020t, arm9e, arm946e-s, arm966e-s, arm968e-s, arm10e, arm1020e, arm1022e,
arm926ej-s, arm1136j-s, arm1136jf-s, mpcore, mpcorenovfp, arm1176jz-s,
arm1176jzf-s, arm1156t2-s, arm1156t2f-s, cortex-m0, cortex-m0plus, cortex-m1,
sc000, cortex-a5, cortex-a7, cortex-a8, cortex-a9, cortex-a12, cortex-a15,
cortex-a17, krait, cortex-r4, cortex-r4f, cortex-r5, cortex-r7, cortex-r8,
cortex-r52, cortex-r52plus, sc300, cortex-m3, cortex-m4, cortex-m7, cortex-m23,
cortex-m33, cortex-m35p, cortex-m55, cortex-m85, cortex-m52, cortex-a32,
cortex-a35, cortex-a53, cortex-a55, cortex-a57, cortex-a72, cortex-a73,
cortex-a75, cortex-a76, cortex-a76ae, cortex-a77, cortex-a78, cortex-a78ae,
cortex-a78c, cortex-a710, cortex-x1, cortex-x1c, neoverse-n1, neoverse-n2,
neoverse-v1, cyclone, exynos-m3, exynos-m4, exynos-m5, kryo, iwmmxt, xscale,
swift{{$}}
-
-// RUN: not %clang_cc1 -triple a
[clang] [clang][NFC] Split invalid-cpu-note tests (PR #104601)
@@ -0,0 +1,90 @@
+// Use --implicit-check-not to ensure no additional CPUs are in this list
+
+// RUN: not %clang_cc1 -triple arm64--- -target-cpu not-a-cpu -fsyntax-only %s
2>&1 | FileCheck %s --implicit-check-not={{[a-zA-Z0-9]}}
+// RUN: not %clang_cc1 -triple arm64--- -tune-cpu not-a-cpu -fsyntax-only %s
2>&1 | FileCheck %s --implicit-check-not={{[a-zA-Z0-9]}}
+
+// CHECK: error: unknown target CPU 'not-a-cpu'
+// CHECK-NEXT: note: valid target CPU values are:
+// CHECK-SAME: a64fx,
lenary wrote:
I am not going to group them, I think one per line is more maintainable
long-term for a few different reasons - it means no rewrapping diffs, no having
to reverse engineer how someone grouped things, and that it's very obvious what
to do for new CPUs.
I have taken the advice on using `{{^}}`
https://github.com/llvm/llvm-project/pull/104601
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Add Hazard3 Core as taped out for RP2350 (PR #102452)
https://github.com/lenary updated
https://github.com/llvm/llvm-project/pull/102452
>From b125071eeb35ee4a76e126967b7c29d86a1fae56 Mon Sep 17 00:00:00 2001
From: Sam Elliott
Date: Fri, 16 Aug 2024 07:52:53 -0700
Subject: [PATCH 1/2] [clang][test] Split invalid-cpu-note tests
This change does two kinds of splits:
- Splits each target into a different file. Some targets are left in the
same files, such as riscv32/64 and x86/_64 as these tests and lists
are very similar.
- Splits up the very long 'note:' lines which contain a list of CPUs,
using `CHECK-SAME`. There was a note about this not being possible
before, but with `--implicit-check-not`, this is now possible -- I
have verified that this does the right thing if a single CPU anywhere
in the list is left out.
These tests had become quite annoying to change when adding a CPU, and I
believe this change makes these easier to maintain, and should cut down
on conflicts in these files (or at least makes conflicts easier to
resolve).
I apologise in advance for downstream conflicts, but hopefully that's a
small amount of short term pain, in return for fewer conflicts in
future.
---
clang/test/Misc/target-invalid-cpu-note.c | 96 -
.../Misc/target-invalid-cpu-note/aarch64.c| 92 +
.../Misc/target-invalid-cpu-note/amdgcn.c | 76
clang/test/Misc/target-invalid-cpu-note/arm.c | 100 +
clang/test/Misc/target-invalid-cpu-note/avr.c | 322 +++
clang/test/Misc/target-invalid-cpu-note/bpf.c | 15 +
.../Misc/target-invalid-cpu-note/hexagon.c| 21 +
.../test/Misc/target-invalid-cpu-note/lanai.c | 9 +
.../test/Misc/target-invalid-cpu-note/mips.c | 26 ++
.../test/Misc/target-invalid-cpu-note/nvptx.c | 80
.../Misc/target-invalid-cpu-note/powerpc.c| 73
.../test/Misc/target-invalid-cpu-note/r600.c | 34 ++
.../test/Misc/target-invalid-cpu-note/riscv.c | 91 +
.../test/Misc/target-invalid-cpu-note/sparc.c | 54 +++
.../Misc/target-invalid-cpu-note/systemz.c| 22 +
.../test/Misc/target-invalid-cpu-note/wasm.c | 11 +
clang/test/Misc/target-invalid-cpu-note/x86.c | 384 ++
17 files changed, 1410 insertions(+), 96 deletions(-)
delete mode 100644 clang/test/Misc/target-invalid-cpu-note.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/aarch64.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/amdgcn.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/arm.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/avr.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/bpf.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/hexagon.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/lanai.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/mips.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/nvptx.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/powerpc.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/r600.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/riscv.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/sparc.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/systemz.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/wasm.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/x86.c
diff --git a/clang/test/Misc/target-invalid-cpu-note.c
b/clang/test/Misc/target-invalid-cpu-note.c
deleted file mode 100644
index b1783f3917a350..00
--- a/clang/test/Misc/target-invalid-cpu-note.c
+++ /dev/null
@@ -1,96 +0,0 @@
-// Use CHECK-NEXT instead of multiple CHECK-SAME to ensure we will fail if
there is anything extra in the output.
-// RUN: not %clang_cc1 -triple armv5--- -target-cpu not-a-cpu -fsyntax-only %s
2>&1 | FileCheck %s --check-prefix ARM
-// ARM: error: unknown target CPU 'not-a-cpu'
-// ARM-NEXT: note: valid target CPU values are: arm8, arm810, strongarm,
strongarm110, strongarm1100, strongarm1110, arm7tdmi, arm7tdmi-s, arm710t,
arm720t, arm9, arm9tdmi, arm920, arm920t, arm922t, arm940t, ep9312, arm10tdmi,
arm1020t, arm9e, arm946e-s, arm966e-s, arm968e-s, arm10e, arm1020e, arm1022e,
arm926ej-s, arm1136j-s, arm1136jf-s, mpcore, mpcorenovfp, arm1176jz-s,
arm1176jzf-s, arm1156t2-s, arm1156t2f-s, cortex-m0, cortex-m0plus, cortex-m1,
sc000, cortex-a5, cortex-a7, cortex-a8, cortex-a9, cortex-a12, cortex-a15,
cortex-a17, krait, cortex-r4, cortex-r4f, cortex-r5, cortex-r7, cortex-r8,
cortex-r52, cortex-r52plus, sc300, cortex-m3, cortex-m4, cortex-m7, cortex-m23,
cortex-m33, cortex-m35p, cortex-m55, cortex-m85, cortex-m52, cortex-a32,
cortex-a35, cortex-a53, cortex-a55, cortex-a57, cortex-a72, cortex-a73,
cortex-a75, cortex-a76, cortex-a76ae, cortex-a77, cortex-a78, cortex-a78ae,
cortex-a78c, cortex-a710, cortex-x1, cortex-x1c, neoverse-n1, neoverse-n2,
neoverse-v1, cyclone, exynos-m3, exynos-m4, exynos-m5, kryo, iwmmxt, xscale,
swift{{$}}
-
-// RUN: not %clang_cc1 -trip
[clang] [llvm] [RISCV] Add Hazard3 Core as taped out for RP2350 (PR #102452)
lenary wrote: > Is this PR stacked on > [b125071](https://github.com/llvm/llvm-project/commit/b125071eeb35ee4a76e126967b7c29d86a1fae56) > (I don't see any note of that in the PR description at the moment)? > > Edit: I found the comment that says that! Yeah, sorry, I only stacked it about halfway through its life, because I got sick of editing those files. https://github.com/llvm/llvm-project/pull/102452 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][NFC] Split invalid-cpu-note tests (PR #104601)
lenary wrote: Failures seem unrelated. Merging. https://github.com/llvm/llvm-project/pull/104601 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][NFC] Split invalid-cpu-note tests (PR #104601)
https://github.com/lenary closed https://github.com/llvm/llvm-project/pull/104601 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Add Hazard3 Core as taped out for RP2350 (PR #102452)
lenary wrote: The commit this was stacked on is merged, and I think we have sorted out naming issues and pinned down the exact cpu configuration, so I think this is ready for review and merge. https://github.com/llvm/llvm-project/pull/102452 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Add Hazard3 Core as taped out for RP2350 (PR #102452)
https://github.com/lenary updated
https://github.com/llvm/llvm-project/pull/102452
>From b125071eeb35ee4a76e126967b7c29d86a1fae56 Mon Sep 17 00:00:00 2001
From: Sam Elliott
Date: Fri, 16 Aug 2024 07:52:53 -0700
Subject: [PATCH 1/2] [clang][test] Split invalid-cpu-note tests
This change does two kinds of splits:
- Splits each target into a different file. Some targets are left in the
same files, such as riscv32/64 and x86/_64 as these tests and lists
are very similar.
- Splits up the very long 'note:' lines which contain a list of CPUs,
using `CHECK-SAME`. There was a note about this not being possible
before, but with `--implicit-check-not`, this is now possible -- I
have verified that this does the right thing if a single CPU anywhere
in the list is left out.
These tests had become quite annoying to change when adding a CPU, and I
believe this change makes these easier to maintain, and should cut down
on conflicts in these files (or at least makes conflicts easier to
resolve).
I apologise in advance for downstream conflicts, but hopefully that's a
small amount of short term pain, in return for fewer conflicts in
future.
---
clang/test/Misc/target-invalid-cpu-note.c | 96 -
.../Misc/target-invalid-cpu-note/aarch64.c| 92 +
.../Misc/target-invalid-cpu-note/amdgcn.c | 76
clang/test/Misc/target-invalid-cpu-note/arm.c | 100 +
clang/test/Misc/target-invalid-cpu-note/avr.c | 322 +++
clang/test/Misc/target-invalid-cpu-note/bpf.c | 15 +
.../Misc/target-invalid-cpu-note/hexagon.c| 21 +
.../test/Misc/target-invalid-cpu-note/lanai.c | 9 +
.../test/Misc/target-invalid-cpu-note/mips.c | 26 ++
.../test/Misc/target-invalid-cpu-note/nvptx.c | 80
.../Misc/target-invalid-cpu-note/powerpc.c| 73
.../test/Misc/target-invalid-cpu-note/r600.c | 34 ++
.../test/Misc/target-invalid-cpu-note/riscv.c | 91 +
.../test/Misc/target-invalid-cpu-note/sparc.c | 54 +++
.../Misc/target-invalid-cpu-note/systemz.c| 22 +
.../test/Misc/target-invalid-cpu-note/wasm.c | 11 +
clang/test/Misc/target-invalid-cpu-note/x86.c | 384 ++
17 files changed, 1410 insertions(+), 96 deletions(-)
delete mode 100644 clang/test/Misc/target-invalid-cpu-note.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/aarch64.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/amdgcn.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/arm.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/avr.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/bpf.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/hexagon.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/lanai.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/mips.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/nvptx.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/powerpc.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/r600.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/riscv.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/sparc.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/systemz.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/wasm.c
create mode 100644 clang/test/Misc/target-invalid-cpu-note/x86.c
diff --git a/clang/test/Misc/target-invalid-cpu-note.c
b/clang/test/Misc/target-invalid-cpu-note.c
deleted file mode 100644
index b1783f3917a350..00
--- a/clang/test/Misc/target-invalid-cpu-note.c
+++ /dev/null
@@ -1,96 +0,0 @@
-// Use CHECK-NEXT instead of multiple CHECK-SAME to ensure we will fail if
there is anything extra in the output.
-// RUN: not %clang_cc1 -triple armv5--- -target-cpu not-a-cpu -fsyntax-only %s
2>&1 | FileCheck %s --check-prefix ARM
-// ARM: error: unknown target CPU 'not-a-cpu'
-// ARM-NEXT: note: valid target CPU values are: arm8, arm810, strongarm,
strongarm110, strongarm1100, strongarm1110, arm7tdmi, arm7tdmi-s, arm710t,
arm720t, arm9, arm9tdmi, arm920, arm920t, arm922t, arm940t, ep9312, arm10tdmi,
arm1020t, arm9e, arm946e-s, arm966e-s, arm968e-s, arm10e, arm1020e, arm1022e,
arm926ej-s, arm1136j-s, arm1136jf-s, mpcore, mpcorenovfp, arm1176jz-s,
arm1176jzf-s, arm1156t2-s, arm1156t2f-s, cortex-m0, cortex-m0plus, cortex-m1,
sc000, cortex-a5, cortex-a7, cortex-a8, cortex-a9, cortex-a12, cortex-a15,
cortex-a17, krait, cortex-r4, cortex-r4f, cortex-r5, cortex-r7, cortex-r8,
cortex-r52, cortex-r52plus, sc300, cortex-m3, cortex-m4, cortex-m7, cortex-m23,
cortex-m33, cortex-m35p, cortex-m55, cortex-m85, cortex-m52, cortex-a32,
cortex-a35, cortex-a53, cortex-a55, cortex-a57, cortex-a72, cortex-a73,
cortex-a75, cortex-a76, cortex-a76ae, cortex-a77, cortex-a78, cortex-a78ae,
cortex-a78c, cortex-a710, cortex-x1, cortex-x1c, neoverse-n1, neoverse-n2,
neoverse-v1, cyclone, exynos-m3, exynos-m4, exynos-m5, kryo, iwmmxt, xscale,
swift{{$}}
-
-// RUN: not %clang_cc1 -trip
[clang] [llvm] [RISCV] Add CSRs and an instruction for Smctr and Ssctr extensions. (PR #105148)
@@ -839,6 +839,14 @@ def HLV_D : HLoad_r<0b0110110, 0b0, "hlv.d">,
Sched<[]>;
def HSV_D : HStore_rr<0b0110111, "hsv.d">, Sched<[]>;
}
+let Predicates = [HasStdExtSmctrOrSsctr] in {
+def SCTRCLR : Priv<"sctrclr", 0b0001000>, Sched<[]> {
lenary wrote:
This doesn't look like it has assembly tests, I think?
https://github.com/llvm/llvm-project/pull/105148
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Add CSRs and an instruction for Smctr and Ssctr extensions. (PR #105148)
https://github.com/lenary approved this pull request. https://github.com/llvm/llvm-project/pull/105148 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Add Hazard3 Core as taped out for RP2350 (PR #102452)
https://github.com/lenary closed https://github.com/llvm/llvm-project/pull/102452 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [RISCV] Allow YAML file to control multilib selection (PR #98856)
lenary wrote: This is also a limitation if you use `@` as a prefix as suggested in the discourse thread - GCC's `-print-multi-lib` prints out flags with the first `-` replaced with an `@`, which iirc some build systems also parse (i recall crosstool-ng, but maybe it's newlib within a crosstool-ng build). I'm not entirely sure what the solution is here - there are two mappings going on, the yaml is optimised for the flags -> libraries translation, but not really for the "what are the (minimal) flags to produce objects to go into this library" query which `--print-multi-lib` wants. https://github.com/llvm/llvm-project/pull/98856 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Fix typo with colon-separated syntax for system registers (PR #105608)
lenary wrote: The existing implementation lines up with the ACLE, which specifies this colon-separated syntax: https://github.com/ARM-software/acle/blob/main/main/acle.md#aarch64-system-register - please send an update to that document before changing this behaviour. https://github.com/llvm/llvm-project/pull/105608 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Enable frame pointer for non-leaf functions on Android (PR #97614)
@@ -166,7 +155,7 @@ static bool useFramePointerForTargetByDefault(const
llvm::opt::ArgList &Args,
static bool useLeafFramePointerForTargetByDefault(const llvm::Triple &Triple) {
if (Triple.isAArch64() || Triple.isPS() || Triple.isVE() ||
- (Triple.isAndroid() && Triple.isRISCV64()))
+ (Triple.isAndroid() && !Triple.isARM()))
lenary wrote:
Did you mean to miss out Thumb? `isARM` is only true for `arm-*`, `armeb-*`
triples, you would need an `isThumb` call to also cover `thumb-*` and
`thumbeb-*` triples.
https://github.com/llvm/llvm-project/pull/97614
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64] Implement GCS ACLE intrinsics (PR #96903)
@@ -855,6 +863,25 @@ __rndrrs(uint64_t *__p) {
}
#endif
+/* 11.2 Guarded Control Stack intrinsics */
+#if defined(__ARM_64BIT_STATE) && __ARM_64BIT_STATE
+static __inline__ void * __attribute__((__always_inline__, __nodebug__))
+__gcspr() {
+ return (void *)__builtin_arm_rsr64("gcspr_el0");
+}
+
+static __inline__ uint64_t __attribute__((__always_inline__, __nodebug__,
target("gcs")))
+__gcspopm() {
+ return __builtin_arm_gcspopm(0);
+}
+
+static __inline__ const void * __attribute__((__always_inline__, __nodebug__,
target("gcs")))
+__gcsss(const void *__stack) {
+ __builtin_arm_gcsss1(__stack);
+ return __builtin_arm_gcsss2(0);
+}
lenary wrote:
Would we ever expect these builtins to be called separately? If not, what's the
rationale for having two of them, rather than one that does both operations?
https://github.com/llvm/llvm-project/pull/96903
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [RISCV] Emit predefined macro __riscv_cmodel_large for large code model (PR #108131)
https://github.com/lenary approved this pull request. Nice catch in the test. Code still LGTM. https://github.com/llvm/llvm-project/pull/108131 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [RISCV][FMV] Support target_clones (PR #85786)
@@ -0,0 +1,441 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --check-globals all --include-generated-funcs --version 4
+// RUN: %clang_cc1 -triple riscv64-linux-gnu -target-feature +i -emit-llvm -o
- %s | FileCheck %s
+
+__attribute__((target_clones("default", "arch=+m"))) int foo1(void) {
+ return 1;
+}
+__attribute__((target_clones("default", "arch=+zbb", "arch=+m"))) int
foo2(void) { return 2; }
+__attribute__((target_clones("default", "arch=+zbb,+c"))) int foo3(void) {
return 3; }
+__attribute__((target_clones("default", "arch=+zbb,+v"))) int
+foo4(void) {
+ return 4;
+}
+__attribute__((target_clones("default"))) int foo5(void) { return 5; }
+__attribute__((target_clones("default", "arch=+zvkt"))) int foo6(void) {
return 2; }
+
+__attribute__((target_clones("default", "arch=+zbb", "arch=+zba",
"arch=+zbb,+zba"))) int foo7(void) { return 2; }
+__attribute__((target_clones("default", "arch=+zbb;priority=2",
"arch=+zba;priority=1", "arch=+zbb,+zba;priority=3"))) int foo8(void) { return
2; }
+__attribute__((target_clones("default", "arch=+zbb;priority=1",
"priority=2;arch=+zba", "priority=3;arch=+zbb,+zba"))) int foo9(void) { return
2; }
+__attribute__((target_clones("default", "arch=+zbb;priority=-1",
"priority=-2;arch=+zba", "priority=3;arch=+zbb,+zba"))) int foo10(void) {
return 2; }
lenary wrote:
The grammar defined in https://github.com/riscv-non-isa/riscv-c-api-doc/pull/85
does not allow for `priority=-1`, as you're only allowed the digits 0-9 after
`priority=`. Was it intentional to support or not support negative priorities?
https://github.com/llvm/llvm-project/pull/85786
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Add support for inline asm constraint vd (PR #111653)
https://github.com/lenary approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/111653 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Add support for inline asm constraint vd (PR #111653)
@@ -29,6 +29,14 @@ vint32m1_t test_vr(vint32m1_t a, vint32m1_t b) {
return ret;
}
+vint32m1_t test_vd(vint32m1_t a, vint32m1_t b) {
+// CHECK-LABEL: define{{.*}} @test_vd
+// CHECK: %0 = tail call asm sideeffect "vadd.vv $0, $1,
$2", "=^vd,^vd,^vd"( %a, %b)
+ vint32m1_t ret;
+ asm volatile ("vadd.vv %0, %1, %2" : "=vd"(ret) : "vd"(a), "vd"(b));
lenary wrote:
@topperc is this test not enough?
https://github.com/llvm/llvm-project/pull/111653
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV][ISel] Ensure 'in X' Constraints prevent X0 (PR #112563)
lenary wrote: Yeah, I went back and looked at that issue, it's helpful to know that it was more than just the register allocator, that it was also copy propagation, which wasn't obvious from the comments. The failing tests are not related, but presumably caused by the rebase, but I'll still wait a bit to merge this. https://github.com/llvm/llvm-project/pull/112563 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV][ISel] Ensure 'in X' Constraints prevent X0 (PR #112563)
https://github.com/lenary updated
https://github.com/llvm/llvm-project/pull/112563
>From bbf0b885dc5912d4dc29abcec5fe7cee7cfd1758 Mon Sep 17 00:00:00 2001
From: Sam Elliott
Date: Wed, 16 Oct 2024 05:04:45 -0700
Subject: [PATCH 1/2] [RISCV] Inline Assembly: RVC constraint and N modifier
This change implements support for the `cr` and `cf` register
constraints (which allocate a RVC GPR or RVC FPR respectively), and the
`N` modifier (which prints the raw encoding of a register rather than the
name).
The intention behind these additions is to make it easier to use inline
assembly when assembling raw instructions that are not supported by the
compiler, for instance when experimenting with new instructions or when
supporting proprietary extensions outside the toolchain.
These implement part of my proposal in riscv-non-isa/riscv-c-api-doc#92
As part of the implementation, I felt there was not enough coverage of
inline assembly and the "in X" floating-point extensions, so I have
added more regression tests around these configurations.
---
clang/lib/Basic/Targets/RISCV.cpp | 10 ++
clang/test/CodeGen/RISCV/riscv-inline-asm.c | 40 -
llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp | 8 +
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | 18 ++
llvm/lib/Target/RISCV/RISCVRegisterInfo.td| 19 ++-
.../RISCV/inline-asm-d-constraint-f.ll| 33
.../CodeGen/RISCV/inline-asm-d-modifier-N.ll | 109
.../RISCV/inline-asm-f-constraint-f.ll| 28 +++-
.../CodeGen/RISCV/inline-asm-f-modifier-N.ll | 96 +++
llvm/test/CodeGen/RISCV/inline-asm-invalid.ll | 20 +++
.../RISCV/inline-asm-zdinx-constraint-r.ll| 92 ++
.../RISCV/inline-asm-zfh-constraint-f.ll | 41 +
.../RISCV/inline-asm-zfh-modifier-N.ll| 157 +
.../RISCV/inline-asm-zfinx-constraint-r.ll| 89 ++
.../RISCV/inline-asm-zhinx-constraint-r.ll| 158 ++
llvm/test/CodeGen/RISCV/inline-asm.ll | 66
.../CodeGen/RISCV/zdinx-asm-constraint.ll | 61 +++
17 files changed, 1040 insertions(+), 5 deletions(-)
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-d-modifier-N.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-f-modifier-N.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zdinx-constraint-r.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zfh-modifier-N.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zfinx-constraint-r.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zhinx-constraint-r.ll
diff --git a/clang/lib/Basic/Targets/RISCV.cpp
b/clang/lib/Basic/Targets/RISCV.cpp
index 870f0f38bc3057..eaaba7642bd7b2 100644
--- a/clang/lib/Basic/Targets/RISCV.cpp
+++ b/clang/lib/Basic/Targets/RISCV.cpp
@@ -100,6 +100,14 @@ bool RISCVTargetInfo::validateAsmConstraint(
case 'S': // A symbol or label reference with a constant offset
Info.setAllowsRegister();
return true;
+ case 'c':
+// A RVC register - GPR or FPR
+if (Name[1] == 'r' || Name[1] == 'f') {
+ Info.setAllowsRegister();
+ Name += 1;
+ return true;
+}
+return false;
case 'v':
// A vector register.
if (Name[1] == 'r' || Name[1] == 'd' || Name[1] == 'm') {
@@ -114,6 +122,8 @@ bool RISCVTargetInfo::validateAsmConstraint(
std::string RISCVTargetInfo::convertConstraint(const char *&Constraint) const {
std::string R;
switch (*Constraint) {
+ // c* and v* are two-letter constraints on RISC-V.
+ case 'c':
case 'v':
R = std::string("^") + std::string(Constraint, 2);
Constraint += 1;
diff --git a/clang/test/CodeGen/RISCV/riscv-inline-asm.c
b/clang/test/CodeGen/RISCV/riscv-inline-asm.c
index fa0bf6aa6aa471..75b91d3c497c50 100644
--- a/clang/test/CodeGen/RISCV/riscv-inline-asm.c
+++ b/clang/test/CodeGen/RISCV/riscv-inline-asm.c
@@ -3,7 +3,35 @@
// RUN: %clang_cc1 -triple riscv64 -O2 -emit-llvm %s -o - \
// RUN: | FileCheck %s
-// Test RISC-V specific inline assembly constraints.
+// Test RISC-V specific inline assembly constraints and modifiers.
+
+long test_r(long x) {
+// CHECK-LABEL: define{{.*}} {{i64|i32}} @test_r(
+// CHECK: call {{i64|i32}} asm sideeffect "", "=r,r"({{i64|i32}} %{{.*}})
+ long ret;
+ asm volatile ("" : "=r"(ret) : "r"(x));
+// CHECK: call {{i64|i32}} asm sideeffect "", "=r,r"({{i64|i32}} %{{.*}})
+ asm volatile ("" : "=r"(ret) : "r"(x));
+ return ret;
+}
+
+long test_cr(long x) {
+// CHECK-LABEL: define{{.*}} {{i64|i32}} @test_cr(
+// CHECK: call {{i64|i32}} asm sideeffect "", "=^cr,^cr"({{i64|i32}} %{{.*}})
+ long ret;
+ asm volatile ("" : "=cr"(ret) : "cr"(x));
+ return ret;
+}
+
+float cf;
+double cd;
+void test_cf(float f, double d) {
+// CHECK-LABEL: define{{.*}} void @test_cf(
+// CHECK: call float asm sideeffect "", "=^cf,^cf"(float %{{.*}})
+ asm volatile("" : "=cf"(cf) : "cf"(f));
+// CHECK: call double asm sideeffect "", "=^cf,^cf"(double %{{.*}})
+ asm volatile("" : "=cf"(cd) :
[clang] [llvm] [RISCV] Inline Assembly: RVC constraint and N modifier (PR #112561)
https://github.com/lenary created
https://github.com/llvm/llvm-project/pull/112561
This change implements support for the `cr` and `cf` register constraints
(which allocate a RVC GPR or RVC FPR respectively), and the `N` modifier (which
prints the raw encoding of a register rather than the name).
The intention behind these additions is to make it easier to use inline
assembly when assembling raw instructions that are not supported by the
compiler, for instance when experimenting with new instructions or when
supporting proprietary extensions outside the toolchain.
These implement part of my proposal in riscv-non-isa/riscv-c-api-doc#92
As part of the implementation, I felt there was not enough coverage of inline
assembly and the "in X" floating-point extensions, so I have added more
regression tests around these configurations.
>From 6d60f09f20d9e8436af95f601256dd9301912028 Mon Sep 17 00:00:00 2001
From: Sam Elliott
Date: Wed, 16 Oct 2024 05:04:45 -0700
Subject: [PATCH] [RISCV] Inline Assembly: RVC constraint and N modifier
This change implements support for the `cr` and `cf` register
constraints (which allocate a RVC GPR or RVC FPR respectively), and the
`N` modifier (which prints the raw encoding of a register rather than the
name).
The intention behind these additions is to make it easier to use inline
assembly when assembling raw instructions that are not supported by the
compiler, for instance when experimenting with new instructions or when
supporting proprietary extensions outside the toolchain.
These implement part of my proposal in riscv-non-isa/riscv-c-api-doc#92
As part of the implementation, I felt there was not enough coverage of
inline assembly and the "in X" floating-point extensions, so I have
added more regression tests around these configurations.
---
clang/lib/Basic/Targets/RISCV.cpp | 10 ++
clang/test/CodeGen/RISCV/riscv-inline-asm.c | 40 -
llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp | 9 +
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | 18 ++
llvm/lib/Target/RISCV/RISCVRegisterInfo.td| 19 ++-
.../RISCV/inline-asm-d-constraint-f.ll| 33
.../CodeGen/RISCV/inline-asm-d-modifier-N.ll | 109
.../RISCV/inline-asm-f-constraint-f.ll| 28 +++-
.../CodeGen/RISCV/inline-asm-f-modifier-N.ll | 96 +++
llvm/test/CodeGen/RISCV/inline-asm-invalid.ll | 20 +++
.../RISCV/inline-asm-zdinx-constraint-r.ll| 92 ++
.../RISCV/inline-asm-zfh-constraint-f.ll | 41 +
.../RISCV/inline-asm-zfh-modifier-N.ll| 157 +
.../RISCV/inline-asm-zfinx-constraint-r.ll| 89 ++
.../RISCV/inline-asm-zhinx-constraint-r.ll| 158 ++
llvm/test/CodeGen/RISCV/inline-asm.ll | 66
.../CodeGen/RISCV/zdinx-asm-constraint.ll | 61 +++
17 files changed, 1041 insertions(+), 5 deletions(-)
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-d-modifier-N.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-f-modifier-N.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zdinx-constraint-r.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zfh-modifier-N.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zfinx-constraint-r.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zhinx-constraint-r.ll
diff --git a/clang/lib/Basic/Targets/RISCV.cpp
b/clang/lib/Basic/Targets/RISCV.cpp
index 870f0f38bc3057..eaaba7642bd7b2 100644
--- a/clang/lib/Basic/Targets/RISCV.cpp
+++ b/clang/lib/Basic/Targets/RISCV.cpp
@@ -100,6 +100,14 @@ bool RISCVTargetInfo::validateAsmConstraint(
case 'S': // A symbol or label reference with a constant offset
Info.setAllowsRegister();
return true;
+ case 'c':
+// A RVC register - GPR or FPR
+if (Name[1] == 'r' || Name[1] == 'f') {
+ Info.setAllowsRegister();
+ Name += 1;
+ return true;
+}
+return false;
case 'v':
// A vector register.
if (Name[1] == 'r' || Name[1] == 'd' || Name[1] == 'm') {
@@ -114,6 +122,8 @@ bool RISCVTargetInfo::validateAsmConstraint(
std::string RISCVTargetInfo::convertConstraint(const char *&Constraint) const {
std::string R;
switch (*Constraint) {
+ // c* and v* are two-letter constraints on RISC-V.
+ case 'c':
case 'v':
R = std::string("^") + std::string(Constraint, 2);
Constraint += 1;
diff --git a/clang/test/CodeGen/RISCV/riscv-inline-asm.c
b/clang/test/CodeGen/RISCV/riscv-inline-asm.c
index fa0bf6aa6aa471..75b91d3c497c50 100644
--- a/clang/test/CodeGen/RISCV/riscv-inline-asm.c
+++ b/clang/test/CodeGen/RISCV/riscv-inline-asm.c
@@ -3,7 +3,35 @@
// RUN: %clang_cc1 -triple riscv64 -O2 -emit-llvm %s -o - \
// RUN: | FileCheck %s
-// Test RISC-V specific inline assembly constraints.
+// Test RISC-V specific inline assembly constraints and modifiers.
+
+long test_r(long x) {
+// CHECK-LABEL: define{{.*}} {{i64|i32}} @test_r(
+// CHECK: call {{i64|i32}} asm sideeffect "", "=r,r"(
[clang] [llvm] [RISCV][ISel] Ensure 'in X' Constraints prevent X0 (PR #112563)
https://github.com/lenary created
https://github.com/llvm/llvm-project/pull/112563
I'm not sure if this fix is required, but I've written the patch anyway. This
does not cause test changes, but we haven't got tests that try to use all 32
registers in inline assembly.
Broadly, for GPRs, we made the explicit choice that `r` constraints would never
attempt to use `x0`, because `x0` isn't really usable like the other GPRs. I
believe the same thing applies to `Zhinx`, `Zfinx` and `Zdinx` because they
should not be allocating operands to `x0` either, so this patch introduces new
`NoX0` classes for `GPRF16` and `GPRF32` registers, and uses them with inline
assembly. There is also a `GPRPairNoX0` for the `Zdinx` case on rv32, avoiding
use of the `x0` pair which has different behaviour to the other GPR pairs.
---
This is stacked on #112561, only review the last commit in this PR.
>From 6d60f09f20d9e8436af95f601256dd9301912028 Mon Sep 17 00:00:00 2001
From: Sam Elliott
Date: Wed, 16 Oct 2024 05:04:45 -0700
Subject: [PATCH 1/2] [RISCV] Inline Assembly: RVC constraint and N modifier
This change implements support for the `cr` and `cf` register
constraints (which allocate a RVC GPR or RVC FPR respectively), and the
`N` modifier (which prints the raw encoding of a register rather than the
name).
The intention behind these additions is to make it easier to use inline
assembly when assembling raw instructions that are not supported by the
compiler, for instance when experimenting with new instructions or when
supporting proprietary extensions outside the toolchain.
These implement part of my proposal in riscv-non-isa/riscv-c-api-doc#92
As part of the implementation, I felt there was not enough coverage of
inline assembly and the "in X" floating-point extensions, so I have
added more regression tests around these configurations.
---
clang/lib/Basic/Targets/RISCV.cpp | 10 ++
clang/test/CodeGen/RISCV/riscv-inline-asm.c | 40 -
llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp | 9 +
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | 18 ++
llvm/lib/Target/RISCV/RISCVRegisterInfo.td| 19 ++-
.../RISCV/inline-asm-d-constraint-f.ll| 33
.../CodeGen/RISCV/inline-asm-d-modifier-N.ll | 109
.../RISCV/inline-asm-f-constraint-f.ll| 28 +++-
.../CodeGen/RISCV/inline-asm-f-modifier-N.ll | 96 +++
llvm/test/CodeGen/RISCV/inline-asm-invalid.ll | 20 +++
.../RISCV/inline-asm-zdinx-constraint-r.ll| 92 ++
.../RISCV/inline-asm-zfh-constraint-f.ll | 41 +
.../RISCV/inline-asm-zfh-modifier-N.ll| 157 +
.../RISCV/inline-asm-zfinx-constraint-r.ll| 89 ++
.../RISCV/inline-asm-zhinx-constraint-r.ll| 158 ++
llvm/test/CodeGen/RISCV/inline-asm.ll | 66
.../CodeGen/RISCV/zdinx-asm-constraint.ll | 61 +++
17 files changed, 1041 insertions(+), 5 deletions(-)
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-d-modifier-N.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-f-modifier-N.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zdinx-constraint-r.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zfh-modifier-N.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zfinx-constraint-r.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zhinx-constraint-r.ll
diff --git a/clang/lib/Basic/Targets/RISCV.cpp
b/clang/lib/Basic/Targets/RISCV.cpp
index 870f0f38bc3057..eaaba7642bd7b2 100644
--- a/clang/lib/Basic/Targets/RISCV.cpp
+++ b/clang/lib/Basic/Targets/RISCV.cpp
@@ -100,6 +100,14 @@ bool RISCVTargetInfo::validateAsmConstraint(
case 'S': // A symbol or label reference with a constant offset
Info.setAllowsRegister();
return true;
+ case 'c':
+// A RVC register - GPR or FPR
+if (Name[1] == 'r' || Name[1] == 'f') {
+ Info.setAllowsRegister();
+ Name += 1;
+ return true;
+}
+return false;
case 'v':
// A vector register.
if (Name[1] == 'r' || Name[1] == 'd' || Name[1] == 'm') {
@@ -114,6 +122,8 @@ bool RISCVTargetInfo::validateAsmConstraint(
std::string RISCVTargetInfo::convertConstraint(const char *&Constraint) const {
std::string R;
switch (*Constraint) {
+ // c* and v* are two-letter constraints on RISC-V.
+ case 'c':
case 'v':
R = std::string("^") + std::string(Constraint, 2);
Constraint += 1;
diff --git a/clang/test/CodeGen/RISCV/riscv-inline-asm.c
b/clang/test/CodeGen/RISCV/riscv-inline-asm.c
index fa0bf6aa6aa471..75b91d3c497c50 100644
--- a/clang/test/CodeGen/RISCV/riscv-inline-asm.c
+++ b/clang/test/CodeGen/RISCV/riscv-inline-asm.c
@@ -3,7 +3,35 @@
// RUN: %clang_cc1 -triple riscv64 -O2 -emit-llvm %s -o - \
// RUN: | FileCheck %s
-// Test RISC-V specific inline assembly constraints.
+// Test RISC-V specific inline assembly constraints and modifiers.
+
+long test_r(long x) {
+// CHECK-LABEL: define{{.*}} {{i64|i32}} @test_r(
+//
[clang] [llvm] [RISCV] Inline Assembly: RVC constraint and N modifier (PR #112561)
@@ -348,6 +349,14 @@ bool RISCVAsmPrinter::PrintAsmOperand(const MachineInstr *MI, unsigned OpNo, if (!MO.isReg()) OS << 'i'; return false; +case 'N': // Print the register encoding as an integer (0-31, or 0-7 when lenary wrote: Ah, yes, sorry - this comment wasn't updated when the implementation was, I'll fix the comment. I specifically gave up on just printing the RVC encoding when the constraint is `c*`, because that makes it harder to use the register in both RVC and non-RVC positions in a multi-instruction inline assembly statement. Instead, it's up to the assembly author to correctly mask the value from the full encoding down to the RVC encoding. https://github.com/llvm/llvm-project/pull/112561 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV][ISel] Ensure 'in X' Constraints prevent X0 (PR #112563)
lenary wrote: (My approach with the test was to try to use all 32 GPRs, so have it fail when it couldn't use x0 - doing so by marking ra, sp, gp, and tp as clobbered, and passing 28 floats) https://github.com/llvm/llvm-project/pull/112563 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Inline Assembly: RVC constraint and N modifier (PR #112561)
https://github.com/lenary updated
https://github.com/llvm/llvm-project/pull/112561
>From bbf0b885dc5912d4dc29abcec5fe7cee7cfd1758 Mon Sep 17 00:00:00 2001
From: Sam Elliott
Date: Wed, 16 Oct 2024 05:04:45 -0700
Subject: [PATCH] [RISCV] Inline Assembly: RVC constraint and N modifier
This change implements support for the `cr` and `cf` register
constraints (which allocate a RVC GPR or RVC FPR respectively), and the
`N` modifier (which prints the raw encoding of a register rather than the
name).
The intention behind these additions is to make it easier to use inline
assembly when assembling raw instructions that are not supported by the
compiler, for instance when experimenting with new instructions or when
supporting proprietary extensions outside the toolchain.
These implement part of my proposal in riscv-non-isa/riscv-c-api-doc#92
As part of the implementation, I felt there was not enough coverage of
inline assembly and the "in X" floating-point extensions, so I have
added more regression tests around these configurations.
---
clang/lib/Basic/Targets/RISCV.cpp | 10 ++
clang/test/CodeGen/RISCV/riscv-inline-asm.c | 40 -
llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp | 8 +
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | 18 ++
llvm/lib/Target/RISCV/RISCVRegisterInfo.td| 19 ++-
.../RISCV/inline-asm-d-constraint-f.ll| 33
.../CodeGen/RISCV/inline-asm-d-modifier-N.ll | 109
.../RISCV/inline-asm-f-constraint-f.ll| 28 +++-
.../CodeGen/RISCV/inline-asm-f-modifier-N.ll | 96 +++
llvm/test/CodeGen/RISCV/inline-asm-invalid.ll | 20 +++
.../RISCV/inline-asm-zdinx-constraint-r.ll| 92 ++
.../RISCV/inline-asm-zfh-constraint-f.ll | 41 +
.../RISCV/inline-asm-zfh-modifier-N.ll| 157 +
.../RISCV/inline-asm-zfinx-constraint-r.ll| 89 ++
.../RISCV/inline-asm-zhinx-constraint-r.ll| 158 ++
llvm/test/CodeGen/RISCV/inline-asm.ll | 66
.../CodeGen/RISCV/zdinx-asm-constraint.ll | 61 +++
17 files changed, 1040 insertions(+), 5 deletions(-)
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-d-modifier-N.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-f-modifier-N.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zdinx-constraint-r.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zfh-modifier-N.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zfinx-constraint-r.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zhinx-constraint-r.ll
diff --git a/clang/lib/Basic/Targets/RISCV.cpp
b/clang/lib/Basic/Targets/RISCV.cpp
index 870f0f38bc3057..eaaba7642bd7b2 100644
--- a/clang/lib/Basic/Targets/RISCV.cpp
+++ b/clang/lib/Basic/Targets/RISCV.cpp
@@ -100,6 +100,14 @@ bool RISCVTargetInfo::validateAsmConstraint(
case 'S': // A symbol or label reference with a constant offset
Info.setAllowsRegister();
return true;
+ case 'c':
+// A RVC register - GPR or FPR
+if (Name[1] == 'r' || Name[1] == 'f') {
+ Info.setAllowsRegister();
+ Name += 1;
+ return true;
+}
+return false;
case 'v':
// A vector register.
if (Name[1] == 'r' || Name[1] == 'd' || Name[1] == 'm') {
@@ -114,6 +122,8 @@ bool RISCVTargetInfo::validateAsmConstraint(
std::string RISCVTargetInfo::convertConstraint(const char *&Constraint) const {
std::string R;
switch (*Constraint) {
+ // c* and v* are two-letter constraints on RISC-V.
+ case 'c':
case 'v':
R = std::string("^") + std::string(Constraint, 2);
Constraint += 1;
diff --git a/clang/test/CodeGen/RISCV/riscv-inline-asm.c
b/clang/test/CodeGen/RISCV/riscv-inline-asm.c
index fa0bf6aa6aa471..75b91d3c497c50 100644
--- a/clang/test/CodeGen/RISCV/riscv-inline-asm.c
+++ b/clang/test/CodeGen/RISCV/riscv-inline-asm.c
@@ -3,7 +3,35 @@
// RUN: %clang_cc1 -triple riscv64 -O2 -emit-llvm %s -o - \
// RUN: | FileCheck %s
-// Test RISC-V specific inline assembly constraints.
+// Test RISC-V specific inline assembly constraints and modifiers.
+
+long test_r(long x) {
+// CHECK-LABEL: define{{.*}} {{i64|i32}} @test_r(
+// CHECK: call {{i64|i32}} asm sideeffect "", "=r,r"({{i64|i32}} %{{.*}})
+ long ret;
+ asm volatile ("" : "=r"(ret) : "r"(x));
+// CHECK: call {{i64|i32}} asm sideeffect "", "=r,r"({{i64|i32}} %{{.*}})
+ asm volatile ("" : "=r"(ret) : "r"(x));
+ return ret;
+}
+
+long test_cr(long x) {
+// CHECK-LABEL: define{{.*}} {{i64|i32}} @test_cr(
+// CHECK: call {{i64|i32}} asm sideeffect "", "=^cr,^cr"({{i64|i32}} %{{.*}})
+ long ret;
+ asm volatile ("" : "=cr"(ret) : "cr"(x));
+ return ret;
+}
+
+float cf;
+double cd;
+void test_cf(float f, double d) {
+// CHECK-LABEL: define{{.*}} void @test_cf(
+// CHECK: call float asm sideeffect "", "=^cf,^cf"(float %{{.*}})
+ asm volatile("" : "=cf"(cf) : "cf"(f));
+// CHECK: call double asm sideeffect "", "=^cf,^cf"(double %{{.*}})
+ asm volatile("" : "=cf"(cd) : "cf"
[clang] [llvm] [RISCV][ISel] Ensure 'in X' Constraints prevent X0 (PR #112563)
https://github.com/lenary updated
https://github.com/llvm/llvm-project/pull/112563
>From bbf0b885dc5912d4dc29abcec5fe7cee7cfd1758 Mon Sep 17 00:00:00 2001
From: Sam Elliott
Date: Wed, 16 Oct 2024 05:04:45 -0700
Subject: [PATCH 1/2] [RISCV] Inline Assembly: RVC constraint and N modifier
This change implements support for the `cr` and `cf` register
constraints (which allocate a RVC GPR or RVC FPR respectively), and the
`N` modifier (which prints the raw encoding of a register rather than the
name).
The intention behind these additions is to make it easier to use inline
assembly when assembling raw instructions that are not supported by the
compiler, for instance when experimenting with new instructions or when
supporting proprietary extensions outside the toolchain.
These implement part of my proposal in riscv-non-isa/riscv-c-api-doc#92
As part of the implementation, I felt there was not enough coverage of
inline assembly and the "in X" floating-point extensions, so I have
added more regression tests around these configurations.
---
clang/lib/Basic/Targets/RISCV.cpp | 10 ++
clang/test/CodeGen/RISCV/riscv-inline-asm.c | 40 -
llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp | 8 +
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | 18 ++
llvm/lib/Target/RISCV/RISCVRegisterInfo.td| 19 ++-
.../RISCV/inline-asm-d-constraint-f.ll| 33
.../CodeGen/RISCV/inline-asm-d-modifier-N.ll | 109
.../RISCV/inline-asm-f-constraint-f.ll| 28 +++-
.../CodeGen/RISCV/inline-asm-f-modifier-N.ll | 96 +++
llvm/test/CodeGen/RISCV/inline-asm-invalid.ll | 20 +++
.../RISCV/inline-asm-zdinx-constraint-r.ll| 92 ++
.../RISCV/inline-asm-zfh-constraint-f.ll | 41 +
.../RISCV/inline-asm-zfh-modifier-N.ll| 157 +
.../RISCV/inline-asm-zfinx-constraint-r.ll| 89 ++
.../RISCV/inline-asm-zhinx-constraint-r.ll| 158 ++
llvm/test/CodeGen/RISCV/inline-asm.ll | 66
.../CodeGen/RISCV/zdinx-asm-constraint.ll | 61 +++
17 files changed, 1040 insertions(+), 5 deletions(-)
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-d-modifier-N.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-f-modifier-N.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zdinx-constraint-r.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zfh-modifier-N.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zfinx-constraint-r.ll
create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zhinx-constraint-r.ll
diff --git a/clang/lib/Basic/Targets/RISCV.cpp
b/clang/lib/Basic/Targets/RISCV.cpp
index 870f0f38bc3057..eaaba7642bd7b2 100644
--- a/clang/lib/Basic/Targets/RISCV.cpp
+++ b/clang/lib/Basic/Targets/RISCV.cpp
@@ -100,6 +100,14 @@ bool RISCVTargetInfo::validateAsmConstraint(
case 'S': // A symbol or label reference with a constant offset
Info.setAllowsRegister();
return true;
+ case 'c':
+// A RVC register - GPR or FPR
+if (Name[1] == 'r' || Name[1] == 'f') {
+ Info.setAllowsRegister();
+ Name += 1;
+ return true;
+}
+return false;
case 'v':
// A vector register.
if (Name[1] == 'r' || Name[1] == 'd' || Name[1] == 'm') {
@@ -114,6 +122,8 @@ bool RISCVTargetInfo::validateAsmConstraint(
std::string RISCVTargetInfo::convertConstraint(const char *&Constraint) const {
std::string R;
switch (*Constraint) {
+ // c* and v* are two-letter constraints on RISC-V.
+ case 'c':
case 'v':
R = std::string("^") + std::string(Constraint, 2);
Constraint += 1;
diff --git a/clang/test/CodeGen/RISCV/riscv-inline-asm.c
b/clang/test/CodeGen/RISCV/riscv-inline-asm.c
index fa0bf6aa6aa471..75b91d3c497c50 100644
--- a/clang/test/CodeGen/RISCV/riscv-inline-asm.c
+++ b/clang/test/CodeGen/RISCV/riscv-inline-asm.c
@@ -3,7 +3,35 @@
// RUN: %clang_cc1 -triple riscv64 -O2 -emit-llvm %s -o - \
// RUN: | FileCheck %s
-// Test RISC-V specific inline assembly constraints.
+// Test RISC-V specific inline assembly constraints and modifiers.
+
+long test_r(long x) {
+// CHECK-LABEL: define{{.*}} {{i64|i32}} @test_r(
+// CHECK: call {{i64|i32}} asm sideeffect "", "=r,r"({{i64|i32}} %{{.*}})
+ long ret;
+ asm volatile ("" : "=r"(ret) : "r"(x));
+// CHECK: call {{i64|i32}} asm sideeffect "", "=r,r"({{i64|i32}} %{{.*}})
+ asm volatile ("" : "=r"(ret) : "r"(x));
+ return ret;
+}
+
+long test_cr(long x) {
+// CHECK-LABEL: define{{.*}} {{i64|i32}} @test_cr(
+// CHECK: call {{i64|i32}} asm sideeffect "", "=^cr,^cr"({{i64|i32}} %{{.*}})
+ long ret;
+ asm volatile ("" : "=cr"(ret) : "cr"(x));
+ return ret;
+}
+
+float cf;
+double cd;
+void test_cf(float f, double d) {
+// CHECK-LABEL: define{{.*}} void @test_cf(
+// CHECK: call float asm sideeffect "", "=^cf,^cf"(float %{{.*}})
+ asm volatile("" : "=cf"(cf) : "cf"(f));
+// CHECK: call double asm sideeffect "", "=^cf,^cf"(double %{{.*}})
+ asm volatile("" : "=cf"(cd) :
[clang] [llvm] [RISCV][ISel] Ensure 'in X' Constraints prevent X0 (PR #112563)
lenary wrote: I spent some time trying to write a test that should fail before, but doesn't after, but it doesn't happen - I presume because x0 is reasonably dealt with by the allocator. This maybe suggests the patch isn't needed? I'm not sure why we do this for GPRs then. https://github.com/llvm/llvm-project/pull/112563 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Inline Assembly Support for GPR Pairs ('Pr') (PR #112983)
lenary wrote: > I'm concerned that if we make i128 legal, we will have to write custom > splitting code for every operation. Using v2i64 probably has other problems > conflicting with the V extension fixed vector support. I sort-of expected that making `i128` legal would be problematic, I didn't realise that `v2i64` would also conflict with something we're currently using. > The Arch64 MVT::i64x8 may be a way to work around this. We could have a > special pair MVT only used by inline assembly. Ok, this sounds doable - so something like `MVT::xlen_pair` is the way I'll lean, rather than a different type for rv32/rv64. https://github.com/llvm/llvm-project/pull/112983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Inline Assembly Support for GPR Pairs ('Pr') (PR #112983)
https://github.com/lenary created https://github.com/llvm/llvm-project/pull/112983 I wanted to push up this draft, to check that I was going a reasonable direction with this work. It's still at an early stage. I tried just adding the double-wide VTs to the GPRPair register class, but that caused a lot of problems in type inference in `RISCVInstrInfoD.td`, around the Zdinx patterns. So to start with, I've essentially renamed the GPRPair classes that were needed for those into `GPRF64_RV32C` (and updated most uses of them). I've also moved any explicit uses of GPRPair in `RISCVInstrInfoD.td` to use these register classes rather than pairs. As it stands, all the in-tree tests are passing, which at least means this hasn't broken anything. (I ended up rearranging the RegisterInfo file to make the separate sections a little more obvious). I haven't got very far beyond that, except staring at the call sequences in a debugger for some simpler testcases (not committed). One big question in my head is around the `XLenPairVT` type, which I have provisionally specified as either `i64` or `i128` (this seems to be what required the changes in `RISCVGISel.td`). The alternative here is `v2i32` or `v2i64`, which might be neater, but that means it's harder to pass e.g. a `(u)int64_t` or a `(u)int128_t` from C (I believe). I'm also trying to be reasonably careful about not affecting the integer calling convention, where we only want (aligned) even-odd register pairs for 2*xlen types for varargs, and for non-variadic arguments cannot require an even-odd pair (as there is no "aligned" requirement for these). I know I've not really started the real SelectionDAG changes to deal with call lowering, legalisation, etc, let alone GlobalISel. As I approach these parts of the work I will keep pushing commits to this Draft PR. Tagging @topperc and @wangpc-pp as you've both expressed interest in this work. That said, I won't be at the dev meeting next week. --- This PR is stacked on top of #112563 - the final two commits are the only ones that matter, and when the work is in a better shape I intend to squash all the changes together and write a better error message. >From bbf0b885dc5912d4dc29abcec5fe7cee7cfd1758 Mon Sep 17 00:00:00 2001 From: Sam Elliott Date: Wed, 16 Oct 2024 05:04:45 -0700 Subject: [PATCH 1/4] [RISCV] Inline Assembly: RVC constraint and N modifier This change implements support for the `cr` and `cf` register constraints (which allocate a RVC GPR or RVC FPR respectively), and the `N` modifier (which prints the raw encoding of a register rather than the name). The intention behind these additions is to make it easier to use inline assembly when assembling raw instructions that are not supported by the compiler, for instance when experimenting with new instructions or when supporting proprietary extensions outside the toolchain. These implement part of my proposal in riscv-non-isa/riscv-c-api-doc#92 As part of the implementation, I felt there was not enough coverage of inline assembly and the "in X" floating-point extensions, so I have added more regression tests around these configurations. --- clang/lib/Basic/Targets/RISCV.cpp | 10 ++ clang/test/CodeGen/RISCV/riscv-inline-asm.c | 40 - llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp | 8 + llvm/lib/Target/RISCV/RISCVISelLowering.cpp | 18 ++ llvm/lib/Target/RISCV/RISCVRegisterInfo.td| 19 ++- .../RISCV/inline-asm-d-constraint-f.ll| 33 .../CodeGen/RISCV/inline-asm-d-modifier-N.ll | 109 .../RISCV/inline-asm-f-constraint-f.ll| 28 +++- .../CodeGen/RISCV/inline-asm-f-modifier-N.ll | 96 +++ llvm/test/CodeGen/RISCV/inline-asm-invalid.ll | 20 +++ .../RISCV/inline-asm-zdinx-constraint-r.ll| 92 ++ .../RISCV/inline-asm-zfh-constraint-f.ll | 41 + .../RISCV/inline-asm-zfh-modifier-N.ll| 157 + .../RISCV/inline-asm-zfinx-constraint-r.ll| 89 ++ .../RISCV/inline-asm-zhinx-constraint-r.ll| 158 ++ llvm/test/CodeGen/RISCV/inline-asm.ll | 66 .../CodeGen/RISCV/zdinx-asm-constraint.ll | 61 +++ 17 files changed, 1040 insertions(+), 5 deletions(-) create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-d-modifier-N.ll create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-f-modifier-N.ll create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zdinx-constraint-r.ll create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zfh-modifier-N.ll create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zfinx-constraint-r.ll create mode 100644 llvm/test/CodeGen/RISCV/inline-asm-zhinx-constraint-r.ll diff --git a/clang/lib/Basic/Targets/RISCV.cpp b/clang/lib/Basic/Targets/RISCV.cpp index 870f0f38bc3057..eaaba7642bd7b2 100644 --- a/clang/lib/Basic/Targets/RISCV.cpp +++ b/clang/lib/Basic/Targets/RISCV.cpp @@ -100,6 +100,14 @@ bool RISCVTargetInfo::validateAsmConstraint( case
[clang] [llvm] [RISCV] Add Smrnmi extension (PR #111668)
@@ -813,6 +815,12 @@ def MRET : Priv<"mret", 0b0011000>, Sched<[]> {
let rs1 = 0;
let rs2 = 0b00010;
}
+
+def MNRET : Priv<"mnret", 0b0111000>, Sched<[]> {
lenary wrote:
Nice, thanks!
https://github.com/llvm/llvm-project/pull/111668
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Add Smrnmi extension (PR #111668)
@@ -129,6 +129,7 @@ on support follow. ``Smcdeleg`` Supported ``Smcsrind`` Supported ``Smepmp``Supported + ``Smrnmi``Supported lenary wrote: This should probably be "Assembly Support" - some of the other `*ret` instructions have support in clang for `__attribute((interrupt()))` which doesn't yet exist for `mnret` - there's no obligation to add this support in the first PR, but this should mean no one expects it has the same level of featureas as the other `*ret` instructions. ```suggestion ``Smrnmi``Assembly Support ``` https://github.com/llvm/llvm-project/pull/111668 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Inline Assembly Support for GPR Pairs ('Pr') (PR #112983)
https://github.com/lenary edited https://github.com/llvm/llvm-project/pull/112983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Inline Assembly Support for GPR Pairs ('Pr') (PR #112983)
lenary wrote: > > The Arch64 MVT::i64x8 may be a way to work around this. We could have a > > special pair MVT only used by inline assembly. > > Ok, this sounds doable - so something like `MVT::xlen_pair` is the way I'll > lean, rather than a different type for rv32/rv64. Turns out that MVTs really want a size (unless they're overloadable, which is a complex and under-documented property), so I'll be going with two different MVTs rather than trying to share one. https://github.com/llvm/llvm-project/pull/112983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Inline Assembly Support for GPR Pairs ('Pr') (PR #112983)
lenary wrote: So, I've just pushed an update: - This now adds the two new MVTs, as suggested by Craig. I'm a little concerned if this causes a problem of using too much space in SelectionDAG tables. It's definitely a concern. - I'm using them from `getAsmOperandValueType`, which is the right place to say "use this type for an inline asm operand" when it doesn't fit into the calling convention. - I've added `BuildXLenPair` and `SplitXLenPair` ISD nodes, to represent building a pair and splitting it. Only the former is used so far. The names are bad, I'll work on better ones (`BuildPairGPR` etc is my current lean) - The implementation in `RISCVTargetLowering::splitValueIntoRegisterParts` is, as far as I can tell, now correct. The SelectionDAG looks right for inline assembly inputs. - I added a case to the switch in `RISCVDAGToDAGISel::Select` because that seemed easier than typing a lot of SelectionDAG stuff. I will probably turn this into TableGen tomorrow. I don't know whether I got too tired, or something else, but the implementation of `RISCVTargetLowering::joinRegisterPartsIntoValue` has not been making sense for me at all. I'd expect this to have an almost identical check as in `splitValueIntoRegisterParts`, and effectively do the opposite, but it doesn't. I think both `PartVT` and `ValueVT` end up as `riscv_i64_pair` for the rv64 testcase, once the `_out` function is uncommented. One of these comes from the constraint's RegClass's first legal type (defensible), the other I'm a bit more confused by, and think it might be coming from `getAsmOperandValueType`, but I'm not sure I traced this back correctly. I'll look again tomorrow. https://github.com/llvm/llvm-project/pull/112983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Inline Assembly Support for GPR Pairs ('Pr') (PR #112983)
lenary wrote: I think the first thing I might do tomorrow is some of the NFC cleanups and commenting that is in this PR. I'm not sure the register class renaming can happen quite yet. https://github.com/llvm/llvm-project/pull/112983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Inline Assembly Support for GPR Pairs ('Pr') (PR #112983)
https://github.com/lenary edited https://github.com/llvm/llvm-project/pull/112983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Inline Assembly: RVC constraint and N modifier (PR #112561)
lenary wrote: It would be great to get more comments than just Craig, so I can be sure that there's wider consensus that adding this is good. https://github.com/llvm/llvm-project/pull/112561 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Add Smrnmi extension (PR #111668)
@@ -813,6 +815,12 @@ def MRET : Priv<"mret", 0b0011000>, Sched<[]> {
let rs1 = 0;
let rs2 = 0b00010;
}
+
+def MNRET : Priv<"mnret", 0b0111000>, Sched<[]> {
lenary wrote:
Does this need a `Requires=[HasStdExtSmrnmi]` (And a definition of
`HasStdExtSmrnmi`)?
https://github.com/llvm/llvm-project/pull/111668
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Inline Assembly Support for GPR Pairs ('Pr') (PR #112983)
lenary wrote: Sorry, got the rebase slightly wrong. Will re-do it tomorrow. Tests will likely fail in the meantime. This only really affects the branch-relaxation tests. https://github.com/llvm/llvm-project/pull/112983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Inline Assembly Support for GPR Pairs ('Pr') (PR #112983)
lenary wrote: ping? https://github.com/llvm/llvm-project/pull/112983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Inline Assembly Support for GPR Pairs ('Pr') (PR #112983)
@@ -2224,6 +2231,17 @@ bool RISCVTargetLowering::isExtractSubvectorCheap(EVT
ResVT, EVT SrcVT,
return Index == 0 || Index == ResElts;
}
+EVT RISCVTargetLowering::getAsmOperandValueType(const DataLayout &DL, Type *Ty,
+bool AllowUnknown) const {
+ if (!Subtarget.is64Bit() && Ty->isIntegerTy(64))
lenary wrote:
This file tends to mostly use `Subtarget.is64Bit()` rather than the
`isRV64`/`isRV32`, which is what I followed here. This might get a lot more
simple if I move to trying `MVT::Other` though.
https://github.com/llvm/llvm-project/pull/112983
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Inline Assembly Support for GPR Pairs ('Pr') (PR #112983)
https://github.com/lenary edited https://github.com/llvm/llvm-project/pull/112983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [RISCV] Inline Assembly Support for GPR Pairs ('Pr') (PR #112983)
lenary wrote: I gave up on using `splitValueIntoRegisterParts` and `joinRegisterPartsIntoValue`, and instead added a custom legalisation of `BITCAST` with the 2*xlen type, which matches what we do for `BuildPairF64` and `SplitF64`. This ended up being much more "symmetrical", which was nice. I'm still doing Selection entirely in C++, as I think we'd need to go to C++ anyway to emit the right REG_SEQUENCE and EXTRACT_SUBREG. I've not implemented anything in `RISCVTargetLowering::PerformDAGCombine` for `BuildPairGPR` and `SplitPairGPR` - though I see there's something in there for `SplitF64`, and not all of it is FP-related. I don't know how much of a difference these combines will make when the generated instructions are not as expensive as the stack slot that `BuildPairF64`/`SplitF64` sometimes needs. Instead of looking at combines, I'm going to try to get the tests to work with GlobalISel. https://github.com/llvm/llvm-project/pull/112983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
