mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-26 16:36:07 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/clang/lib/Basic/Targets/RISCV.cpp

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

606 lines
20 KiB
C++
Raw Normal View History

[RISCV] Replace RISCV -> RISC-V in comments. NFC To be consistent with RISC-V branding guidelines https://riscv.org/about/risc-v-branding-guidelines/ Think we should be using RISC-V where possible. More patches will follow. Reviewed By: asb Differential Revision: https://reviews.llvm.org/D146449
2023-03-27 09:15:53 -07:00
//===--- RISCV.cpp - Implement RISC-V target feature support --------------===//
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 13:36:56 +00:00
//
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-19 08:50:56 +00:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 13:36:56 +00:00
//
//===----------------------------------------------------------------------===//
//
[RISCV] Replace RISCV -> RISC-V in comments. NFC To be consistent with RISC-V branding guidelines https://riscv.org/about/risc-v-branding-guidelines/ Think we should be using RISC-V where possible. More patches will follow. Reviewed By: asb Differential Revision: https://reviews.llvm.org/D146449
2023-03-27 09:15:53 -07:00
// This file implements RISC-V TargetInfo objects.
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 13:36:56 +00:00
//
//===----------------------------------------------------------------------===//
#include "RISCV.h"
[RISCV] Unify the arch string parsing logic to to RISCVISAInfo. How many place you need to modify when implementing a new extension for RISC-V? At least 7 places as I know: - Add new SubtargetFeature at RISCV.td - -march parser in RISCV.cpp - RISCVTargetInfo::initFeatureMap@RISCV.cpp for handling feature vector. - RISCVTargetInfo::getTargetDefines@RISCV.cpp for pre-define marco. - Arch string parser for ELF attribute in RISCVAsmParser.cpp - ELF attribute emittion in RISCVAsmParser.cpp, and make sure it's in canonical order... - ELF attribute emittion in RISCVTargetStreamer.cpp, and again, must in canonical order... And now, this patch provide an unified infrastructure for handling (almost) everything of RISC-V arch string. After this patch, you only need to update 2 places for implement an extension for RISC-V: - Add new SubtargetFeature at RISCV.td, hmmm, it's hard to avoid. - Add new entry to RISCVSupportedExtension@RISCVISAInfo.cpp or SupportedExperimentalExtensions@RISCVISAInfo.cpp . Most codes are come from existing -march parser, but with few new feature/bug fixes: - Accept version for -march, e.g. -march=rv32i2p0. - Reject version info with `p` but without minor version number like `rv32i2p`. Differential Revision: https://reviews.llvm.org/D105168
2021-06-23 16:18:54 +08:00
#include "clang/Basic/Diagnostic.h"
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 13:36:56 +00:00
#include "clang/Basic/MacroBuilder.h"
[RISCV] Add vadd with mask and without mask builtin. Demonstrate how to add RISC-V V builtins and lower them to IR intrinsics for V extension. Authored-by: Roger Ferrer Ibanez <rofirrim@gmail.com> Co-Authored-by: Hsiangkai Wang <kai.wang@sifive.com> Differential Revision: https://reviews.llvm.org/D93446
2021-02-04 12:57:44 +08:00
#include "clang/Basic/TargetBuiltins.h"
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 13:36:56 +00:00
#include "llvm/ADT/StringSwitch.h"
[RISCV] Unify the arch string parsing logic to to RISCVISAInfo. How many place you need to modify when implementing a new extension for RISC-V? At least 7 places as I know: - Add new SubtargetFeature at RISCV.td - -march parser in RISCV.cpp - RISCVTargetInfo::initFeatureMap@RISCV.cpp for handling feature vector. - RISCVTargetInfo::getTargetDefines@RISCV.cpp for pre-define marco. - Arch string parser for ELF attribute in RISCVAsmParser.cpp - ELF attribute emittion in RISCVAsmParser.cpp, and make sure it's in canonical order... - ELF attribute emittion in RISCVTargetStreamer.cpp, and again, must in canonical order... And now, this patch provide an unified infrastructure for handling (almost) everything of RISC-V arch string. After this patch, you only need to update 2 places for implement an extension for RISC-V: - Add new SubtargetFeature at RISCV.td, hmmm, it's hard to avoid. - Add new entry to RISCVSupportedExtension@RISCVISAInfo.cpp or SupportedExperimentalExtensions@RISCVISAInfo.cpp . Most codes are come from existing -march parser, but with few new feature/bug fixes: - Accept version for -march, e.g. -march=rv32i2p0. - Reject version info with `p` but without minor version number like `rv32i2p`. Differential Revision: https://reviews.llvm.org/D105168
2021-06-23 16:18:54 +08:00
#include "llvm/Support/raw_ostream.h"
[TargetParser] Generate the defs for RISCV CPUs using llvm-tblgen. Rework the change to prevent build failures. NFCI. The failing code was submitted as cf7a8305a2b4ddfd299c748136cb9a2960ef7089 and reverted via 8bd65e535fb33bc48805bafed8217b16a853e158. The rework in this new commit prevents failures like the following: FAILED: tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Targets/RISCV.cpp.o /usr/bin/c++ [bunch of non interesting stuff] -c <path-to>/llvm-project/clang/lib/Basic/Targets/RISCV.cpp In file included from <path-to>/llvm-project/clang/lib/Basic/Targets/RISCV.cpp:19: <path-to>/llvm-project/llvm/include/llvm/TargetParser/RISCVTargetParser.h:29:10: fatal error: llvm/TargetParser/RISCVTargetParserDef.inc: No such file or directory 29 | #include "llvm/TargetParser/RISCVTargetParserDef.inc" | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ These failures happen because the library LLVMTargetParser depends on RISCVTargetParserTableGen, which is a tablegen target that generates the list of CPUs in llvm/TargetParser/RISCVTargetParserDef.inc. This *.inc file is included by the public header file llvm/TargetParser/RISCVTargetParser.h. The header file llvm/TargetParser/RISCVTargetParser.h is also used in components (clangDriver and clangBasic) that link into LLVMTargetParser, but on some configurations such components might end up being built before TargetParser is ready. The fix is to make sure that clangDriver and clangBasic depend on the tablegen target RISCVTargetParserTableGen, which generates the .inc file whether or not LLVMTargetParser is ready. WRT the original patch at https://reviews.llvm.org/D137517, this commit is just adding RISCVTargetParserTableGen in the DEPENDS list of clangDriver and clangBasic.
2023-01-11 10:23:55 +01:00
#include "llvm/TargetParser/RISCVTargetParser.h"
[Targets] Use std::optional in RISCV.cpp (NFC) This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-09 22:52:29 -08:00
#include <optional>
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 13:36:56 +00:00
using namespace clang;
using namespace clang::targets;
ArrayRef<const char *> RISCVTargetInfo::getGCCRegNames() const {
[Clang][RISCV] Support CSRs in clobbered registers of inline assembly (#67646) To match GCC's behaviors. Fixes #67596
2023-10-23 11:15:20 +08:00
// clang-format off
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 13:36:56 +00:00
static const char *const GCCRegNames[] = {
[RISCV] Add support for floating point registers in inlineasm This adds support for parsing/emitting in IR the floating-point RISC-V registers in inline assembly clobber lists. Differential Revision: https://reviews.llvm.org/D64737 llvm-svn: 367399
2019-07-31 09:12:00 +00:00
// Integer registers
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 13:36:56 +00:00
"x0", "x1", "x2", "x3", "x4", "x5", "x6", "x7",
"x8", "x9", "x10", "x11", "x12", "x13", "x14", "x15",
"x16", "x17", "x18", "x19", "x20", "x21", "x22", "x23",
[RISCV] Add support for floating point registers in inlineasm This adds support for parsing/emitting in IR the floating-point RISC-V registers in inline assembly clobber lists. Differential Revision: https://reviews.llvm.org/D64737 llvm-svn: 367399
2019-07-31 09:12:00 +00:00
"x24", "x25", "x26", "x27", "x28", "x29", "x30", "x31",
// Floating point registers
"f0", "f1", "f2", "f3", "f4", "f5", "f6", "f7",
"f8", "f9", "f10", "f11", "f12", "f13", "f14", "f15",
"f16", "f17", "f18", "f19", "f20", "f21", "f22", "f23",
[RISCV] Add inline asm constraint 'vr' and 'vm' in Clang for RISC-V 'V'. Add asm constraint 'vr' for vector registers. Add asm constraint 'vm' for vector mask registers. Differential Revision: https://reviews.llvm.org/D98616
2021-03-29 18:27:27 +08:00
"f24", "f25", "f26", "f27", "f28", "f29", "f30", "f31",
// Vector registers
"v0", "v1", "v2", "v3", "v4", "v5", "v6", "v7",
"v8", "v9", "v10", "v11", "v12", "v13", "v14", "v15",
"v16", "v17", "v18", "v19", "v20", "v21", "v22", "v23",
[Clang][RISCV] Support CSRs in clobbered registers of inline assembly (#67646) To match GCC's behaviors. Fixes #67596
2023-10-23 11:15:20 +08:00
"v24", "v25", "v26", "v27", "v28", "v29", "v30", "v31",
// CSRs
[RISCV][VCIX] Add vcix_state to GNU inline assembly register set (#106914) https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/56 Resolved https://github.com/llvm/llvm-project/issues/106700. This enables inline asm to have vcix_state to be a clobbered register thus disable reordering between VCIX intrinsics and inline asm.
2024-09-30 23:52:35 -07:00
"fflags", "frm", "vtype", "vl", "vxsat", "vxrm", "sf.vcix_state"
[Clang][RISCV] Support CSRs in clobbered registers of inline assembly (#67646) To match GCC's behaviors. Fixes #67596
2023-10-23 11:15:20 +08:00
};
// clang-format on
Move from llvm::makeArrayRef to ArrayRef deduction guides - clang/ part This is a follow-up to https://reviews.llvm.org/D140896, split into several parts as it touches a lot of files. Differential Revision: https://reviews.llvm.org/D141139
2023-01-06 16:56:23 +01:00
return llvm::ArrayRef(GCCRegNames);
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 13:36:56 +00:00
}
ArrayRef<TargetInfo::GCCRegAlias> RISCVTargetInfo::getGCCRegAliases() const {
static const TargetInfo::GCCRegAlias GCCRegAliases[] = {
[RISCV] Add support for floating point registers in inlineasm This adds support for parsing/emitting in IR the floating-point RISC-V registers in inline assembly clobber lists. Differential Revision: https://reviews.llvm.org/D64737 llvm-svn: 367399
2019-07-31 09:12:00 +00:00
{{"zero"}, "x0"}, {{"ra"}, "x1"}, {{"sp"}, "x2"}, {{"gp"}, "x3"},
{{"tp"}, "x4"}, {{"t0"}, "x5"}, {{"t1"}, "x6"}, {{"t2"}, "x7"},
{{"s0"}, "x8"}, {{"s1"}, "x9"}, {{"a0"}, "x10"}, {{"a1"}, "x11"},
{{"a2"}, "x12"}, {{"a3"}, "x13"}, {{"a4"}, "x14"}, {{"a5"}, "x15"},
{{"a6"}, "x16"}, {{"a7"}, "x17"}, {{"s2"}, "x18"}, {{"s3"}, "x19"},
{{"s4"}, "x20"}, {{"s5"}, "x21"}, {{"s6"}, "x22"}, {{"s7"}, "x23"},
{{"s8"}, "x24"}, {{"s9"}, "x25"}, {{"s10"}, "x26"}, {{"s11"}, "x27"},
{{"t3"}, "x28"}, {{"t4"}, "x29"}, {{"t5"}, "x30"}, {{"t6"}, "x31"},
{{"ft0"}, "f0"}, {{"ft1"}, "f1"}, {{"ft2"}, "f2"}, {{"ft3"}, "f3"},
{{"ft4"}, "f4"}, {{"ft5"}, "f5"}, {{"ft6"}, "f6"}, {{"ft7"}, "f7"},
{{"fs0"}, "f8"}, {{"fs1"}, "f9"}, {{"fa0"}, "f10"}, {{"fa1"}, "f11"},
{{"fa2"}, "f12"}, {{"fa3"}, "f13"}, {{"fa4"}, "f14"}, {{"fa5"}, "f15"},
{{"fa6"}, "f16"}, {{"fa7"}, "f17"}, {{"fs2"}, "f18"}, {{"fs3"}, "f19"},
{{"fs4"}, "f20"}, {{"fs5"}, "f21"}, {{"fs6"}, "f22"}, {{"fs7"}, "f23"},
{{"fs8"}, "f24"}, {{"fs9"}, "f25"}, {{"fs10"}, "f26"}, {{"fs11"}, "f27"},
{{"ft8"}, "f28"}, {{"ft9"}, "f29"}, {{"ft10"}, "f30"}, {{"ft11"}, "f31"}};
Move from llvm::makeArrayRef to ArrayRef deduction guides - clang/ part This is a follow-up to https://reviews.llvm.org/D140896, split into several parts as it touches a lot of files. Differential Revision: https://reviews.llvm.org/D141139
2023-01-06 16:56:23 +01:00
return llvm::ArrayRef(GCCRegAliases);
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 13:36:56 +00:00
}
[RISCV] Add inline asm constraints I, J & K for RISC-V This allows the constraints I, J & K to be used in inline asm for RISC-V, with the following semantics (equivalent to GCC): I: Any 12-bit signed immediate. J: Integer zero only. K: Any 5-bit unsigned immediate. See the GCC definitions here: https://gcc.gnu.org/onlinedocs/gccint/Machine-Constraints.html Differential Revision: https://reviews.llvm.org/D54091 llvm-svn: 363055
2019-06-11 12:44:01 +00:00
bool RISCVTargetInfo::validateAsmConstraint(
const char *&Name, TargetInfo::ConstraintInfo &Info) const {
switch (*Name) {
default:
return false;
case 'I':
// A 12-bit signed immediate.
Info.setRequiresImmediate(-2048, 2047);
return true;
case 'J':
// Integer zero.
Info.setRequiresImmediate(0);
return true;
case 'K':
// A 5-bit unsigned immediate for CSR access instructions.
Info.setRequiresImmediate(0, 31);
return true;
[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 llvm-svn: 367403
2019-07-31 09:45:55 +00:00
case 'f':
// A floating-point register.
Info.setAllowsRegister();
return true;
[RISCV] Add inline asm constraint A for RISC-V This allows the constraint A to be used in inline asm for RISC-V, which allows an address held in a register to be used. This patch adds the minimal amount of code required to get operands with the right constraints to compile. Differential Revision: https://reviews.llvm.org/D54295 llvm-svn: 369093
2019-08-16 10:23:56 +00:00
case 'A':
// An address that is held in a general-purpose register.
Info.setAllowsMemory();
return true;
[RISCV] Support constraint "s" (#80201) GCC has supported a generic constraint "s" for a long time (since at least 1992), which references a symbol or label with an optional constant offset. "i" is a superset that also supports a constant integer. GCC's RISC-V port also supports a machine-specific constraint "S", which cannot be used with a preemptible symbol. (We don't bother to check preemptibility.) In PIC code, an external symbol is preemptible by default, making "S" less useful if you want to create an artificial reference for linker garbage collection, or define sections to hold symbol addresses: ``` void fun(); // error: impossible constraint in ‘asm’ for riscv64-linux-gnu-gcc -fpie/-fpic void foo() { asm(".reloc ., BFD_RELOC_NONE, %0" :: "S"(fun)); } // good even if -fpie/-fpic void foo() { asm(".reloc ., BFD_RELOC_NONE, %0" :: "s"(fun)); } ``` This patch adds support for "s". Modify https://reviews.llvm.org/D105254 ("S") to handle multi-depth GEPs (https://reviews.llvm.org/D61560).
2024-02-01 10:18:42 -08:00
case 's':
case 'S': // A symbol or label reference with a constant offset
[RISCV] Support machine constraint "S" Similar to D46745, "S" represents an absolute symbolic operand, which can be used to specify the access models, e.g. extern int var; void *addr_via_asm() { void *ret; asm("lui %0, %%hi(%1)\naddi %0,%0,%%lo(%1)" : "=r"(ret) : "S"(&var)); return ret; } 'S' is documented in trunk GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101275 Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D105254
2021-07-13 09:30:09 -07:00
Info.setAllowsRegister();
return true;
[RISCV] Inline Assembly: RVC constraint and N modifier (#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.
2024-10-18 11:40:38 +02:00
case 'c':
// A RVC register - GPR or FPR
[RISCV] Support cR Inline Asm Constraint (#124174) This denotes RVC-compatible GPR Pairs, which are used by the Zclsd extension. C API PR: riscv-non-isa/riscv-c-api-doc#102
2025-01-23 16:19:19 -08:00
if (Name[1] == 'r' || Name[1] == 'R' || Name[1] == 'f') {
[RISCV] Inline Assembly: RVC constraint and N modifier (#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.
2024-10-18 11:40:38 +02:00
Info.setAllowsRegister();
Name += 1;
return true;
}
return false;
[RISCV] Inline Assembly Support for GPR Pairs ('R') (#112983) This patch adds support for getting even-odd general purpose register pairs into and out of inline assembly using the `R` constraint as proposed in riscv-non-isa/riscv-c-api-doc#92 There are a few different pieces to this patch, each of which need their own explanation. - Renames the Register Class used for f64 values on rv32i_zdinx from `GPRPair*` to `GPRF64Pair*`. These register classes are kept broadly unmodified, as their primary value type is used for type inference over selection patterns. This rename affects quite a lot of files. - Adds new `GPRPair*` register classes which will be used for `R` constraints and for instructions that need an even-odd GPR pair. This new type is used for `amocas.d.*`(rv32) and `amocas.q.*`(rv64) in Zacas, instead of the `GPRF64Pair` class being used before. - Marks the new `GPRPair` class legal as for holding a `MVT::Untyped`. Two new RISCVISD node types are added for creating and destructing a pair - `BuildGPRPair` and `SplitGPRPair`, and are introduced when bitcasting to/from the pair type and `untyped`. - Adds functionality to `splitValueIntoRegisterParts` and `joinRegisterPartsIntoValue` to handle changing `i<2*xlen>` MVTs into `untyped` pairs. - Adds an override for `getNumRegisters` to ensure that `i<2*xlen>` values, when going to/from inline assembly, only allocate one (pair) register (they would otherwise allocate two). This is due to a bug in SelectionDAGBuilder.cpp which other backends also work around. - Ensures that Clang understands that `R` is a valid inline assembly constraint. - This also allows `R` to be used for `f64` types on `rv32_zdinx` architectures, where doubles are stored in a GPR pair.
2024-11-18 17:45:58 +00:00
case 'R':
// An even-odd GPR pair
Info.setAllowsRegister();
return true;
[RISCV] Add inline asm constraint 'vr' and 'vm' in Clang for RISC-V 'V'. Add asm constraint 'vr' for vector registers. Add asm constraint 'vm' for vector mask registers. Differential Revision: https://reviews.llvm.org/D98616
2021-03-29 18:27:27 +08:00
case 'v':
// A vector register.
[RISCV] Add support for inline asm constraint vd (#111653) It constrains vector registers excluding v0. Refer to https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html RISC-V part. This patch also adds a testcase for constraints vr, vd and vm.
2024-10-14 10:47:59 +08:00
if (Name[1] == 'r' || Name[1] == 'd' || Name[1] == 'm') {
[RISCV] Add inline asm constraint 'vr' and 'vm' in Clang for RISC-V 'V'. Add asm constraint 'vr' for vector registers. Add asm constraint 'vm' for vector mask registers. Differential Revision: https://reviews.llvm.org/D98616
2021-03-29 18:27:27 +08:00
Info.setAllowsRegister();
Name += 1;
return true;
}
return false;
}
}
std::string RISCVTargetInfo::convertConstraint(const char *&Constraint) const {
std::string R;
switch (*Constraint) {
[RISCV] Inline Assembly: RVC constraint and N modifier (#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.
2024-10-18 11:40:38 +02:00
// c* and v* are two-letter constraints on RISC-V.
case 'c':
[RISCV] Add inline asm constraint 'vr' and 'vm' in Clang for RISC-V 'V'. Add asm constraint 'vr' for vector registers. Add asm constraint 'vm' for vector mask registers. Differential Revision: https://reviews.llvm.org/D98616
2021-03-29 18:27:27 +08:00
case 'v':
[RISCV] Rename vector inline constraint from 'v' to 'vr' and 'vm' in IR. Differential Revision: https://reviews.llvm.org/D107139
2021-07-30 17:10:30 +08:00
R = std::string("^") + std::string(Constraint, 2);
[RISCV] Add inline asm constraint 'vr' and 'vm' in Clang for RISC-V 'V'. Add asm constraint 'vr' for vector registers. Add asm constraint 'vm' for vector mask registers. Differential Revision: https://reviews.llvm.org/D98616
2021-03-29 18:27:27 +08:00
Constraint += 1;
break;
default:
R = TargetInfo::convertConstraint(Constraint);
break;
[RISCV] Add inline asm constraints I, J & K for RISC-V This allows the constraints I, J & K to be used in inline asm for RISC-V, with the following semantics (equivalent to GCC): I: Any 12-bit signed immediate. J: Integer zero only. K: Any 5-bit unsigned immediate. See the GCC definitions here: https://gcc.gnu.org/onlinedocs/gccint/Machine-Constraints.html Differential Revision: https://reviews.llvm.org/D54091 llvm-svn: 363055
2019-06-11 12:44:01 +00:00
}
[RISCV] Add inline asm constraint 'vr' and 'vm' in Clang for RISC-V 'V'. Add asm constraint 'vr' for vector registers. Add asm constraint 'vm' for vector mask registers. Differential Revision: https://reviews.llvm.org/D98616
2021-03-29 18:27:27 +08:00
return R;
[RISCV] Add inline asm constraints I, J & K for RISC-V This allows the constraints I, J & K to be used in inline asm for RISC-V, with the following semantics (equivalent to GCC): I: Any 12-bit signed immediate. J: Integer zero only. K: Any 5-bit unsigned immediate. See the GCC definitions here: https://gcc.gnu.org/onlinedocs/gccint/Machine-Constraints.html Differential Revision: https://reviews.llvm.org/D54091 llvm-svn: 363055
2019-06-11 12:44:01 +00:00
}
[NFC][RISCV] Extract utility to calculate value through MajorVersion and MinorVersion Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D139025
2022-12-20 02:34:52 -08:00
static unsigned getVersionValue(unsigned MajorVersion, unsigned MinorVersion) {
return MajorVersion * 1000000 + MinorVersion * 1000;
}
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 13:36:56 +00:00
void RISCVTargetInfo::getTargetDefines(const LangOptions &Opts,
MacroBuilder &Builder) const {
Builder.defineMacro("__riscv");
[RISCV] Use Triple::isRISCV64(). NFC
2023-12-09 14:02:11 -08:00
bool Is64Bit = getTriple().isRISCV64();
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 13:36:56 +00:00
Builder.defineMacro("__riscv_xlen", Is64Bit ? "64" : "32");
[RISCV] Define __riscv_cmodel_medlow and __riscv_cmodel_medany correctly RISC-V LLVM was only implement small/medlow code model, so it defined __riscv_cmodel_medlow directly without check. Now, we have medium/medany code model in RISC-V back-end, it should define according the actually code model. Reviewed By: lewis-revill Differential Revision: https://reviews.llvm.org/D67065 llvm-svn: 372078
2019-09-17 08:09:56 +00:00
StringRef CodeModel = getTargetOpts().CodeModel;
[RISCV] Unify the arch string parsing logic to to RISCVISAInfo. How many place you need to modify when implementing a new extension for RISC-V? At least 7 places as I know: - Add new SubtargetFeature at RISCV.td - -march parser in RISCV.cpp - RISCVTargetInfo::initFeatureMap@RISCV.cpp for handling feature vector. - RISCVTargetInfo::getTargetDefines@RISCV.cpp for pre-define marco. - Arch string parser for ELF attribute in RISCVAsmParser.cpp - ELF attribute emittion in RISCVAsmParser.cpp, and make sure it's in canonical order... - ELF attribute emittion in RISCVTargetStreamer.cpp, and again, must in canonical order... And now, this patch provide an unified infrastructure for handling (almost) everything of RISC-V arch string. After this patch, you only need to update 2 places for implement an extension for RISC-V: - Add new SubtargetFeature at RISCV.td, hmmm, it's hard to avoid. - Add new entry to RISCVSupportedExtension@RISCVISAInfo.cpp or SupportedExperimentalExtensions@RISCVISAInfo.cpp . Most codes are come from existing -march parser, but with few new feature/bug fixes: - Accept version for -march, e.g. -march=rv32i2p0. - Reject version info with `p` but without minor version number like `rv32i2p`. Differential Revision: https://reviews.llvm.org/D105168
2021-06-23 16:18:54 +08:00
unsigned FLen = ISAInfo->getFLen();
[RISCV] Add the zvl extension according to the v1.0 spec `zvl` is the new standard vector extension that specifies the minimum vector length of the vector extension. The `zvl` extension is related to the `zve` extension and other updates that are added in v1.0. According to https://github.com/riscv-non-isa/riscv-c-api-doc/pull/21, Clang defines macro `__riscv_v_min_vlen` for `zvl` and it can be used for applications that uses the vector extension. LLVM checks whether the option `riscv-v-vector-bits-min` (if specified) matches the `zvl*` extension specified. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D108694
2021-10-23 03:18:24 -07:00
unsigned MinVLen = ISAInfo->getMinVLen();
[RISCV] Add the zve extension according to the v1.0 spec `zve` is the new standard vector extension to specify varying degrees of vector support for embedding processors. The `zve` extension is related to the `zvl` extension and other updates that are added in v1.0. According to https://github.com/riscv-non-isa/riscv-c-api-doc/pull/21, Clang defines macro `__riscv_v_max_elen`, `__riscv_v_max_elen_fp` for `zve` and it can be used by applications that uses the vector extension. Authored by: Zakk Chen <zakk.chen@sifive.com> @khchen Co-Authored by: Eop Chen <eop.chen@sifive.com> @eopXD Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D112408
2021-10-27 05:52:20 -07:00
unsigned MaxELen = ISAInfo->getMaxELen();
unsigned MaxELenFp = ISAInfo->getMaxELenFp();
[RISCV] Define __riscv_cmodel_medlow and __riscv_cmodel_medany correctly RISC-V LLVM was only implement small/medlow code model, so it defined __riscv_cmodel_medlow directly without check. Now, we have medium/medany code model in RISC-V back-end, it should define according the actually code model. Reviewed By: lewis-revill Differential Revision: https://reviews.llvm.org/D67065 llvm-svn: 372078
2019-09-17 08:09:56 +00:00
if (CodeModel == "default")
CodeModel = "small";
if (CodeModel == "small")
Builder.defineMacro("__riscv_cmodel_medlow");
else if (CodeModel == "medium")
Builder.defineMacro("__riscv_cmodel_medany");
[RISCV] Emit predefined macro __riscv_cmodel_large for large code model (#108131) Co-authored-by: patrick <patrick@andestech.com>
2024-09-13 10:37:48 +08:00
else if (CodeModel == "large")
Builder.defineMacro("__riscv_cmodel_large");
[RISCV] Hard float ABI support The RISC-V hard float calling convention requires the frontend to: * Detect cases where, once "flattened", a struct can be passed using int+fp or fp+fp registers under the hard float ABI and coerce to the appropriate type(s) * Track usage of GPRs and FPRs in order to gate the above, and to determine when signext/zeroext attributes must be added to integer scalars This patch attempts to do this in compliance with the documented ABI, and uses ABIArgInfo::CoerceAndExpand in order to do this. @rjmccall, as author of that code I've tagged you as reviewer for initial feedback on my usage. Note that a previous version of the ABI indicated that when passing an int+fp struct using a GPR+FPR, the int would need to be sign or zero-extended appropriately. GCC never did this and the ABI was changed, which makes life easier as ABIArgInfo::CoerceAndExpand can't currently handle sign/zero-extension attributes. Re-landed after backing out 366450 due to missed hunks. Differential Revision: https://reviews.llvm.org/D60456 llvm-svn: 366480
2019-07-18 18:29:59 +00:00
StringRef ABIName = getABI();
if (ABIName == "ilp32f" || ABIName == "lp64f")
Builder.defineMacro("__riscv_float_abi_single");
else if (ABIName == "ilp32d" || ABIName == "lp64d")
Builder.defineMacro("__riscv_float_abi_double");
else
Builder.defineMacro("__riscv_float_abi_soft");
[PATCH] [RISCV] Extend getTargetDefines for RISCVTargetInfo Summary: This patch extend getTargetDefines and implement handleTargetFeatures and hasFeature. and define corresponding marco for those features. Reviewers: asb, apazos, eli.friedman Differential Revision: https://reviews.llvm.org/D44727 Patch by Kito Cheng. llvm-svn: 329278
2018-04-05 12:54:00 +00:00
[RISCV] CodeGen of RVE and ilp32e/lp64e ABIs (#76777) This commit includes the necessary changes to clang and LLVM to support codegen of `RVE` and the `ilp32e`/`lp64e` ABIs. The differences between `RVE` and `RVI` are: * `RVE` reduces the integer register count to 16(x0-x16). * The ABI should be `ilp32e` for 32 bits and `lp64e` for 64 bits. `RVE` can be combined with all current standard extensions. The central changes in ilp32e/lp64e ABI, compared to ilp32/lp64 are: * Only 6 integer argument registers (rather than 8). * Only 2 callee-saved registers (rather than 12). * A Stack Alignment of 32bits (rather than 128bits). * ilp32e isn't compatible with D ISA extension. If `ilp32e` or `lp64` is used with an ISA that has any of the registers x16-x31 and f0-f31, then these registers are considered temporaries. To be compatible with the implementation of ilp32e in GCC, we don't use aligned registers to pass variadic arguments and set stack alignment\ to 4-bytes for types with length of 2*XLEN. FastCC is also supported on RVE, while GHC isn't since there is only one avaiable register. Differential Revision: https://reviews.llvm.org/D70401
2024-01-16 20:44:30 +08:00
if (ABIName == "ilp32e" || ABIName == "lp64e")
[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 llvm-svn: 370709
2019-09-03 08:47:58 +00:00
Builder.defineMacro("__riscv_abi_rve");
[RISCV] Implement new architecture extension macros This adds support for the new architecture extension test macros as defined in the C-API Document: https://github.com/riscv/riscv-c-api-doc/blob/master/riscv-c-api.md Extension versions have been taken from what are used in RISCVTargetStreamer for ratified extensions, and the -march parser for experimental extensions. Differential Revision: https://reviews.llvm.org/D94403
2021-01-25 08:58:46 +00:00
Builder.defineMacro("__riscv_arch_test");
[RISCV] Unify the arch string parsing logic to to RISCVISAInfo. How many place you need to modify when implementing a new extension for RISC-V? At least 7 places as I know: - Add new SubtargetFeature at RISCV.td - -march parser in RISCV.cpp - RISCVTargetInfo::initFeatureMap@RISCV.cpp for handling feature vector. - RISCVTargetInfo::getTargetDefines@RISCV.cpp for pre-define marco. - Arch string parser for ELF attribute in RISCVAsmParser.cpp - ELF attribute emittion in RISCVAsmParser.cpp, and make sure it's in canonical order... - ELF attribute emittion in RISCVTargetStreamer.cpp, and again, must in canonical order... And now, this patch provide an unified infrastructure for handling (almost) everything of RISC-V arch string. After this patch, you only need to update 2 places for implement an extension for RISC-V: - Add new SubtargetFeature at RISCV.td, hmmm, it's hard to avoid. - Add new entry to RISCVSupportedExtension@RISCVISAInfo.cpp or SupportedExperimentalExtensions@RISCVISAInfo.cpp . Most codes are come from existing -march parser, but with few new feature/bug fixes: - Accept version for -march, e.g. -march=rv32i2p0. - Reject version info with `p` but without minor version number like `rv32i2p`. Differential Revision: https://reviews.llvm.org/D105168
2021-06-23 16:18:54 +08:00
for (auto &Extension : ISAInfo->getExtensions()) {
auto ExtName = Extension.first;
auto ExtInfo = Extension.second;
[RISCV] Deduplicate version struct in RISCVISAInfo. NFC (#77645) We have two structs for representing the version of an extension in RISCVISAInfo, RISCVExtensionInfo and RISCVExtensionVersion, both with the exact same fields. This patch deduplicates them.
2024-01-11 15:07:24 +07:00
Builder.defineMacro(Twine("__riscv_", ExtName),
Twine(getVersionValue(ExtInfo.Major, ExtInfo.Minor)));
[RISCV] Unify the arch string parsing logic to to RISCVISAInfo. How many place you need to modify when implementing a new extension for RISC-V? At least 7 places as I know: - Add new SubtargetFeature at RISCV.td - -march parser in RISCV.cpp - RISCVTargetInfo::initFeatureMap@RISCV.cpp for handling feature vector. - RISCVTargetInfo::getTargetDefines@RISCV.cpp for pre-define marco. - Arch string parser for ELF attribute in RISCVAsmParser.cpp - ELF attribute emittion in RISCVAsmParser.cpp, and make sure it's in canonical order... - ELF attribute emittion in RISCVTargetStreamer.cpp, and again, must in canonical order... And now, this patch provide an unified infrastructure for handling (almost) everything of RISC-V arch string. After this patch, you only need to update 2 places for implement an extension for RISC-V: - Add new SubtargetFeature at RISCV.td, hmmm, it's hard to avoid. - Add new entry to RISCVSupportedExtension@RISCVISAInfo.cpp or SupportedExperimentalExtensions@RISCVISAInfo.cpp . Most codes are come from existing -march parser, but with few new feature/bug fixes: - Accept version for -march, e.g. -march=rv32i2p0. - Reject version info with `p` but without minor version number like `rv32i2p`. Differential Revision: https://reviews.llvm.org/D105168
2021-06-23 16:18:54 +08:00
}
[RISCV] Make M imply Zmmul (#95070) According to the spec, M implies Zmmul.
2024-06-21 11:11:10 +08:00
if (ISAInfo->hasExtension("zmmul"))
[PATCH] [RISCV] Extend getTargetDefines for RISCVTargetInfo Summary: This patch extend getTargetDefines and implement handleTargetFeatures and hasFeature. and define corresponding marco for those features. Reviewers: asb, apazos, eli.friedman Differential Revision: https://reviews.llvm.org/D44727 Patch by Kito Cheng. llvm-svn: 329278
2018-04-05 12:54:00 +00:00
Builder.defineMacro("__riscv_mul");
[RISCV][Clang] Add support for Zmmul extension This patch implements recently ratified extension Zmmul, a subextension of M (Integer Multiplication and Division) consisting only multiplication part of it. Differential Revision: https://reviews.llvm.org/D103313 Reviewed By: craig.topper, jrtc27, asb
2022-06-25 21:36:02 -04:00
if (ISAInfo->hasExtension("m")) {
[PATCH] [RISCV] Extend getTargetDefines for RISCVTargetInfo Summary: This patch extend getTargetDefines and implement handleTargetFeatures and hasFeature. and define corresponding marco for those features. Reviewers: asb, apazos, eli.friedman Differential Revision: https://reviews.llvm.org/D44727 Patch by Kito Cheng. llvm-svn: 329278
2018-04-05 12:54:00 +00:00
Builder.defineMacro("__riscv_div");
Builder.defineMacro("__riscv_muldiv");
}
[RISCV] Unify the arch string parsing logic to to RISCVISAInfo. How many place you need to modify when implementing a new extension for RISC-V? At least 7 places as I know: - Add new SubtargetFeature at RISCV.td - -march parser in RISCV.cpp - RISCVTargetInfo::initFeatureMap@RISCV.cpp for handling feature vector. - RISCVTargetInfo::getTargetDefines@RISCV.cpp for pre-define marco. - Arch string parser for ELF attribute in RISCVAsmParser.cpp - ELF attribute emittion in RISCVAsmParser.cpp, and make sure it's in canonical order... - ELF attribute emittion in RISCVTargetStreamer.cpp, and again, must in canonical order... And now, this patch provide an unified infrastructure for handling (almost) everything of RISC-V arch string. After this patch, you only need to update 2 places for implement an extension for RISC-V: - Add new SubtargetFeature at RISCV.td, hmmm, it's hard to avoid. - Add new entry to RISCVSupportedExtension@RISCVISAInfo.cpp or SupportedExperimentalExtensions@RISCVISAInfo.cpp . Most codes are come from existing -march parser, but with few new feature/bug fixes: - Accept version for -march, e.g. -march=rv32i2p0. - Reject version info with `p` but without minor version number like `rv32i2p`. Differential Revision: https://reviews.llvm.org/D105168
2021-06-23 16:18:54 +08:00
if (ISAInfo->hasExtension("a")) {
[PATCH] [RISCV] Extend getTargetDefines for RISCVTargetInfo Summary: This patch extend getTargetDefines and implement handleTargetFeatures and hasFeature. and define corresponding marco for those features. Reviewers: asb, apazos, eli.friedman Differential Revision: https://reviews.llvm.org/D44727 Patch by Kito Cheng. llvm-svn: 329278
2018-04-05 12:54:00 +00:00
Builder.defineMacro("__riscv_atomic");
[RISCV] Set __GCC_HAVE_SYNC_COMPARE_AND_SWAP_x defines The RISCV target did not set the GCC atomic compare and swap defines, unlike other targets. This broke builds for things like glib on RISCV. Patch by Kristof Provost (kprovost) Differential Revision: https://reviews.llvm.org/D91784
2020-11-24 22:46:38 +00:00
Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1");
Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2");
Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4");
if (Is64Bit)
Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8");
}
[PATCH] [RISCV] Extend getTargetDefines for RISCVTargetInfo Summary: This patch extend getTargetDefines and implement handleTargetFeatures and hasFeature. and define corresponding marco for those features. Reviewers: asb, apazos, eli.friedman Differential Revision: https://reviews.llvm.org/D44727 Patch by Kito Cheng. llvm-svn: 329278
2018-04-05 12:54:00 +00:00
[RISCV] Unify the arch string parsing logic to to RISCVISAInfo. How many place you need to modify when implementing a new extension for RISC-V? At least 7 places as I know: - Add new SubtargetFeature at RISCV.td - -march parser in RISCV.cpp - RISCVTargetInfo::initFeatureMap@RISCV.cpp for handling feature vector. - RISCVTargetInfo::getTargetDefines@RISCV.cpp for pre-define marco. - Arch string parser for ELF attribute in RISCVAsmParser.cpp - ELF attribute emittion in RISCVAsmParser.cpp, and make sure it's in canonical order... - ELF attribute emittion in RISCVTargetStreamer.cpp, and again, must in canonical order... And now, this patch provide an unified infrastructure for handling (almost) everything of RISC-V arch string. After this patch, you only need to update 2 places for implement an extension for RISC-V: - Add new SubtargetFeature at RISCV.td, hmmm, it's hard to avoid. - Add new entry to RISCVSupportedExtension@RISCVISAInfo.cpp or SupportedExperimentalExtensions@RISCVISAInfo.cpp . Most codes are come from existing -march parser, but with few new feature/bug fixes: - Accept version for -march, e.g. -march=rv32i2p0. - Reject version info with `p` but without minor version number like `rv32i2p`. Differential Revision: https://reviews.llvm.org/D105168
2021-06-23 16:18:54 +08:00
if (FLen) {
Builder.defineMacro("__riscv_flen", Twine(FLen));
[PATCH] [RISCV] Extend getTargetDefines for RISCVTargetInfo Summary: This patch extend getTargetDefines and implement handleTargetFeatures and hasFeature. and define corresponding marco for those features. Reviewers: asb, apazos, eli.friedman Differential Revision: https://reviews.llvm.org/D44727 Patch by Kito Cheng. llvm-svn: 329278
2018-04-05 12:54:00 +00:00
Builder.defineMacro("__riscv_fdiv");
Builder.defineMacro("__riscv_fsqrt");
}
[RISCV] Add the zve extension according to the v1.0 spec `zve` is the new standard vector extension to specify varying degrees of vector support for embedding processors. The `zve` extension is related to the `zvl` extension and other updates that are added in v1.0. According to https://github.com/riscv-non-isa/riscv-c-api-doc/pull/21, Clang defines macro `__riscv_v_max_elen`, `__riscv_v_max_elen_fp` for `zve` and it can be used by applications that uses the vector extension. Authored by: Zakk Chen <zakk.chen@sifive.com> @khchen Co-Authored by: Eop Chen <eop.chen@sifive.com> @eopXD Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D112408
2021-10-27 05:52:20 -07:00
if (MinVLen) {
[RISCV] Add the zvl extension according to the v1.0 spec `zvl` is the new standard vector extension that specifies the minimum vector length of the vector extension. The `zvl` extension is related to the `zve` extension and other updates that are added in v1.0. According to https://github.com/riscv-non-isa/riscv-c-api-doc/pull/21, Clang defines macro `__riscv_v_min_vlen` for `zvl` and it can be used for applications that uses the vector extension. LLVM checks whether the option `riscv-v-vector-bits-min` (if specified) matches the `zvl*` extension specified. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D108694
2021-10-23 03:18:24 -07:00
Builder.defineMacro("__riscv_v_min_vlen", Twine(MinVLen));
[RISCV] Add the zve extension according to the v1.0 spec `zve` is the new standard vector extension to specify varying degrees of vector support for embedding processors. The `zve` extension is related to the `zvl` extension and other updates that are added in v1.0. According to https://github.com/riscv-non-isa/riscv-c-api-doc/pull/21, Clang defines macro `__riscv_v_max_elen`, `__riscv_v_max_elen_fp` for `zve` and it can be used by applications that uses the vector extension. Authored by: Zakk Chen <zakk.chen@sifive.com> @khchen Co-Authored by: Eop Chen <eop.chen@sifive.com> @eopXD Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D112408
2021-10-27 05:52:20 -07:00
Builder.defineMacro("__riscv_v_elen", Twine(MaxELen));
Builder.defineMacro("__riscv_v_elen_fp", Twine(MaxELenFp));
}
[RISCV] Add the zvl extension according to the v1.0 spec `zvl` is the new standard vector extension that specifies the minimum vector length of the vector extension. The `zvl` extension is related to the `zve` extension and other updates that are added in v1.0. According to https://github.com/riscv-non-isa/riscv-c-api-doc/pull/21, Clang defines macro `__riscv_v_min_vlen` for `zvl` and it can be used for applications that uses the vector extension. LLVM checks whether the option `riscv-v-vector-bits-min` (if specified) matches the `zvl*` extension specified. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D108694
2021-10-23 03:18:24 -07:00
[RISCV] Unify the arch string parsing logic to to RISCVISAInfo. How many place you need to modify when implementing a new extension for RISC-V? At least 7 places as I know: - Add new SubtargetFeature at RISCV.td - -march parser in RISCV.cpp - RISCVTargetInfo::initFeatureMap@RISCV.cpp for handling feature vector. - RISCVTargetInfo::getTargetDefines@RISCV.cpp for pre-define marco. - Arch string parser for ELF attribute in RISCVAsmParser.cpp - ELF attribute emittion in RISCVAsmParser.cpp, and make sure it's in canonical order... - ELF attribute emittion in RISCVTargetStreamer.cpp, and again, must in canonical order... And now, this patch provide an unified infrastructure for handling (almost) everything of RISC-V arch string. After this patch, you only need to update 2 places for implement an extension for RISC-V: - Add new SubtargetFeature at RISCV.td, hmmm, it's hard to avoid. - Add new entry to RISCVSupportedExtension@RISCVISAInfo.cpp or SupportedExperimentalExtensions@RISCVISAInfo.cpp . Most codes are come from existing -march parser, but with few new feature/bug fixes: - Accept version for -march, e.g. -march=rv32i2p0. - Reject version info with `p` but without minor version number like `rv32i2p`. Differential Revision: https://reviews.llvm.org/D105168
2021-06-23 16:18:54 +08:00
if (ISAInfo->hasExtension("c"))
[PATCH] [RISCV] Extend getTargetDefines for RISCVTargetInfo Summary: This patch extend getTargetDefines and implement handleTargetFeatures and hasFeature. and define corresponding marco for those features. Reviewers: asb, apazos, eli.friedman Differential Revision: https://reviews.llvm.org/D44727 Patch by Kito Cheng. llvm-svn: 329278
2018-04-05 12:54:00 +00:00
Builder.defineMacro("__riscv_compressed");
[RISCV] Add Clang frontend support for Bitmanip extension This adds the __riscv_bitmanip macro and the 'b' target feature to enable it. Differential Revision: https://reviews.llvm.org/D71553
2020-04-09 17:51:26 +01:00
[clang][RISCV] __riscv_v_intrinsic macro doesn't need zve32x (#117356) This macro is used to check if compiler supports RVV intrinsics, so it should be defined no matter vector is enabled or not. Resolved https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/376
2024-11-27 10:35:38 +08:00
if (ISAInfo->hasExtension("zve32x"))
[RISCV] Define preprocessor definitions for 'V' extension. Differential Revision: https://reviews.llvm.org/D92650
2020-12-04 20:45:41 +08:00
Builder.defineMacro("__riscv_vector");
[clang][RISCV] __riscv_v_intrinsic macro doesn't need zve32x (#117356) This macro is used to check if compiler supports RVV intrinsics, so it should be defined no matter vector is enabled or not. Resolved https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/376
2024-11-27 10:35:38 +08:00
// Currently we support the v1.0 RISC-V V intrinsics.
Builder.defineMacro("__riscv_v_intrinsic", Twine(getVersionValue(1, 0)));
[RISCV] Add attribute(riscv_rvv_vector_bits(N)) based on AArch64 arm_sve_vector_bits. This allows the user to set the size of the scalable vector so they can be used in structs and as the type of global variables. This works by representing the type as a fixed vector instead of a scalable vector in IR. Conversions to and from scalable vectors are made where necessary like function arguments/returns and intrinsics. This features has been requested here https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/176 I know arm_sve_vector_bits is used by the Eigen library so this could be used to port Eigen to RVV. This patch adds a new preprocessor define `__riscv_v_fixed_vlen` that is set when -mrvv_vector_bits is passed on the command line. The code is largely based on the AArch64 code. A lot of code was copy/pasted and then modiied to RVV. There may be some opportunities for sharing. This first patch only supports the LMUL=1 types. Additional changes will be needed to support other LMULs. I have also not supported mask vectors. Differential Revision: https://reviews.llvm.org/D145088
2023-04-28 15:41:17 -07:00
[AArch64] Enable vscale_range with +sme (#124466) If we have +sme but not +sve, we would not set vscale_range on functions. It should be valid to apply it with the same range with just +sme, which can help mitigate some performance regressions in cases such as scalable vector bitcasts (https://godbolt.org/z/exhe4jd8d).
2025-01-31 07:57:43 +00:00
auto VScale = getVScaleRange(Opts, false);
[RISCV] Add attribute(riscv_rvv_vector_bits(N)) based on AArch64 arm_sve_vector_bits. This allows the user to set the size of the scalable vector so they can be used in structs and as the type of global variables. This works by representing the type as a fixed vector instead of a scalable vector in IR. Conversions to and from scalable vectors are made where necessary like function arguments/returns and intrinsics. This features has been requested here https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/176 I know arm_sve_vector_bits is used by the Eigen library so this could be used to port Eigen to RVV. This patch adds a new preprocessor define `__riscv_v_fixed_vlen` that is set when -mrvv_vector_bits is passed on the command line. The code is largely based on the AArch64 code. A lot of code was copy/pasted and then modiied to RVV. There may be some opportunities for sharing. This first patch only supports the LMUL=1 types. Additional changes will be needed to support other LMULs. I have also not supported mask vectors. Differential Revision: https://reviews.llvm.org/D145088
2023-04-28 15:41:17 -07:00
if (VScale && VScale->first && VScale->first == VScale->second)
Builder.defineMacro("__riscv_v_fixed_vlen",
Twine(VScale->first * llvm::RISCV::RVVBitsPerBlock));
[RISCV] Support predefined macro __riscv_misaligned_[fast,avoid]. (#65756) RISC-V C API introduced predefined macro to achieve hints about unaligned accesses ([pr]). This patch defines __riscv_misaligned_fast when using -mno-strict-align, otherwise, defines __riscv_misaligned_avoid. Note: This ignores __riscv_misaligned_slow which is also defined by spec. [pr]: https://github.com/riscv-non-isa/riscv-c-api-doc/pull/40
2023-10-26 15:10:57 +08:00
[RISCV] Add -m[no-]scalar-strict-align and -m[no-]vector-strict-align. (#95024)
2024-07-14 13:39:17 -07:00
if (FastScalarUnalignedAccess)
[RISCV] Support predefined macro __riscv_misaligned_[fast,avoid]. (#65756) RISC-V C API introduced predefined macro to achieve hints about unaligned accesses ([pr]). This patch defines __riscv_misaligned_fast when using -mno-strict-align, otherwise, defines __riscv_misaligned_avoid. Note: This ignores __riscv_misaligned_slow which is also defined by spec. [pr]: https://github.com/riscv-non-isa/riscv-c-api-doc/pull/40
2023-10-26 15:10:57 +08:00
Builder.defineMacro("__riscv_misaligned_fast");
else
Builder.defineMacro("__riscv_misaligned_avoid");
[RISCV] CodeGen of RVE and ilp32e/lp64e ABIs (#76777) This commit includes the necessary changes to clang and LLVM to support codegen of `RVE` and the `ilp32e`/`lp64e` ABIs. The differences between `RVE` and `RVI` are: * `RVE` reduces the integer register count to 16(x0-x16). * The ABI should be `ilp32e` for 32 bits and `lp64e` for 64 bits. `RVE` can be combined with all current standard extensions. The central changes in ilp32e/lp64e ABI, compared to ilp32/lp64 are: * Only 6 integer argument registers (rather than 8). * Only 2 callee-saved registers (rather than 12). * A Stack Alignment of 32bits (rather than 128bits). * ilp32e isn't compatible with D ISA extension. If `ilp32e` or `lp64` is used with an ISA that has any of the registers x16-x31 and f0-f31, then these registers are considered temporaries. To be compatible with the implementation of ilp32e in GCC, we don't use aligned registers to pass variadic arguments and set stack alignment\ to 4-bytes for types with length of 2*XLEN. FastCC is also supported on RVE, while GHC isn't since there is only one avaiable register. Differential Revision: https://reviews.llvm.org/D70401
2024-01-16 20:44:30 +08:00
if (ISAInfo->hasExtension("e")) {
if (Is64Bit)
Builder.defineMacro("__riscv_64e");
else
Builder.defineMacro("__riscv_32e");
}
[clang][RISCV] Introduce preprocessor macro when Zicfiss-based shadow stack is enabled (#127592) The `-fcf-protection=[full|return]` flag enables shadow stack implementation based on RISC-V Zicfiss extension. This patch adds the `__riscv_shadow_stack` predefined macro to preprocessing when such a shadow stack implementation is enabled.
2025-02-18 17:27:20 +08:00
if (Opts.CFProtectionReturn && ISAInfo->hasExtension("zicfiss"))
Builder.defineMacro("__riscv_shadow_stack");
[PATCH] [RISCV] Extend getTargetDefines for RISCVTargetInfo Summary: This patch extend getTargetDefines and implement handleTargetFeatures and hasFeature. and define corresponding marco for those features. Reviewers: asb, apazos, eli.friedman Differential Revision: https://reviews.llvm.org/D44727 Patch by Kito Cheng. llvm-svn: 329278
2018-04-05 12:54:00 +00:00
}
[StrTable] Switch Clang builtins to use string tables This both reapplies #118734, the initial attempt at this, and updates it significantly. First, it uses the newly added `StringTable` abstraction for string tables, and simplifies the construction to build the string table and info arrays separately. This should reduce any `constexpr` compile time memory or CPU cost of the original PR while significantly improving the APIs throughout. It also restructures the builtins to support sharding across several independent tables. This accomplishes two improvements from the original PR: 1) It improves the APIs used significantly. 2) When builtins are defined from different sources (like SVE vs MVE in AArch64), this allows each of them to build their own string table independently rather than having to merge the string tables and info structures. 3) It allows each shard to factor out a common prefix, often cutting the size of the strings needed for the builtins by a factor two. The second point is important both to allow different mechanisms of construction (for example a `.def` file and a tablegen'ed `.inc` file, or different tablegen'ed `.inc files), it also simply reduces the sizes of these tables which is valuable given how large they are in some cases. The third builds on that size reduction. Initially, we use this new sharding rather than merging tables in AArch64, LoongArch, RISCV, and X86. Mostly this helps ensure the system works, as without further changes these still push scaling limits. Subsequent commits will more deeply leverage the new structure, including using the prefix capabilities which cannot be easily factored out here and requires deep changes to the targets.
2024-12-14 09:09:47 +00:00
static constexpr int NumRVVBuiltins =
[StrTable] Switch RISCV to leverage sharded, prefixed builtins w/ TableGen This lets the TableGen-ed code be much cleaner, directly building an efficient string table without duplicates and without the repeated prefix.
2024-12-15 03:20:15 +00:00
RISCVVector::FirstSiFiveBuiltin - Builtin::FirstTSBuiltin;
static constexpr int NumRVVSiFiveBuiltins =
RISCVVector::FirstTSBuiltin - RISCVVector::FirstSiFiveBuiltin;
[StrTable] Switch Clang builtins to use string tables This both reapplies #118734, the initial attempt at this, and updates it significantly. First, it uses the newly added `StringTable` abstraction for string tables, and simplifies the construction to build the string table and info arrays separately. This should reduce any `constexpr` compile time memory or CPU cost of the original PR while significantly improving the APIs throughout. It also restructures the builtins to support sharding across several independent tables. This accomplishes two improvements from the original PR: 1) It improves the APIs used significantly. 2) When builtins are defined from different sources (like SVE vs MVE in AArch64), this allows each of them to build their own string table independently rather than having to merge the string tables and info structures. 3) It allows each shard to factor out a common prefix, often cutting the size of the strings needed for the builtins by a factor two. The second point is important both to allow different mechanisms of construction (for example a `.def` file and a tablegen'ed `.inc` file, or different tablegen'ed `.inc files), it also simply reduces the sizes of these tables which is valuable given how large they are in some cases. The third builds on that size reduction. Initially, we use this new sharding rather than merging tables in AArch64, LoongArch, RISCV, and X86. Mostly this helps ensure the system works, as without further changes these still push scaling limits. Subsequent commits will more deeply leverage the new structure, including using the prefix capabilities which cannot be easily factored out here and requires deep changes to the targets.
2024-12-14 09:09:47 +00:00
static constexpr int NumRISCVBuiltins =
[StrTable] Switch RISCV to leverage sharded, prefixed builtins w/ TableGen This lets the TableGen-ed code be much cleaner, directly building an efficient string table without duplicates and without the repeated prefix.
2024-12-15 03:20:15 +00:00
RISCV::LastTSBuiltin - RISCVVector::FirstTSBuiltin;
[StrTable] Switch Clang builtins to use string tables This both reapplies #118734, the initial attempt at this, and updates it significantly. First, it uses the newly added `StringTable` abstraction for string tables, and simplifies the construction to build the string table and info arrays separately. This should reduce any `constexpr` compile time memory or CPU cost of the original PR while significantly improving the APIs throughout. It also restructures the builtins to support sharding across several independent tables. This accomplishes two improvements from the original PR: 1) It improves the APIs used significantly. 2) When builtins are defined from different sources (like SVE vs MVE in AArch64), this allows each of them to build their own string table independently rather than having to merge the string tables and info structures. 3) It allows each shard to factor out a common prefix, often cutting the size of the strings needed for the builtins by a factor two. The second point is important both to allow different mechanisms of construction (for example a `.def` file and a tablegen'ed `.inc` file, or different tablegen'ed `.inc files), it also simply reduces the sizes of these tables which is valuable given how large they are in some cases. The third builds on that size reduction. Initially, we use this new sharding rather than merging tables in AArch64, LoongArch, RISCV, and X86. Mostly this helps ensure the system works, as without further changes these still push scaling limits. Subsequent commits will more deeply leverage the new structure, including using the prefix capabilities which cannot be easily factored out here and requires deep changes to the targets.
2024-12-14 09:09:47 +00:00
static constexpr int NumBuiltins =
[StrTable] Switch RISCV to leverage sharded, prefixed builtins w/ TableGen This lets the TableGen-ed code be much cleaner, directly building an efficient string table without duplicates and without the repeated prefix.
2024-12-15 03:20:15 +00:00
RISCV::LastTSBuiltin - Builtin::FirstTSBuiltin;
static_assert(NumBuiltins ==
(NumRVVBuiltins + NumRVVSiFiveBuiltins + NumRISCVBuiltins));
namespace RVV {
#define GET_RISCVV_BUILTIN_STR_TABLE
#include "clang/Basic/riscv_vector_builtins.inc"
#undef GET_RISCVV_BUILTIN_STR_TABLE
static_assert(BuiltinStrings.size() < 100'000);
static constexpr std::array<Builtin::Info, NumRVVBuiltins> BuiltinInfos = {
#define GET_RISCVV_BUILTIN_INFOS
#include "clang/Basic/riscv_vector_builtins.inc"
#undef GET_RISCVV_BUILTIN_INFOS
};
} // namespace RVV
namespace RVVSiFive {
#define GET_RISCVV_BUILTIN_STR_TABLE
#include "clang/Basic/riscv_sifive_vector_builtins.inc"
#undef GET_RISCVV_BUILTIN_STR_TABLE
static constexpr std::array<Builtin::Info, NumRVVSiFiveBuiltins> BuiltinInfos =
{
#define GET_RISCVV_BUILTIN_INFOS
#include "clang/Basic/riscv_sifive_vector_builtins.inc"
#undef GET_RISCVV_BUILTIN_INFOS
};
} // namespace RVVSiFive
[StrTable] Teach main builtin TableGen to use direct enums, strings, and info This moves the main builtins and several targets to use nice generated string tables and info structures rather than X-macros. Even without obvious prefixes factored out, the resulting tables are significantly smaller and much cheaper to compile with out all the X-macro overhead. This leaves the X-macros in place for atomic builtins which have a wide range of uses that don't seem reasonable to fold into TableGen. As future work, these should move to their own file (whether as X-macros or just generated patterns) so the AST headers don't have to include all the data for other builtins.
2024-12-17 19:21:27 +00:00
#define GET_BUILTIN_STR_TABLE
[Clang][RISCV] Refactor builtins to TableGen This mechanism is introduced by #68324. This refactor makes the prototype and attributes clear. Reviewers: asb, kito-cheng, philnik777, topperc, preames Reviewed By: topperc Pull Request: https://github.com/llvm/llvm-project/pull/80280
2024-02-09 20:27:17 +08:00
#include "clang/Basic/BuiltinsRISCV.inc"
[StrTable] Teach main builtin TableGen to use direct enums, strings, and info This moves the main builtins and several targets to use nice generated string tables and info structures rather than X-macros. Even without obvious prefixes factored out, the resulting tables are significantly smaller and much cheaper to compile with out all the X-macro overhead. This leaves the X-macros in place for atomic builtins which have a wide range of uses that don't seem reasonable to fold into TableGen. As future work, these should move to their own file (whether as X-macros or just generated patterns) so the AST headers don't have to include all the data for other builtins.
2024-12-17 19:21:27 +00:00
#undef GET_BUILTIN_STR_TABLE
[RISCV] Add vadd with mask and without mask builtin. Demonstrate how to add RISC-V V builtins and lower them to IR intrinsics for V extension. Authored-by: Roger Ferrer Ibanez <rofirrim@gmail.com> Co-Authored-by: Hsiangkai Wang <kai.wang@sifive.com> Differential Revision: https://reviews.llvm.org/D93446
2021-02-04 12:57:44 +08:00
[StrTable] Teach main builtin TableGen to use direct enums, strings, and info This moves the main builtins and several targets to use nice generated string tables and info structures rather than X-macros. Even without obvious prefixes factored out, the resulting tables are significantly smaller and much cheaper to compile with out all the X-macro overhead. This leaves the X-macros in place for atomic builtins which have a wide range of uses that don't seem reasonable to fold into TableGen. As future work, these should move to their own file (whether as X-macros or just generated patterns) so the AST headers don't have to include all the data for other builtins.
2024-12-17 19:21:27 +00:00
static constexpr Builtin::Info BuiltinInfos[] = {
#define GET_BUILTIN_INFOS
[StrTable] Switch Clang builtins to use string tables This both reapplies #118734, the initial attempt at this, and updates it significantly. First, it uses the newly added `StringTable` abstraction for string tables, and simplifies the construction to build the string table and info arrays separately. This should reduce any `constexpr` compile time memory or CPU cost of the original PR while significantly improving the APIs throughout. It also restructures the builtins to support sharding across several independent tables. This accomplishes two improvements from the original PR: 1) It improves the APIs used significantly. 2) When builtins are defined from different sources (like SVE vs MVE in AArch64), this allows each of them to build their own string table independently rather than having to merge the string tables and info structures. 3) It allows each shard to factor out a common prefix, often cutting the size of the strings needed for the builtins by a factor two. The second point is important both to allow different mechanisms of construction (for example a `.def` file and a tablegen'ed `.inc` file, or different tablegen'ed `.inc files), it also simply reduces the sizes of these tables which is valuable given how large they are in some cases. The third builds on that size reduction. Initially, we use this new sharding rather than merging tables in AArch64, LoongArch, RISCV, and X86. Mostly this helps ensure the system works, as without further changes these still push scaling limits. Subsequent commits will more deeply leverage the new structure, including using the prefix capabilities which cannot be easily factored out here and requires deep changes to the targets.
2024-12-14 09:09:47 +00:00
#include "clang/Basic/BuiltinsRISCV.inc"
[StrTable] Teach main builtin TableGen to use direct enums, strings, and info This moves the main builtins and several targets to use nice generated string tables and info structures rather than X-macros. Even without obvious prefixes factored out, the resulting tables are significantly smaller and much cheaper to compile with out all the X-macro overhead. This leaves the X-macros in place for atomic builtins which have a wide range of uses that don't seem reasonable to fold into TableGen. As future work, these should move to their own file (whether as X-macros or just generated patterns) so the AST headers don't have to include all the data for other builtins.
2024-12-17 19:21:27 +00:00
#undef GET_BUILTIN_INFOS
};
static_assert(std::size(BuiltinInfos) == NumRISCVBuiltins);
[StrTable] Switch Clang builtins to use string tables This both reapplies #118734, the initial attempt at this, and updates it significantly. First, it uses the newly added `StringTable` abstraction for string tables, and simplifies the construction to build the string table and info arrays separately. This should reduce any `constexpr` compile time memory or CPU cost of the original PR while significantly improving the APIs throughout. It also restructures the builtins to support sharding across several independent tables. This accomplishes two improvements from the original PR: 1) It improves the APIs used significantly. 2) When builtins are defined from different sources (like SVE vs MVE in AArch64), this allows each of them to build their own string table independently rather than having to merge the string tables and info structures. 3) It allows each shard to factor out a common prefix, often cutting the size of the strings needed for the builtins by a factor two. The second point is important both to allow different mechanisms of construction (for example a `.def` file and a tablegen'ed `.inc` file, or different tablegen'ed `.inc files), it also simply reduces the sizes of these tables which is valuable given how large they are in some cases. The third builds on that size reduction. Initially, we use this new sharding rather than merging tables in AArch64, LoongArch, RISCV, and X86. Mostly this helps ensure the system works, as without further changes these still push scaling limits. Subsequent commits will more deeply leverage the new structure, including using the prefix capabilities which cannot be easily factored out here and requires deep changes to the targets.
2024-12-14 09:09:47 +00:00
llvm::SmallVector<Builtin::InfosShard>
RISCVTargetInfo::getTargetBuiltins() const {
return {
[StrTable] Switch RISCV to leverage sharded, prefixed builtins w/ TableGen This lets the TableGen-ed code be much cleaner, directly building an efficient string table without duplicates and without the repeated prefix.
2024-12-15 03:20:15 +00:00
{&RVV::BuiltinStrings, RVV::BuiltinInfos, "__builtin_rvv_"},
{&RVVSiFive::BuiltinStrings, RVVSiFive::BuiltinInfos, "__builtin_rvv_"},
{&BuiltinStrings, BuiltinInfos},
[StrTable] Switch Clang builtins to use string tables This both reapplies #118734, the initial attempt at this, and updates it significantly. First, it uses the newly added `StringTable` abstraction for string tables, and simplifies the construction to build the string table and info arrays separately. This should reduce any `constexpr` compile time memory or CPU cost of the original PR while significantly improving the APIs throughout. It also restructures the builtins to support sharding across several independent tables. This accomplishes two improvements from the original PR: 1) It improves the APIs used significantly. 2) When builtins are defined from different sources (like SVE vs MVE in AArch64), this allows each of them to build their own string table independently rather than having to merge the string tables and info structures. 3) It allows each shard to factor out a common prefix, often cutting the size of the strings needed for the builtins by a factor two. The second point is important both to allow different mechanisms of construction (for example a `.def` file and a tablegen'ed `.inc` file, or different tablegen'ed `.inc files), it also simply reduces the sizes of these tables which is valuable given how large they are in some cases. The third builds on that size reduction. Initially, we use this new sharding rather than merging tables in AArch64, LoongArch, RISCV, and X86. Mostly this helps ensure the system works, as without further changes these still push scaling limits. Subsequent commits will more deeply leverage the new structure, including using the prefix capabilities which cannot be easily factored out here and requires deep changes to the targets.
2024-12-14 09:09:47 +00:00
};
[RISCV] Add vadd with mask and without mask builtin. Demonstrate how to add RISC-V V builtins and lower them to IR intrinsics for V extension. Authored-by: Roger Ferrer Ibanez <rofirrim@gmail.com> Co-Authored-by: Hsiangkai Wang <kai.wang@sifive.com> Differential Revision: https://reviews.llvm.org/D93446
2021-02-04 12:57:44 +08:00
}
[RISCV] Prevent __builtin_riscv_orc_b_64 from being compiled RV32 target. The backend can't handle this and will throw a fatal error from type legalization. It's easy enough to fix that for this intrinsic by just splitting the IR intrinsic since it works on individual bytes. There will be other intrinsics in the future that would be harder to support through splitting, for example grev, gorc, and shfl. Those would require a compare and a select be inserted to check the MSB of their control input. This patch adds support for preventing this in the frontend with a nice diagnostic. Reviewed By: frasercrmck Differential Revision: https://reviews.llvm.org/D99984
2021-04-08 09:12:57 -07:00
bool RISCVTargetInfo::initFeatureMap(
llvm::StringMap<bool> &Features, DiagnosticsEngine &Diags, StringRef CPU,
const std::vector<std::string> &FeaturesVec) const {
[RISCV] Imply extensions in RISCVTargetInfo::initFeatureMap Under ASTContext, clang only copies the features from the options with Target->initFeatureMap, and no implications is done there. This makes clang_cc1 fail to imply into `zve32x` for the vector extension, and test cases will have to add ` -target-feature +experimental-zve32x` in order to work. This patch fixes it. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D113336
2021-11-06 02:05:43 -07:00
unsigned XLen = 32;
[RISCV] Use Triple::isRISCV64(). NFC
2023-12-09 14:02:11 -08:00
if (getTriple().isRISCV64()) {
[RISCV] Prevent __builtin_riscv_orc_b_64 from being compiled RV32 target. The backend can't handle this and will throw a fatal error from type legalization. It's easy enough to fix that for this intrinsic by just splitting the IR intrinsic since it works on individual bytes. There will be other intrinsics in the future that would be harder to support through splitting, for example grev, gorc, and shfl. Those would require a compare and a select be inserted to check the MSB of their control input. This patch adds support for preventing this in the frontend with a nice diagnostic. Reviewed By: frasercrmck Differential Revision: https://reviews.llvm.org/D99984
2021-04-08 09:12:57 -07:00
Features["64bit"] = true;
[RISCV] Imply extensions in RISCVTargetInfo::initFeatureMap Under ASTContext, clang only copies the features from the options with Target->initFeatureMap, and no implications is done there. This makes clang_cc1 fail to imply into `zve32x` for the vector extension, and test cases will have to add ` -target-feature +experimental-zve32x` in order to work. This patch fixes it. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D113336
2021-11-06 02:05:43 -07:00
XLen = 64;
[RISCV] Add '32bit' feature to rv32 only builtins. The backend now has a 32bit feature as part of the recent mtune patch. We can now use that make our rv32-only builtin error checking work the same way as rv64-only errors. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D132192
2022-09-06 14:45:17 -07:00
} else {
Features["32bit"] = true;
[RISCV] Imply extensions in RISCVTargetInfo::initFeatureMap Under ASTContext, clang only copies the features from the options with Target->initFeatureMap, and no implications is done there. This makes clang_cc1 fail to imply into `zve32x` for the vector extension, and test cases will have to add ` -target-feature +experimental-zve32x` in order to work. This patch fixes it. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D113336
2021-11-06 02:05:43 -07:00
}
[RISCV] Overwrite cpu target features for full arch string in target attribute (#77426) This patch reworks RISCVTargetInfo::initFeatureMap to fix the issue described in https://github.com/llvm/llvm-project/pull/74889#pullrequestreview-1773445559 (and is an alternative to #75804) When a full arch string is specified, a "full" list of extensions is now passed after the __RISCV_TargetAttrNeedOverride marker feature, which includes any negative features that disable ISA extensions. In initFeatureMap, there are now two code paths: 1. If the arch string was overriden, use the "full" list of override features, only adding back any non-isa features that were specified. Using the full list of positive and negative features will mean that the target-cpu will have no effect on the final arch, e.g. __attribute__((target("arch=rv64i"))) with -mcpu=sifive-x280 will have the features for rv64i, not a mix of both. 2. Otherwise, parse and *append* the list of implied features. By appending, we turn back on any features that might have been disabled by a negative extension, i.e. this handles the case fixed in #74889.
2024-01-17 13:32:03 +07:00
std::vector<std::string> AllFeatures = FeaturesVec;
auto ParseResult = llvm::RISCVISAInfo::parseFeatures(XLen, FeaturesVec);
[RISCV] Imply extensions in RISCVTargetInfo::initFeatureMap Under ASTContext, clang only copies the features from the options with Target->initFeatureMap, and no implications is done there. This makes clang_cc1 fail to imply into `zve32x` for the vector extension, and test cases will have to add ` -target-feature +experimental-zve32x` in order to work. This patch fixes it. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D113336
2021-11-06 02:05:43 -07:00
if (!ParseResult) {
std::string Buffer;
llvm::raw_string_ostream OutputErrMsg(Buffer);
handleAllErrors(ParseResult.takeError(), [&](llvm::StringError &ErrMsg) {
OutputErrMsg << ErrMsg.getMessage();
});
Diags.Report(diag::err_invalid_feature_combination) << OutputErrMsg.str();
return false;
}
[RISCV] Prevent __builtin_riscv_orc_b_64 from being compiled RV32 target. The backend can't handle this and will throw a fatal error from type legalization. It's easy enough to fix that for this intrinsic by just splitting the IR intrinsic since it works on individual bytes. There will be other intrinsics in the future that would be harder to support through splitting, for example grev, gorc, and shfl. Those would require a compare and a select be inserted to check the MSB of their control input. This patch adds support for preventing this in the frontend with a nice diagnostic. Reviewed By: frasercrmck Differential Revision: https://reviews.llvm.org/D99984
2021-04-08 09:12:57 -07:00
[RISCV] Overwrite cpu target features for full arch string in target attribute (#77426) This patch reworks RISCVTargetInfo::initFeatureMap to fix the issue described in https://github.com/llvm/llvm-project/pull/74889#pullrequestreview-1773445559 (and is an alternative to #75804) When a full arch string is specified, a "full" list of extensions is now passed after the __RISCV_TargetAttrNeedOverride marker feature, which includes any negative features that disable ISA extensions. In initFeatureMap, there are now two code paths: 1. If the arch string was overriden, use the "full" list of override features, only adding back any non-isa features that were specified. Using the full list of positive and negative features will mean that the target-cpu will have no effect on the final arch, e.g. __attribute__((target("arch=rv64i"))) with -mcpu=sifive-x280 will have the features for rv64i, not a mix of both. 2. Otherwise, parse and *append* the list of implied features. By appending, we turn back on any features that might have been disabled by a negative extension, i.e. this handles the case fixed in #74889.
2024-01-17 13:32:03 +07:00
// Append all features, not just new ones, so we override any negatives.
llvm::append_range(AllFeatures, (*ParseResult)->toFeatures());
return TargetInfo::initFeatureMap(Features, Diags, CPU, AllFeatures);
[RISCV] Prevent __builtin_riscv_orc_b_64 from being compiled RV32 target. The backend can't handle this and will throw a fatal error from type legalization. It's easy enough to fix that for this intrinsic by just splitting the IR intrinsic since it works on individual bytes. There will be other intrinsics in the future that would be harder to support through splitting, for example grev, gorc, and shfl. Those would require a compare and a select be inserted to check the MSB of their control input. This patch adds support for preventing this in the frontend with a nice diagnostic. Reviewed By: frasercrmck Differential Revision: https://reviews.llvm.org/D99984
2021-04-08 09:12:57 -07:00
}
[clang] Use std::optional instead of llvm::Optional (NFC) This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to remove #include "llvm/ADT/Optional.h". This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2023-01-14 12:31:01 -08:00
std::optional<std::pair<unsigned, unsigned>>
[AArch64] Enable vscale_range with +sme (#124466) If we have +sme but not +sve, we would not set vscale_range on functions. It should be valid to apply it with the same range with just +sme, which can help mitigate some performance regressions in cases such as scalable vector bitcasts (https://godbolt.org/z/exhe4jd8d).
2025-01-31 07:57:43 +00:00
RISCVTargetInfo::getVScaleRange(const LangOptions &LangOpts,
bool IsArmStreamingFunction) const {
[RISCV] Use Zvl*b as a lower bound for VScaleRange. The backend has a fatal error in RISCVSubtarget::getMinRVVVectorSizeInBits if RVVVectorBitsMin is less than the Zvl length from -march. Now RVVVectorBitsMin is connected to VScaleRange in the backend, we can trip this fatal error. This patch adds the Zvl*b length as a lower bound to protect this. The test is updated to test vscale-min with Zvl64b instead of V. I'd like to do a proper diagnostic for this, but I don't think we can do that from this function. Since -mvscale-min is an internal cc1 option, I'm not sure it's a big deal. I'm planning to add a driver option -msve-vector-bits. I will probably implement a diagnostic for that. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D141459
2023-01-17 11:32:08 -08:00
// RISCV::RVVBitsPerBlock is 64.
unsigned VScaleMin = ISAInfo->getMinVLen() / llvm::RISCV::RVVBitsPerBlock;
if (LangOpts.VScaleMin || LangOpts.VScaleMax) {
// Treat Zvl*b as a lower bound on vscale.
VScaleMin = std::max(VScaleMin, LangOpts.VScaleMin);
unsigned VScaleMax = LangOpts.VScaleMax;
if (VScaleMax != 0 && VScaleMax < VScaleMin)
VScaleMax = VScaleMin;
return std::pair<unsigned, unsigned>(VScaleMin ? VScaleMin : 1, VScaleMax);
}
if (VScaleMin > 0) {
unsigned VScaleMax = ISAInfo->getMaxVLen() / llvm::RISCV::RVVBitsPerBlock;
return std::make_pair(VScaleMin, VScaleMax);
[clang][RISCV] Set vscale_range attribute based on VLEN Follow up on D135894, restructure code to work in terms of minimum and maximum VLEN coming from RISCVISAInfo.cpp. In the original review, I'd mentioned that MinVLEN was sometimes zero. This turns out to be a case of human error, combined with really bad (lack of) error reporting. This patch adds appropriate tests for various vector extension combinations to show the mechanism works, but doesn't try to provide exhaustive coverage of the extension interactions. Presumably, that is already covered in existing tests elsewhere. Differential Revision: https://reviews.llvm.org/D136106
2022-10-19 16:05:39 -07:00
}
[clang][RISCV] Set vscale_range attribute based on presence of "v" extension This follows the path that AArch64 SVE has taken. Doing this via a function attribute set in the frontend is basically a workaround for the fact that several analyzes which need the information (i.e. known bits, lvi, scev) can't easily use TTI without significant amounts of plumbing changes. This patch hard codes "v" numbers, and directly follows the SVE precedent as a result. In a follow up, I hope to drive this from RISCVISAInfo.h/cpp instead, but the MinVLen number being returned from that interface seemed to always be 0 (which is wrong), and I haven't figured out what's going wrong there. Differential Revision: https://reviews.llvm.org/D135894
2022-10-17 10:09:58 -07:00
[Basic] Use std::nullopt instead of None (NFC) This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-03 11:34:27 -08:00
return std::nullopt;
[clang][RISCV] Set vscale_range attribute based on presence of "v" extension This follows the path that AArch64 SVE has taken. Doing this via a function attribute set in the frontend is basically a workaround for the fact that several analyzes which need the information (i.e. known bits, lvi, scev) can't easily use TTI without significant amounts of plumbing changes. This patch hard codes "v" numbers, and directly follows the SVE precedent as a result. In a follow up, I hope to drive this from RISCVISAInfo.h/cpp instead, but the MinVLen number being returned from that interface seemed to always be 0 (which is wrong), and I haven't figured out what's going wrong there. Differential Revision: https://reviews.llvm.org/D135894
2022-10-17 10:09:58 -07:00
}
[PATCH] [RISCV] Extend getTargetDefines for RISCVTargetInfo Summary: This patch extend getTargetDefines and implement handleTargetFeatures and hasFeature. and define corresponding marco for those features. Reviewers: asb, apazos, eli.friedman Differential Revision: https://reviews.llvm.org/D44727 Patch by Kito Cheng. llvm-svn: 329278
2018-04-05 12:54:00 +00:00
/// Return true if has this feature, need to sync with handleTargetFeatures.
bool RISCVTargetInfo::hasFeature(StringRef Feature) const {
[RISCV] Use Triple::isRISCV64(). NFC
2023-12-09 14:02:11 -08:00
bool Is64Bit = getTriple().isRISCV64();
[Targets] Use std::optional in RISCV.cpp (NFC) This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-09 22:52:29 -08:00
auto Result = llvm::StringSwitch<std::optional<bool>>(Feature)
[RISCV] Unify the arch string parsing logic to to RISCVISAInfo. How many place you need to modify when implementing a new extension for RISC-V? At least 7 places as I know: - Add new SubtargetFeature at RISCV.td - -march parser in RISCV.cpp - RISCVTargetInfo::initFeatureMap@RISCV.cpp for handling feature vector. - RISCVTargetInfo::getTargetDefines@RISCV.cpp for pre-define marco. - Arch string parser for ELF attribute in RISCVAsmParser.cpp - ELF attribute emittion in RISCVAsmParser.cpp, and make sure it's in canonical order... - ELF attribute emittion in RISCVTargetStreamer.cpp, and again, must in canonical order... And now, this patch provide an unified infrastructure for handling (almost) everything of RISC-V arch string. After this patch, you only need to update 2 places for implement an extension for RISC-V: - Add new SubtargetFeature at RISCV.td, hmmm, it's hard to avoid. - Add new entry to RISCVSupportedExtension@RISCVISAInfo.cpp or SupportedExperimentalExtensions@RISCVISAInfo.cpp . Most codes are come from existing -march parser, but with few new feature/bug fixes: - Accept version for -march, e.g. -march=rv32i2p0. - Reject version info with `p` but without minor version number like `rv32i2p`. Differential Revision: https://reviews.llvm.org/D105168
2021-06-23 16:18:54 +08:00
.Case("riscv", true)
.Case("riscv32", !Is64Bit)
.Case("riscv64", Is64Bit)
[RISCV] Add '32bit' feature to rv32 only builtins. The backend now has a 32bit feature as part of the recent mtune patch. We can now use that make our rv32-only builtin error checking work the same way as rv64-only errors. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D132192
2022-09-06 14:45:17 -07:00
.Case("32bit", !Is64Bit)
[RISCV] Unify the arch string parsing logic to to RISCVISAInfo. How many place you need to modify when implementing a new extension for RISC-V? At least 7 places as I know: - Add new SubtargetFeature at RISCV.td - -march parser in RISCV.cpp - RISCVTargetInfo::initFeatureMap@RISCV.cpp for handling feature vector. - RISCVTargetInfo::getTargetDefines@RISCV.cpp for pre-define marco. - Arch string parser for ELF attribute in RISCVAsmParser.cpp - ELF attribute emittion in RISCVAsmParser.cpp, and make sure it's in canonical order... - ELF attribute emittion in RISCVTargetStreamer.cpp, and again, must in canonical order... And now, this patch provide an unified infrastructure for handling (almost) everything of RISC-V arch string. After this patch, you only need to update 2 places for implement an extension for RISC-V: - Add new SubtargetFeature at RISCV.td, hmmm, it's hard to avoid. - Add new entry to RISCVSupportedExtension@RISCVISAInfo.cpp or SupportedExperimentalExtensions@RISCVISAInfo.cpp . Most codes are come from existing -march parser, but with few new feature/bug fixes: - Accept version for -march, e.g. -march=rv32i2p0. - Reject version info with `p` but without minor version number like `rv32i2p`. Differential Revision: https://reviews.llvm.org/D105168
2021-06-23 16:18:54 +08:00
.Case("64bit", Is64Bit)
[RISCV] Remove experimental from Vector Crypto extensions (#74213) The RISC-V vector crypto extensions have been ratified. This patch updates the Clang and LLVM support for these extensions to be non-experimental, while leaving the C intrinsics as experimental since the C intrinsics are not yet standardized. Co-authored-by: Brandon Wu <brandon.wu@sifive.com>
2023-12-18 22:04:22 -08:00
.Case("experimental", HasExperimental)
[Basic] Use std::nullopt instead of None (NFC) This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-03 11:34:27 -08:00
.Default(std::nullopt);
[clang] Don't use Optional::hasValue (NFC) This patch replaces Optional::hasValue with the implicit cast to bool in conditionals only.
2022-06-25 22:26:24 -07:00
if (Result)
std::optional::value => operator*/operator-> value() has undesired exception checking semantics and calls __throw_bad_optional_access in libc++. Moreover, the API is unavailable without _LIBCPP_NO_EXCEPTIONS on older Mach-O platforms (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). This fixes clang.
2022-12-17 00:42:05 +00:00
return *Result;
[RISCV] Unify the arch string parsing logic to to RISCVISAInfo. How many place you need to modify when implementing a new extension for RISC-V? At least 7 places as I know: - Add new SubtargetFeature at RISCV.td - -march parser in RISCV.cpp - RISCVTargetInfo::initFeatureMap@RISCV.cpp for handling feature vector. - RISCVTargetInfo::getTargetDefines@RISCV.cpp for pre-define marco. - Arch string parser for ELF attribute in RISCVAsmParser.cpp - ELF attribute emittion in RISCVAsmParser.cpp, and make sure it's in canonical order... - ELF attribute emittion in RISCVTargetStreamer.cpp, and again, must in canonical order... And now, this patch provide an unified infrastructure for handling (almost) everything of RISC-V arch string. After this patch, you only need to update 2 places for implement an extension for RISC-V: - Add new SubtargetFeature at RISCV.td, hmmm, it's hard to avoid. - Add new entry to RISCVSupportedExtension@RISCVISAInfo.cpp or SupportedExperimentalExtensions@RISCVISAInfo.cpp . Most codes are come from existing -march parser, but with few new feature/bug fixes: - Accept version for -march, e.g. -march=rv32i2p0. - Reject version info with `p` but without minor version number like `rv32i2p`. Differential Revision: https://reviews.llvm.org/D105168
2021-06-23 16:18:54 +08:00
[RISCV] Remove unnecessary call to isSupportedExtensionFeature. hasExtension already checks if the extension is supported.
2023-12-09 14:16:09 -08:00
return ISAInfo->hasExtension(Feature);
[PATCH] [RISCV] Extend getTargetDefines for RISCVTargetInfo Summary: This patch extend getTargetDefines and implement handleTargetFeatures and hasFeature. and define corresponding marco for those features. Reviewers: asb, apazos, eli.friedman Differential Revision: https://reviews.llvm.org/D44727 Patch by Kito Cheng. llvm-svn: 329278
2018-04-05 12:54:00 +00:00
}
/// Perform initialization based on the user configured set of features.
bool RISCVTargetInfo::handleTargetFeatures(std::vector<std::string> &Features,
DiagnosticsEngine &Diags) {
[RISCV] Unify the arch string parsing logic to to RISCVISAInfo. How many place you need to modify when implementing a new extension for RISC-V? At least 7 places as I know: - Add new SubtargetFeature at RISCV.td - -march parser in RISCV.cpp - RISCVTargetInfo::initFeatureMap@RISCV.cpp for handling feature vector. - RISCVTargetInfo::getTargetDefines@RISCV.cpp for pre-define marco. - Arch string parser for ELF attribute in RISCVAsmParser.cpp - ELF attribute emittion in RISCVAsmParser.cpp, and make sure it's in canonical order... - ELF attribute emittion in RISCVTargetStreamer.cpp, and again, must in canonical order... And now, this patch provide an unified infrastructure for handling (almost) everything of RISC-V arch string. After this patch, you only need to update 2 places for implement an extension for RISC-V: - Add new SubtargetFeature at RISCV.td, hmmm, it's hard to avoid. - Add new entry to RISCVSupportedExtension@RISCVISAInfo.cpp or SupportedExperimentalExtensions@RISCVISAInfo.cpp . Most codes are come from existing -march parser, but with few new feature/bug fixes: - Accept version for -march, e.g. -march=rv32i2p0. - Reject version info with `p` but without minor version number like `rv32i2p`. Differential Revision: https://reviews.llvm.org/D105168
2021-06-23 16:18:54 +08:00
unsigned XLen = getTriple().isArch64Bit() ? 64 : 32;
auto ParseResult = llvm::RISCVISAInfo::parseFeatures(XLen, Features);
if (!ParseResult) {
std::string Buffer;
llvm::raw_string_ostream OutputErrMsg(Buffer);
handleAllErrors(ParseResult.takeError(), [&](llvm::StringError &ErrMsg) {
OutputErrMsg << ErrMsg.getMessage();
});
Diags.Report(diag::err_invalid_feature_combination) << OutputErrMsg.str();
return false;
} else {
ISAInfo = std::move(*ParseResult);
[PATCH] [RISCV] Extend getTargetDefines for RISCVTargetInfo Summary: This patch extend getTargetDefines and implement handleTargetFeatures and hasFeature. and define corresponding marco for those features. Reviewers: asb, apazos, eli.friedman Differential Revision: https://reviews.llvm.org/D44727 Patch by Kito Cheng. llvm-svn: 329278
2018-04-05 12:54:00 +00:00
}
[RISCV][Clang] Compute the default target-abi if it's empty. Every generated IR has a corresponding target-abi value, so encoding a non-empty value would improve the robustness and correctness. Reviewed By: asb, jrtc27, arichardson Differential Revision: https://reviews.llvm.org/D105555
2021-11-04 10:13:50 -07:00
if (ABI.empty())
[RISCV][NFC] Refactor RISCVISAInfo. 1. Remove computeDefaultABIFromArch and add computeDefaultABI in RISCVISAInfo. 2. Add parseFeatureBits which may used in D118333. Differential Revision: https://reviews.llvm.org/D119250
2022-02-08 07:42:48 -08:00
ABI = ISAInfo->computeDefaultABI().str();
[RISCV][Clang] Compute the default target-abi if it's empty. Every generated IR has a corresponding target-abi value, so encoding a non-empty value would improve the robustness and correctness. Reviewed By: asb, jrtc27, arichardson Differential Revision: https://reviews.llvm.org/D105555
2021-11-04 10:13:50 -07:00
[clang][RISCV] Set HasLegalHalfType to true if zhinx is enabled Now that codegen support for zhinx in landed (D149811), we should set HasLegalHalfType=true for zhinx (see D145071 for the patch doing this for zfh). Differential Revision: https://reviews.llvm.org/D150777
2023-05-18 15:01:48 +01:00
if (ISAInfo->hasExtension("zfh") || ISAInfo->hasExtension("zhinx"))
[clang][RISCV] Set HasLegalHalfType to true if zfh is enabled The desired semantics for HasLegalHalfType are slightly unclear in that the comment for HasLegalHalfType says "True if the backend supports operations on the half LLVM IR type." Which operations? We get very limited scalar operations with zfhmin, more with zfh, and vector support with zvfh. While the comment for hasLegalHalfType() says "Determine whether _Float16 is supported on this target." This patch sets HasLegalHalfType to true for zfh. Differential Revision: https://reviews.llvm.org/D145071
2023-05-05 13:53:50 +01:00
HasLegalHalfType = true;
[RISCV] Add -m[no-]scalar-strict-align and -m[no-]vector-strict-align. (#95024)
2024-07-14 13:39:17 -07:00
FastScalarUnalignedAccess =
llvm::is_contained(Features, "+unaligned-scalar-mem");
[RISCV] Support predefined macro __riscv_misaligned_[fast,avoid]. (#65756) RISC-V C API introduced predefined macro to achieve hints about unaligned accesses ([pr]). This patch defines __riscv_misaligned_fast when using -mno-strict-align, otherwise, defines __riscv_misaligned_avoid. Note: This ignores __riscv_misaligned_slow which is also defined by spec. [pr]: https://github.com/riscv-non-isa/riscv-c-api-doc/pull/40
2023-10-26 15:10:57 +08:00
[RISCV] Remove experimental from Vector Crypto extensions (#74213) The RISC-V vector crypto extensions have been ratified. This patch updates the Clang and LLVM support for these extensions to be non-experimental, while leaving the C intrinsics as experimental since the C intrinsics are not yet standardized. Co-authored-by: Brandon Wu <brandon.wu@sifive.com>
2023-12-18 22:04:22 -08:00
if (llvm::is_contained(Features, "+experimental"))
HasExperimental = true;
[RISCV] CodeGen of RVE and ilp32e/lp64e ABIs (#76777) This commit includes the necessary changes to clang and LLVM to support codegen of `RVE` and the `ilp32e`/`lp64e` ABIs. The differences between `RVE` and `RVI` are: * `RVE` reduces the integer register count to 16(x0-x16). * The ABI should be `ilp32e` for 32 bits and `lp64e` for 64 bits. `RVE` can be combined with all current standard extensions. The central changes in ilp32e/lp64e ABI, compared to ilp32/lp64 are: * Only 6 integer argument registers (rather than 8). * Only 2 callee-saved registers (rather than 12). * A Stack Alignment of 32bits (rather than 128bits). * ilp32e isn't compatible with D ISA extension. If `ilp32e` or `lp64` is used with an ISA that has any of the registers x16-x31 and f0-f31, then these registers are considered temporaries. To be compatible with the implementation of ilp32e in GCC, we don't use aligned registers to pass variadic arguments and set stack alignment\ to 4-bytes for types with length of 2*XLEN. FastCC is also supported on RVE, while GHC isn't since there is only one avaiable register. Differential Revision: https://reviews.llvm.org/D70401
2024-01-16 20:44:30 +08:00
if (ABI == "ilp32e" && ISAInfo->hasExtension("d")) {
Diags.Report(diag::err_invalid_feature_combination)
<< "ILP32E cannot be used with the D ISA extension";
return false;
}
[PATCH] [RISCV] Extend getTargetDefines for RISCVTargetInfo Summary: This patch extend getTargetDefines and implement handleTargetFeatures and hasFeature. and define corresponding marco for those features. Reviewers: asb, apazos, eli.friedman Differential Revision: https://reviews.llvm.org/D44727 Patch by Kito Cheng. llvm-svn: 329278
2018-04-05 12:54:00 +00:00
return true;
[RISCV] Add the RISCV target and compiler driver As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver support (RV64 to follow). Differential Revision: https://reviews.llvm.org/D39963 llvm-svn: 322276
2018-01-11 13:36:56 +00:00
}
[RISCV] Add support for -mcpu option. Summary: 1. gcc uses `-march` and `-mtune` flag to chose arch and pipeline model, but clang does not have `-mtune` flag, we uses `-mcpu` to chose both infos. 2. Add SiFive e31 and u54 cpu which have default march and pipeline model. 3. Specific `-mcpu` with rocket-rv[32|64] would select pipeline model only, and use the driver's arch choosing logic to get default arch. Reviewers: lenary, asb, evandro, HsiangKai Reviewed By: lenary, asb, evandro Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D71124
2020-07-16 10:32:01 -07:00
[RISCV] Move isValidCPUName to RISCVTargetInfo. NFC Instead of having separate implementations for RV32 and RV64, use the triple to control the Is64Bit parameter. Do the same for isValidTuneCPUName, fillValidCPUList, and fillValidTuneCPUList.
2022-08-11 09:45:32 -07:00
bool RISCVTargetInfo::isValidCPUName(StringRef Name) const {
bool Is64Bit = getTriple().isArch64Bit();
[RISCV] Merge RISCV::parseCPUKind and RISCV::checkCPUKind. Similar for RISCV::parseTuneCPU and RISCV::checkTuneCPUKind. This makes the CPUKind enum no longer part of the API. It wasn't providing much value. It was only used to pass between the two functions. By removing it, we can remove a dependency on a tablegen generated file from the RISCVTargetParser.h file. Then we can remove a dependency from several CMakeLists.txt.
2023-05-01 13:00:05 -07:00
return llvm::RISCV::parseCPU(Name, Is64Bit);
[RISCV] Add support for -mcpu option. Summary: 1. gcc uses `-march` and `-mtune` flag to chose arch and pipeline model, but clang does not have `-mtune` flag, we uses `-mcpu` to chose both infos. 2. Add SiFive e31 and u54 cpu which have default march and pipeline model. 3. Specific `-mcpu` with rocket-rv[32|64] would select pipeline model only, and use the driver's arch choosing logic to get default arch. Reviewers: lenary, asb, evandro, HsiangKai Reviewed By: lenary, asb, evandro Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D71124
2020-07-16 10:32:01 -07:00
}
[RISCV] Move isValidCPUName to RISCVTargetInfo. NFC Instead of having separate implementations for RV32 and RV64, use the triple to control the Is64Bit parameter. Do the same for isValidTuneCPUName, fillValidCPUList, and fillValidTuneCPUList.
2022-08-11 09:45:32 -07:00
void RISCVTargetInfo::fillValidCPUList(
[RISCV] Add support for -mcpu option. Summary: 1. gcc uses `-march` and `-mtune` flag to chose arch and pipeline model, but clang does not have `-mtune` flag, we uses `-mcpu` to chose both infos. 2. Add SiFive e31 and u54 cpu which have default march and pipeline model. 3. Specific `-mcpu` with rocket-rv[32|64] would select pipeline model only, and use the driver's arch choosing logic to get default arch. Reviewers: lenary, asb, evandro, HsiangKai Reviewed By: lenary, asb, evandro Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D71124
2020-07-16 10:32:01 -07:00
SmallVectorImpl<StringRef> &Values) const {
[RISCV] Move isValidCPUName to RISCVTargetInfo. NFC Instead of having separate implementations for RV32 and RV64, use the triple to control the Is64Bit parameter. Do the same for isValidTuneCPUName, fillValidCPUList, and fillValidTuneCPUList.
2022-08-11 09:45:32 -07:00
bool Is64Bit = getTriple().isArch64Bit();
llvm::RISCV::fillValidCPUArchList(Values, Is64Bit);
[RISCV] Add support for -mcpu option. Summary: 1. gcc uses `-march` and `-mtune` flag to chose arch and pipeline model, but clang does not have `-mtune` flag, we uses `-mcpu` to chose both infos. 2. Add SiFive e31 and u54 cpu which have default march and pipeline model. 3. Specific `-mcpu` with rocket-rv[32|64] would select pipeline model only, and use the driver's arch choosing logic to get default arch. Reviewers: lenary, asb, evandro, HsiangKai Reviewed By: lenary, asb, evandro Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D71124
2020-07-16 10:32:01 -07:00
}
[RISCV] Move isValidCPUName to RISCVTargetInfo. NFC Instead of having separate implementations for RV32 and RV64, use the triple to control the Is64Bit parameter. Do the same for isValidTuneCPUName, fillValidCPUList, and fillValidTuneCPUList.
2022-08-11 09:45:32 -07:00
bool RISCVTargetInfo::isValidTuneCPUName(StringRef Name) const {
bool Is64Bit = getTriple().isArch64Bit();
[RISCV] Merge RISCV::parseCPUKind and RISCV::checkCPUKind. Similar for RISCV::parseTuneCPU and RISCV::checkTuneCPUKind. This makes the CPUKind enum no longer part of the API. It wasn't providing much value. It was only used to pass between the two functions. By removing it, we can remove a dependency on a tablegen generated file from the RISCVTargetParser.h file. Then we can remove a dependency from several CMakeLists.txt.
2023-05-01 13:00:05 -07:00
return llvm::RISCV::parseTuneCPU(Name, Is64Bit);
[RISCV] Add -mtune support - The goal of this patch is improve option compatible with RISCV-V GCC, -mcpu support on GCC side will sent patch in next few days. - -mtune only affect the pipeline model and non-arch/extension related target feature, e.g. instruction fusion; in td file it called TuneFeatures, which is introduced by X86 back-end[1]. - -mtune accept all valid option for -mcpu and extra alias processor option, e.g. `generic`, `rocket` and `sifive-7-series`, the purpose is option compatible with RISCV-V GCC. - Processor alias for -mtune will resolve according the current target arch, rv32 or rv64, e.g. `rocket` will resolve to `rocket-rv32` or `rocket-rv64`. - Interaction between -mcpu and -mtune: * -mtune has higher priority than -mcpu for pipeline model and TuneFeatures. [1] https://reviews.llvm.org/D85165 Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D89025
2020-10-06 14:33:43 +08:00
}
[RISCV] Move isValidCPUName to RISCVTargetInfo. NFC Instead of having separate implementations for RV32 and RV64, use the triple to control the Is64Bit parameter. Do the same for isValidTuneCPUName, fillValidCPUList, and fillValidTuneCPUList.
2022-08-11 09:45:32 -07:00
void RISCVTargetInfo::fillValidTuneCPUList(
[RISCV] Add -mtune support - The goal of this patch is improve option compatible with RISCV-V GCC, -mcpu support on GCC side will sent patch in next few days. - -mtune only affect the pipeline model and non-arch/extension related target feature, e.g. instruction fusion; in td file it called TuneFeatures, which is introduced by X86 back-end[1]. - -mtune accept all valid option for -mcpu and extra alias processor option, e.g. `generic`, `rocket` and `sifive-7-series`, the purpose is option compatible with RISCV-V GCC. - Processor alias for -mtune will resolve according the current target arch, rv32 or rv64, e.g. `rocket` will resolve to `rocket-rv32` or `rocket-rv64`. - Interaction between -mcpu and -mtune: * -mtune has higher priority than -mcpu for pipeline model and TuneFeatures. [1] https://reviews.llvm.org/D85165 Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D89025
2020-10-06 14:33:43 +08:00
SmallVectorImpl<StringRef> &Values) const {
[RISCV] Move isValidCPUName to RISCVTargetInfo. NFC Instead of having separate implementations for RV32 and RV64, use the triple to control the Is64Bit parameter. Do the same for isValidTuneCPUName, fillValidCPUList, and fillValidTuneCPUList.
2022-08-11 09:45:32 -07:00
bool Is64Bit = getTriple().isArch64Bit();
llvm::RISCV::fillValidTuneCPUArchList(Values, Is64Bit);
[RISCV] Add -mtune support - The goal of this patch is improve option compatible with RISCV-V GCC, -mcpu support on GCC side will sent patch in next few days. - -mtune only affect the pipeline model and non-arch/extension related target feature, e.g. instruction fusion; in td file it called TuneFeatures, which is introduced by X86 back-end[1]. - -mtune accept all valid option for -mcpu and extra alias processor option, e.g. `generic`, `rocket` and `sifive-7-series`, the purpose is option compatible with RISCV-V GCC. - Processor alias for -mtune will resolve according the current target arch, rv32 or rv64, e.g. `rocket` will resolve to `rocket-rv32` or `rocket-rv64`. - Interaction between -mcpu and -mtune: * -mtune has higher priority than -mcpu for pipeline model and TuneFeatures. [1] https://reviews.llvm.org/D85165 Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D89025
2020-10-06 14:33:43 +08:00
}
[RISCV] Support target attribute for function The proposal of target attribute is https://github.com/riscv-non-isa/riscv-c-api-doc/pull/35 This patch implements it by emitting .option arch during codegen. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D151730
2023-11-23 22:58:35 -08:00
[RISCV][NFC] Reimplementation of target attribute override mechanism (#106680) This patch aims to replace the target attribute override mechanism based on `__RISCV_TargetAttrNeedOverride` with the insertion of several negative target features When the target attribute uses the full architecture string ("arch=rv64gc") or specifies the CPU ("cpu=rocket-rv64") as the version, it will override the module-level target feature. Currently, this mechanism is implemented by inserting `__RISCV_TargetAttrNeedOverride` as a dummy target feature immediately before the target attribute's feature. ``` module target features + __RISCV_TargetAttrNeedOverride + target attribute's feature ``` The RISCVTargetInfo::initFeatureMap function will remove the "module target features" and use only the "target attribute's features". This patch changes the process as follows: ``` module target features + negative target feature for all supported extension + target attribute's feature ``` The `module target features` will be disable by `negative target feature for all supported extension` in `TargetInfo::initFeatureMap`
2024-08-31 20:02:46 +08:00
static void populateNegativeRISCVFeatures(std::vector<std::string> &Features) {
auto RII = llvm::RISCVISAInfo::parseArchString(
"rv64i", /* EnableExperimentalExtension */ true);
if (llvm::errorToBool(RII.takeError()))
llvm_unreachable("unsupport rv64i");
std::vector<std::string> FeatStrings =
(*RII)->toFeatures(/* AddAllExtensions */ true);
Features.insert(Features.end(), FeatStrings.begin(), FeatStrings.end());
}
[RISCV] Support target attribute for function The proposal of target attribute is https://github.com/riscv-non-isa/riscv-c-api-doc/pull/35 This patch implements it by emitting .option arch during codegen. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D151730
2023-11-23 22:58:35 -08:00
static void handleFullArchString(StringRef FullArchStr,
std::vector<std::string> &Features) {
auto RII = llvm::RISCVISAInfo::parseArchString(
FullArchStr, /* EnableExperimentalExtension */ true);
[RISCV][NFC] Use errorToBool (#76429) To reduce calls to `consumeError`.
2023-12-28 12:59:11 +08:00
if (llvm::errorToBool(RII.takeError())) {
[RISCV] Support target attribute for function The proposal of target attribute is https://github.com/riscv-non-isa/riscv-c-api-doc/pull/35 This patch implements it by emitting .option arch during codegen. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D151730
2023-11-23 22:58:35 -08:00
// Forward the invalid FullArchStr.
[Clang][RISCV] Recognize unsupport target feature by supporting isValidFeatureName (#106495) This patch makes unsupported target attributes emit a warning and ignore the target attribute during semantic checks. The changes include: 1. Adding the RISCVTargetInfo::isValidFeatureName function. 2. Rejecting non-full-arch strings in the handleFullArchString function. 3. Adding test cases to demonstrate the warning behavior.
2024-09-09 15:07:39 +08:00
Features.push_back(FullArchStr.str());
[RISCV] Support target attribute for function The proposal of target attribute is https://github.com/riscv-non-isa/riscv-c-api-doc/pull/35 This patch implements it by emitting .option arch during codegen. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D151730
2023-11-23 22:58:35 -08:00
} else {
[RISCV] Overwrite cpu target features for full arch string in target attribute (#77426) This patch reworks RISCVTargetInfo::initFeatureMap to fix the issue described in https://github.com/llvm/llvm-project/pull/74889#pullrequestreview-1773445559 (and is an alternative to #75804) When a full arch string is specified, a "full" list of extensions is now passed after the __RISCV_TargetAttrNeedOverride marker feature, which includes any negative features that disable ISA extensions. In initFeatureMap, there are now two code paths: 1. If the arch string was overriden, use the "full" list of override features, only adding back any non-isa features that were specified. Using the full list of positive and negative features will mean that the target-cpu will have no effect on the final arch, e.g. __attribute__((target("arch=rv64i"))) with -mcpu=sifive-x280 will have the features for rv64i, not a mix of both. 2. Otherwise, parse and *append* the list of implied features. By appending, we turn back on any features that might have been disabled by a negative extension, i.e. this handles the case fixed in #74889.
2024-01-17 13:32:03 +07:00
// Append a full list of features, including any negative extensions so that
// we override the CPU's features.
[RISCV][NFC] Reimplementation of target attribute override mechanism (#106680) This patch aims to replace the target attribute override mechanism based on `__RISCV_TargetAttrNeedOverride` with the insertion of several negative target features When the target attribute uses the full architecture string ("arch=rv64gc") or specifies the CPU ("cpu=rocket-rv64") as the version, it will override the module-level target feature. Currently, this mechanism is implemented by inserting `__RISCV_TargetAttrNeedOverride` as a dummy target feature immediately before the target attribute's feature. ``` module target features + __RISCV_TargetAttrNeedOverride + target attribute's feature ``` The RISCVTargetInfo::initFeatureMap function will remove the "module target features" and use only the "target attribute's features". This patch changes the process as follows: ``` module target features + negative target feature for all supported extension + target attribute's feature ``` The `module target features` will be disable by `negative target feature for all supported extension` in `TargetInfo::initFeatureMap`
2024-08-31 20:02:46 +08:00
populateNegativeRISCVFeatures(Features);
[RISCV] Overwrite cpu target features for full arch string in target attribute (#77426) This patch reworks RISCVTargetInfo::initFeatureMap to fix the issue described in https://github.com/llvm/llvm-project/pull/74889#pullrequestreview-1773445559 (and is an alternative to #75804) When a full arch string is specified, a "full" list of extensions is now passed after the __RISCV_TargetAttrNeedOverride marker feature, which includes any negative features that disable ISA extensions. In initFeatureMap, there are now two code paths: 1. If the arch string was overriden, use the "full" list of override features, only adding back any non-isa features that were specified. Using the full list of positive and negative features will mean that the target-cpu will have no effect on the final arch, e.g. __attribute__((target("arch=rv64i"))) with -mcpu=sifive-x280 will have the features for rv64i, not a mix of both. 2. Otherwise, parse and *append* the list of implied features. By appending, we turn back on any features that might have been disabled by a negative extension, i.e. this handles the case fixed in #74889.
2024-01-17 13:32:03 +07:00
std::vector<std::string> FeatStrings =
(*RII)->toFeatures(/* AddAllExtensions */ true);
[RISCV] Minor improvements/cleanup to target attribute handling. NFC (#73851) Use ArrayRef to avoid a vector copy. Replace a push_back loop with a call to std::vector::insert.
2023-11-29 12:57:48 -08:00
Features.insert(Features.end(), FeatStrings.begin(), FeatStrings.end());
[RISCV] Support target attribute for function The proposal of target attribute is https://github.com/riscv-non-isa/riscv-c-api-doc/pull/35 This patch implements it by emitting .option arch during codegen. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D151730
2023-11-23 22:58:35 -08:00
}
}
ParsedTargetAttr RISCVTargetInfo::parseTargetAttr(StringRef Features) const {
ParsedTargetAttr Ret;
if (Features == "default")
return Ret;
SmallVector<StringRef, 1> AttrFeatures;
Features.split(AttrFeatures, ";");
bool FoundArch = false;
[NFC][clang][FMV][TargetInfo] Refactor API for FMV feature priority. (#116257) Currently we have code with target hooks in CodeGenModule shared between X86 and AArch64 for sorting MultiVersionResolverOptions. Those are used when generating IFunc resolvers for FMV. The RISCV target has different criteria for sorting, therefore it repeats sorting after calling CodeGenFunction::EmitMultiVersionResolver. I am moving the FMV priority logic in TargetInfo, so that it can be implemented by the TargetParser which then makes it possible to query it from llvm. Here is an example why this is handy: https://github.com/llvm/llvm-project/pull/87939
2024-11-28 09:22:05 +00:00
auto handleArchExtension = [](StringRef AttrString,
std::vector<std::string> &Features) {
SmallVector<StringRef, 1> Exts;
AttrString.split(Exts, ",");
for (auto Ext : Exts) {
if (Ext.empty())
continue;
StringRef ExtName = Ext.substr(1);
std::string TargetFeature =
llvm::RISCVISAInfo::getTargetFeatureForExtension(ExtName);
if (!TargetFeature.empty())
Features.push_back(Ext.front() + TargetFeature);
else
Features.push_back(Ext.str());
}
};
[RISCV] Support target attribute for function The proposal of target attribute is https://github.com/riscv-non-isa/riscv-c-api-doc/pull/35 This patch implements it by emitting .option arch during codegen. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D151730
2023-11-23 22:58:35 -08:00
for (auto &Feature : AttrFeatures) {
Feature = Feature.trim();
StringRef AttrString = Feature.split("=").second.trim();
[clang] Use StringRef::{starts,ends}_with (NFC) (#75149) This patch replaces uses of StringRef::{starts,ends}with with StringRef::{starts,ends}_with for consistency with std::{string,string_view}::{starts,ends}_with in C++20. I'm planning to deprecate and eventually remove StringRef::{starts,ends}with.
2023-12-13 08:54:13 -08:00
if (Feature.starts_with("arch=")) {
[RISCV] Support target attribute for function The proposal of target attribute is https://github.com/riscv-non-isa/riscv-c-api-doc/pull/35 This patch implements it by emitting .option arch during codegen. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D151730
2023-11-23 22:58:35 -08:00
// Override last features
Ret.Features.clear();
if (FoundArch)
Ret.Duplicate = "arch=";
FoundArch = true;
[clang] Use StringRef::{starts,ends}_with (NFC) (#75149) This patch replaces uses of StringRef::{starts,ends}with with StringRef::{starts,ends}_with for consistency with std::{string,string_view}::{starts,ends}_with in C++20. I'm planning to deprecate and eventually remove StringRef::{starts,ends}with.
2023-12-13 08:54:13 -08:00
if (AttrString.starts_with("+")) {
[RISCV] Support target attribute for function The proposal of target attribute is https://github.com/riscv-non-isa/riscv-c-api-doc/pull/35 This patch implements it by emitting .option arch during codegen. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D151730
2023-11-23 22:58:35 -08:00
// EXTENSION like arch=+v,+zbb
[NFC][clang][FMV][TargetInfo] Refactor API for FMV feature priority. (#116257) Currently we have code with target hooks in CodeGenModule shared between X86 and AArch64 for sorting MultiVersionResolverOptions. Those are used when generating IFunc resolvers for FMV. The RISCV target has different criteria for sorting, therefore it repeats sorting after calling CodeGenFunction::EmitMultiVersionResolver. I am moving the FMV priority logic in TargetInfo, so that it can be implemented by the TargetParser which then makes it possible to query it from llvm. Here is an example why this is handy: https://github.com/llvm/llvm-project/pull/87939
2024-11-28 09:22:05 +00:00
handleArchExtension(AttrString, Ret.Features);
[RISCV] Support target attribute for function The proposal of target attribute is https://github.com/riscv-non-isa/riscv-c-api-doc/pull/35 This patch implements it by emitting .option arch during codegen. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D151730
2023-11-23 22:58:35 -08:00
} else {
// full-arch-string like arch=rv64gcv
handleFullArchString(AttrString, Ret.Features);
}
[clang] Use StringRef::{starts,ends}_with (NFC) (#75149) This patch replaces uses of StringRef::{starts,ends}with with StringRef::{starts,ends}_with for consistency with std::{string,string_view}::{starts,ends}_with in C++20. I'm planning to deprecate and eventually remove StringRef::{starts,ends}with.
2023-12-13 08:54:13 -08:00
} else if (Feature.starts_with("cpu=")) {
[RISCV] Support target attribute for function The proposal of target attribute is https://github.com/riscv-non-isa/riscv-c-api-doc/pull/35 This patch implements it by emitting .option arch during codegen. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D151730
2023-11-23 22:58:35 -08:00
if (!Ret.CPU.empty())
Ret.Duplicate = "cpu=";
Ret.CPU = AttrString;
if (!FoundArch) {
// Update Features with CPU's features
StringRef MarchFromCPU = llvm::RISCV::getMArchFromMcpu(Ret.CPU);
if (MarchFromCPU != "") {
Ret.Features.clear();
handleFullArchString(MarchFromCPU, Ret.Features);
}
}
[clang] Use StringRef::{starts,ends}_with (NFC) (#75149) This patch replaces uses of StringRef::{starts,ends}with with StringRef::{starts,ends}_with for consistency with std::{string,string_view}::{starts,ends}_with in C++20. I'm planning to deprecate and eventually remove StringRef::{starts,ends}with.
2023-12-13 08:54:13 -08:00
} else if (Feature.starts_with("tune=")) {
[RISCV] Support target attribute for function The proposal of target attribute is https://github.com/riscv-non-isa/riscv-c-api-doc/pull/35 This patch implements it by emitting .option arch during codegen. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D151730
2023-11-23 22:58:35 -08:00
if (!Ret.Tune.empty())
Ret.Duplicate = "tune=";
Ret.Tune = AttrString;
[RISCV][FMV] Support target_clones (#85786) This patch enable the function multiversion(FMV) and `target_clones` attribute for RISC-V target. The proposal of `target_clones` syntax can be found at the https://github.com/riscv-non-isa/riscv-c-api-doc/pull/48 (which has landed), as modified by the proposed https://github.com/riscv-non-isa/riscv-c-api-doc/pull/85 (which adds the priority syntax). It supports the `target_clones` function attribute and function multiversioning feature for RISC-V target. It will generate the ifunc resolver function for the function that declared with target_clones attribute. The resolver function will check the version support by runtime object `__riscv_feature_bits`. For example: ``` __attribute__((target_clones("default", "arch=+ver1", "arch=+ver2"))) int bar() { return 1; } ``` the corresponding resolver will be like: ``` bar.resolver() { __init_riscv_feature_bits(); // Check arch=+ver1 if ((__riscv_feature_bits.features[0] & BITMASK_OF_VERSION1) == BITMASK_OF_VERSION1) { return bar.arch=+ver1; } else { // Check arch=+ver2 if ((__riscv_feature_bits.features[0] & BITMASK_OF_VERSION2) == BITMASK_OF_VERSION2) { return bar.arch=+ver2; } else { // Default return bar.default; } } } ```
2024-09-13 18:04:53 +08:00
} else if (Feature.starts_with("priority")) {
// Skip because it only use for FMV.
[NFC][clang][FMV][TargetInfo] Refactor API for FMV feature priority. (#116257) Currently we have code with target hooks in CodeGenModule shared between X86 and AArch64 for sorting MultiVersionResolverOptions. Those are used when generating IFunc resolvers for FMV. The RISCV target has different criteria for sorting, therefore it repeats sorting after calling CodeGenFunction::EmitMultiVersionResolver. I am moving the FMV priority logic in TargetInfo, so that it can be implemented by the TargetParser which then makes it possible to query it from llvm. Here is an example why this is handy: https://github.com/llvm/llvm-project/pull/87939
2024-11-28 09:22:05 +00:00
} else if (Feature.starts_with("+")) {
// Handle target_version/target_clones attribute strings
// that are already delimited by ','
handleArchExtension(Feature, Ret.Features);
[RISCV] Support target attribute for function The proposal of target attribute is https://github.com/riscv-non-isa/riscv-c-api-doc/pull/35 This patch implements it by emitting .option arch during codegen. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D151730
2023-11-23 22:58:35 -08:00
}
}
return Ret;
}
[RISCV] RISCV vector calling convention (1/2) (#77560) [RISCV] RISCV vector calling convention (1/2) This is the vector calling convention based on https://github.com/riscv-non-isa/riscv-elf-psabi-doc, the idea is to split between "scalar" callee-saved registers and "vector" callee-saved registers. "scalar" ones remain the original strategy, however, "vector" ones are handled together with RVV objects. The stack layout would be: |--------------------------| <-- FP | callee-allocated save | | area for register varargs| |--------------------------| | callee-saved registers | <-- scalar callee-saved | (scalar) | |--------------------------| | RVV alignment padding | |--------------------------| | callee-saved registers | <-- vector callee-saved | (vector) | |--------------------------| | RVV objects | |--------------------------| | padding before RVV | |--------------------------| | scalar local variables | |--------------------------| <-- BP | variable size objects | |--------------------------| <-- SP Note: This patch doesn't contain "tuple" type, e.g. vint32m1x2. It will be handled in https://github.com/riscv-non-isa/riscv-elf-psabi-doc (2/2). Differential Revision: https://reviews.llvm.org/D154576
2024-03-27 23:03:13 +08:00
[FMV][AArch64] Simplify version selection according to ACLE. (#121921) Currently, the more features a version has, the higher its priority is. We are changing ACLE https://github.com/ARM-software/acle/pull/370 as follows: "Among any two versions, the higher priority version is determined by identifying the highest priority feature that is specified in exactly one of the versions, and selecting that version."
2025-01-08 18:59:07 +00:00
uint64_t RISCVTargetInfo::getFMVPriority(ArrayRef<StringRef> Features) const {
[NFC][clang][FMV][TargetInfo] Refactor API for FMV feature priority. (#116257) Currently we have code with target hooks in CodeGenModule shared between X86 and AArch64 for sorting MultiVersionResolverOptions. Those are used when generating IFunc resolvers for FMV. The RISCV target has different criteria for sorting, therefore it repeats sorting after calling CodeGenFunction::EmitMultiVersionResolver. I am moving the FMV priority logic in TargetInfo, so that it can be implemented by the TargetParser which then makes it possible to query it from llvm. Here is an example why this is handy: https://github.com/llvm/llvm-project/pull/87939
2024-11-28 09:22:05 +00:00
// Priority is explicitly specified on RISC-V unlike on other targets, where
// it is derived by all the features of a specific version. Therefore if a
// feature contains the priority string, then return it immediately.
for (StringRef Feature : Features) {
auto [LHS, RHS] = Feature.rsplit(';');
if (LHS.consume_front("priority="))
Feature = LHS;
else if (RHS.consume_front("priority="))
Feature = RHS;
else
continue;
[FMV][AArch64] Simplify version selection according to ACLE. (#121921) Currently, the more features a version has, the higher its priority is. We are changing ACLE https://github.com/ARM-software/acle/pull/370 as follows: "Among any two versions, the higher priority version is determined by identifying the highest priority feature that is specified in exactly one of the versions, and selecting that version."
2025-01-08 18:59:07 +00:00
uint64_t Priority;
[NFC][clang][FMV][TargetInfo] Refactor API for FMV feature priority. (#116257) Currently we have code with target hooks in CodeGenModule shared between X86 and AArch64 for sorting MultiVersionResolverOptions. Those are used when generating IFunc resolvers for FMV. The RISCV target has different criteria for sorting, therefore it repeats sorting after calling CodeGenFunction::EmitMultiVersionResolver. I am moving the FMV priority logic in TargetInfo, so that it can be implemented by the TargetParser which then makes it possible to query it from llvm. Here is an example why this is handy: https://github.com/llvm/llvm-project/pull/87939
2024-11-28 09:22:05 +00:00
if (!Feature.getAsInteger(0, Priority))
return Priority;
}
// Default Priority is zero.
return 0;
}
[RISCV] RISCV vector calling convention (1/2) (#77560) [RISCV] RISCV vector calling convention (1/2) This is the vector calling convention based on https://github.com/riscv-non-isa/riscv-elf-psabi-doc, the idea is to split between "scalar" callee-saved registers and "vector" callee-saved registers. "scalar" ones remain the original strategy, however, "vector" ones are handled together with RVV objects. The stack layout would be: |--------------------------| <-- FP | callee-allocated save | | area for register varargs| |--------------------------| | callee-saved registers | <-- scalar callee-saved | (scalar) | |--------------------------| | RVV alignment padding | |--------------------------| | callee-saved registers | <-- vector callee-saved | (vector) | |--------------------------| | RVV objects | |--------------------------| | padding before RVV | |--------------------------| | scalar local variables | |--------------------------| <-- BP | variable size objects | |--------------------------| <-- SP Note: This patch doesn't contain "tuple" type, e.g. vint32m1x2. It will be handled in https://github.com/riscv-non-isa/riscv-elf-psabi-doc (2/2). Differential Revision: https://reviews.llvm.org/D154576
2024-03-27 23:03:13 +08:00
TargetInfo::CallingConvCheckResult
RISCVTargetInfo::checkCallingConvention(CallingConv CC) const {
switch (CC) {
default:
return CCCR_Warning;
case CC_C:
case CC_RISCVVectorCall:
[RISCV][VLS] Support RISCV VLS calling convention (#100346) This patch adds a function attribute `riscv_vls_cc` for RISCV VLS calling convention which takes 0 or 1 argument, the argument is the `ABI_VLEN` which is the `VLEN` for passing the fixed-vector arguments, it wraps the argument as a scalable vector(VLA) using the `ABI_VLEN` and uses the corresponding mechanism to handle it. The range of `ABI_VLEN` is [32, 65536], if not specified, the default value is 128. Here is an example of VLS argument passing: Non-VLS call: ``` void original_call(__attribute__((vector_size(16))) int arg) {} => define void @original_call(i128 noundef %arg) { entry: ... ret void } ``` VLS call: ``` void __attribute__((riscv_vls_cc(256))) vls_call(__attribute__((vector_size(16))) int arg) {} => define riscv_vls_cc void @vls_call(<vscale x 1 x i32> %arg) { entry: ... ret void } } ``` The first Non-VLS call passes generic vector argument of 16 bytes by flattened integer. On the contrary, the VLS call uses `ABI_VLEN=256` which wraps the vector to <vscale x 1 x i32> where the number of scalable vector elements is calaulated by: `ORIG_ELTS * RVV_BITS_PER_BLOCK / ABI_VLEN`. Note: ORIG_ELTS = Vector Size / Type Size = 128 / 32 = 4. PsABI PR: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/418 C-API PR: https://github.com/riscv-non-isa/riscv-c-api-doc/pull/68
2025-03-03 12:39:35 +08:00
case CC_RISCVVLSCall_32:
case CC_RISCVVLSCall_64:
case CC_RISCVVLSCall_128:
case CC_RISCVVLSCall_256:
case CC_RISCVVLSCall_512:
case CC_RISCVVLSCall_1024:
case CC_RISCVVLSCall_2048:
case CC_RISCVVLSCall_4096:
case CC_RISCVVLSCall_8192:
case CC_RISCVVLSCall_16384:
case CC_RISCVVLSCall_32768:
case CC_RISCVVLSCall_65536:
[RISCV] RISCV vector calling convention (1/2) (#77560) [RISCV] RISCV vector calling convention (1/2) This is the vector calling convention based on https://github.com/riscv-non-isa/riscv-elf-psabi-doc, the idea is to split between "scalar" callee-saved registers and "vector" callee-saved registers. "scalar" ones remain the original strategy, however, "vector" ones are handled together with RVV objects. The stack layout would be: |--------------------------| <-- FP | callee-allocated save | | area for register varargs| |--------------------------| | callee-saved registers | <-- scalar callee-saved | (scalar) | |--------------------------| | RVV alignment padding | |--------------------------| | callee-saved registers | <-- vector callee-saved | (vector) | |--------------------------| | RVV objects | |--------------------------| | padding before RVV | |--------------------------| | scalar local variables | |--------------------------| <-- BP | variable size objects | |--------------------------| <-- SP Note: This patch doesn't contain "tuple" type, e.g. vint32m1x2. It will be handled in https://github.com/riscv-non-isa/riscv-elf-psabi-doc (2/2). Differential Revision: https://reviews.llvm.org/D154576
2024-03-27 23:03:13 +08:00
return CCCR_OK;
}
}
[RISCV] Support __builtin_cpu_init and __builtin_cpu_supports (#99700) This implements the __builtin_cpu_init and __builtin_cpu_supports builtin routines based on the compiler runtime changes in https://github.com/llvm/llvm-project/pull/85790. This is inspired by https://github.com/llvm/llvm-project/pull/85786. Major changes are a) a restriction in scope to only the builtins (which have a much narrower user interface), and the avoidance of false generality. This change deliberately only handles group 0 extensions (which happen to be all defined ones today), and avoids the tblgen changes from that review. I don't have an environment in which I can actually test this, but @BeMg has been kind enough to report that this appears to work as expected. Before this can make it into a release, we need a change such as https://github.com/llvm/llvm-project/pull/99958. The gcc docs claim that cpu_support can be called by "normal" code without calling the cpu_init routine because the init routine will have been called by a high priority constructor. Our current compiler-rt mechanism does not do this.
2024-07-23 08:48:28 -07:00
bool RISCVTargetInfo::validateCpuSupports(StringRef Feature) const {
// Only allow extensions we have a known bit position for in the
// __riscv_feature_bits structure.
[RISCV] Support new groupid/bitmask for cpu_model (#101632) The spec can be found at https://github.com/riscv-non-isa/riscv-c-api-doc/pull/74. 1. Add the new extension GroupID/Bitmask with latest hwprobe key. 2. Update the `initRISCVFeature ` 3. Update `EmitRISCVCpuSupports` due to not only group0 now.
2024-08-08 14:42:41 +08:00
return -1 != llvm::RISCVISAInfo::getRISCVFeaturesBitsInfo(Feature).second;
[RISCV] Support __builtin_cpu_init and __builtin_cpu_supports (#99700) This implements the __builtin_cpu_init and __builtin_cpu_supports builtin routines based on the compiler runtime changes in https://github.com/llvm/llvm-project/pull/85790. This is inspired by https://github.com/llvm/llvm-project/pull/85786. Major changes are a) a restriction in scope to only the builtins (which have a much narrower user interface), and the avoidance of false generality. This change deliberately only handles group 0 extensions (which happen to be all defined ones today), and avoids the tblgen changes from that review. I don't have an environment in which I can actually test this, but @BeMg has been kind enough to report that this appears to work as expected. Before this can make it into a release, we need a change such as https://github.com/llvm/llvm-project/pull/99958. The gcc docs claim that cpu_support can be called by "normal" code without calling the cpu_init routine because the init routine will have been called by a high priority constructor. Our current compiler-rt mechanism does not do this.
2024-07-23 08:48:28 -07:00
}
[Clang][RISCV] Recognize unsupport target feature by supporting isValidFeatureName (#106495) This patch makes unsupported target attributes emit a warning and ignore the target attribute during semantic checks. The changes include: 1. Adding the RISCVTargetInfo::isValidFeatureName function. 2. Rejecting non-full-arch strings in the handleFullArchString function. 3. Adding test cases to demonstrate the warning behavior.
2024-09-09 15:07:39 +08:00
bool RISCVTargetInfo::isValidFeatureName(StringRef Name) const {
return llvm::RISCVISAInfo::isSupportedExtensionFeature(Name);
}
[RISCV] Implement validateGlobalRegisterVariable. (#109596) Only allow GPR registers and verify the size is the same as XLen. This fixes the crash seen in #109588 by making it a frontend error. gcc does accept the code so we may need to consider if we can fix the backend. Some other targets I tried appear to have similar issues so it might not be straightforward to fix.
2024-09-23 10:24:27 -07:00
bool RISCVTargetInfo::validateGlobalRegisterVariable(
StringRef RegName, unsigned RegSize, bool &HasSizeMismatch) const {
if (RegName == "ra" || RegName == "sp" || RegName == "gp" ||
RegName == "tp" || RegName.starts_with("x") || RegName.starts_with("a") ||
RegName.starts_with("s") || RegName.starts_with("t")) {
unsigned XLen = getTriple().isArch64Bit() ? 64 : 32;
HasSizeMismatch = RegSize != XLen;
return true;
}
return false;
}
[RISCV] Support __builtin_cpu_is We have defined `__riscv_cpu_model` variable in #101449. It contains `mvendorid`, `marchid` and `mimpid` fields which are read via system call `sys_riscv_hwprobe`. We can support `__builtin_cpu_is` via comparing values in compiler's CPU definitions and `__riscv_cpu_model`. This depends on #116202. Reviewers: lenary, BeMg, kito-cheng, preames, lukel97 Reviewed By: lenary Pull Request: https://github.com/llvm/llvm-project/pull/116231
2024-11-22 20:04:57 +08:00
bool RISCVTargetInfo::validateCpuIs(StringRef CPUName) const {
assert(getTriple().isOSLinux() &&
"__builtin_cpu_is() is only supported for Linux.");
return llvm::RISCV::hasValidCPUModel(CPUName);
}
Reference in New Issue Copy Permalink