maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/lib/Target/RISCV/RISCV.td

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

290 lines
13 KiB
TableGen
Raw Normal View History

[RISCV 4/10] Add basic RISCV{InstrFormats,InstrInfo,RegisterInfo,}.td For now, only add instruction definitions for basic ALU operations. Our initial target is a working MC layer rather than codegen, so appropriate SelectionDAG patterns will come later. Differential Revision: https://reviews.llvm.org/D23561 llvm-svn: 285769
2016-11-02 07:40:28 +08:00
//===-- RISCV.td - Describe the RISCV Target Machine -------*- tablegen -*-===//
//
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 16:50:56 +08: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 4/10] Add basic RISCV{InstrFormats,InstrInfo,RegisterInfo,}.td For now, only add instruction definitions for basic ALU operations. Our initial target is a working MC layer rather than codegen, so appropriate SelectionDAG patterns will come later. Differential Revision: https://reviews.llvm.org/D23561 llvm-svn: 285769
2016-11-02 07:40:28 +08:00
//
//===----------------------------------------------------------------------===//
include "llvm/Target/Target.td"
[RISCV] Prepare for the use of variable-sized register classes While parameterising by XLen, also take the opportunity to clean up the formatting of the RISCV .td files. This commit unifies the in-tree code with my patchset at <https://github.com/lowrisc/riscv-llvm>. llvm-svn: 316159
2017-10-19 22:29:03 +08:00
//===----------------------------------------------------------------------===//
// RISC-V subtarget features and instruction predicates.
//===----------------------------------------------------------------------===//
[RISCV 4/10] Add basic RISCV{InstrFormats,InstrInfo,RegisterInfo,}.td For now, only add instruction definitions for basic ALU operations. Our initial target is a working MC layer rather than codegen, so appropriate SelectionDAG patterns will come later. Differential Revision: https://reviews.llvm.org/D23561 llvm-svn: 285769
2016-11-02 07:40:28 +08:00
[RISCV] MC layer support for the standard RV32A instruction set extension llvm-svn: 317791
2017-11-09 23:00:03 +08:00
def FeatureStdExtM
: SubtargetFeature<"m", "HasStdExtM", "true",
"'M' (Integer Multiplication and Division)">;
def HasStdExtM : Predicate<"Subtarget->hasStdExtM()">,
[TableGen] Support combining AssemblerPredicates with ORs For context, the proposed RISC-V bit manipulation extension has a subset of instructions which require one of two SubtargetFeatures to be enabled, 'zbb' or 'zbp', and there is no defined feature which both of these can imply to use as a constraint either (see comments in D65649). AssemblerPredicates allow multiple SubtargetFeatures to be declared in the "AssemblerCondString" field, separated by commas, and this means that the two features must both be enabled. There is no equivalent to say that _either_ feature X or feature Y must be enabled, short of creating a dummy SubtargetFeature for this purpose and having features X and Y imply the new feature. To solve the case where X or Y is needed without adding a new feature, and to better match a typical TableGen style, this replaces the existing "AssemblerCondString" with a dag "AssemblerCondDag" which represents the same information. Two operators are defined for use with AssemblerCondDag, "all_of", which matches the current behaviour, and "any_of", which adds the new proposed ORing features functionality. This was originally proposed in the RFC at http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html Changes to all current backends are mechanical to support the replaced functionality, and are NFCI. At this stage, it is illegal to combine features with ands and ors in a single AssemblerCondDag. I suspect this case is sufficiently rare that adding more complex changes to support it are unnecessary. Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
AssemblerPredicate<(all_of FeatureStdExtM),
[RISCV] Improve assembler missing feature warnings This adds support for printing improved missing feature error messages from the assembler, which now indicates which feature caused the parse to fail. Differential Revision: https://reviews.llvm.org/D69899
2019-12-11 00:44:48 +08:00
"'M' (Integer Multiplication and Division)">;
[RISCV 4/10] Add basic RISCV{InstrFormats,InstrInfo,RegisterInfo,}.td For now, only add instruction definitions for basic ALU operations. Our initial target is a working MC layer rather than codegen, so appropriate SelectionDAG patterns will come later. Differential Revision: https://reviews.llvm.org/D23561 llvm-svn: 285769
2016-11-02 07:40:28 +08:00
[RISCV] MC layer support for the standard RV32A instruction set extension llvm-svn: 317791
2017-11-09 23:00:03 +08:00
def FeatureStdExtA
: SubtargetFeature<"a", "HasStdExtA", "true",
"'A' (Atomic Instructions)">;
def HasStdExtA : Predicate<"Subtarget->hasStdExtA()">,
[TableGen] Support combining AssemblerPredicates with ORs For context, the proposed RISC-V bit manipulation extension has a subset of instructions which require one of two SubtargetFeatures to be enabled, 'zbb' or 'zbp', and there is no defined feature which both of these can imply to use as a constraint either (see comments in D65649). AssemblerPredicates allow multiple SubtargetFeatures to be declared in the "AssemblerCondString" field, separated by commas, and this means that the two features must both be enabled. There is no equivalent to say that _either_ feature X or feature Y must be enabled, short of creating a dummy SubtargetFeature for this purpose and having features X and Y imply the new feature. To solve the case where X or Y is needed without adding a new feature, and to better match a typical TableGen style, this replaces the existing "AssemblerCondString" with a dag "AssemblerCondDag" which represents the same information. Two operators are defined for use with AssemblerCondDag, "all_of", which matches the current behaviour, and "any_of", which adds the new proposed ORing features functionality. This was originally proposed in the RFC at http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html Changes to all current backends are mechanical to support the replaced functionality, and are NFCI. At this stage, it is illegal to combine features with ands and ors in a single AssemblerCondDag. I suspect this case is sufficiently rare that adding more complex changes to support it are unnecessary. Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
AssemblerPredicate<(all_of FeatureStdExtA),
[RISCV] Improve assembler missing feature warnings This adds support for printing improved missing feature error messages from the assembler, which now indicates which feature caused the parse to fail. Differential Revision: https://reviews.llvm.org/D69899
2019-12-11 00:44:48 +08:00
"'A' (Atomic Instructions)">;
[RISCV] MC layer support for the standard RV32A instruction set extension llvm-svn: 317791
2017-11-09 23:00:03 +08:00
[RISCV] MC layer support for the standard RV32F instruction set extension The most interesting part of this patch is probably the handling of rounding mode arguments. Sadly, the RISC-V assembler handles floating point rounding modes as a special "argument" when it would be more consistent to handle them like the atomics, opcode suffixes. This patch supports parsing this optional parameter, using InstAlias to allow parsing these floating point instructions when no rounding mode is specified. Differential Revision: https://reviews.llvm.org/D39893 llvm-svn: 320020
2017-12-07 18:26:05 +08:00
def FeatureStdExtF
: SubtargetFeature<"f", "HasStdExtF", "true",
"'F' (Single-Precision Floating-Point)">;
def HasStdExtF : Predicate<"Subtarget->hasStdExtF()">,
[TableGen] Support combining AssemblerPredicates with ORs For context, the proposed RISC-V bit manipulation extension has a subset of instructions which require one of two SubtargetFeatures to be enabled, 'zbb' or 'zbp', and there is no defined feature which both of these can imply to use as a constraint either (see comments in D65649). AssemblerPredicates allow multiple SubtargetFeatures to be declared in the "AssemblerCondString" field, separated by commas, and this means that the two features must both be enabled. There is no equivalent to say that _either_ feature X or feature Y must be enabled, short of creating a dummy SubtargetFeature for this purpose and having features X and Y imply the new feature. To solve the case where X or Y is needed without adding a new feature, and to better match a typical TableGen style, this replaces the existing "AssemblerCondString" with a dag "AssemblerCondDag" which represents the same information. Two operators are defined for use with AssemblerCondDag, "all_of", which matches the current behaviour, and "any_of", which adds the new proposed ORing features functionality. This was originally proposed in the RFC at http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html Changes to all current backends are mechanical to support the replaced functionality, and are NFCI. At this stage, it is illegal to combine features with ands and ors in a single AssemblerCondDag. I suspect this case is sufficiently rare that adding more complex changes to support it are unnecessary. Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
AssemblerPredicate<(all_of FeatureStdExtF),
[RISCV] Improve assembler missing feature warnings This adds support for printing improved missing feature error messages from the assembler, which now indicates which feature caused the parse to fail. Differential Revision: https://reviews.llvm.org/D69899
2019-12-11 00:44:48 +08:00
"'F' (Single-Precision Floating-Point)">;
[RISCV] MC layer support for the standard RV32F instruction set extension The most interesting part of this patch is probably the handling of rounding mode arguments. Sadly, the RISC-V assembler handles floating point rounding modes as a special "argument" when it would be more consistent to handle them like the atomics, opcode suffixes. This patch supports parsing this optional parameter, using InstAlias to allow parsing these floating point instructions when no rounding mode is specified. Differential Revision: https://reviews.llvm.org/D39893 llvm-svn: 320020
2017-12-07 18:26:05 +08:00
[RISCV] MC layer support for the standard RV32D instruction set extension As the FPR32 and FPR64 registers have the same names, use validateTargetOperandClass in RISCVAsmParser to coerce a parsed FPR32 to an FPR64 when necessary. The rest of this patch is very similar to the RV32F patch. Differential Revision: https://reviews.llvm.org/D39895 llvm-svn: 320023
2017-12-07 18:46:23 +08:00
def FeatureStdExtD
: SubtargetFeature<"d", "HasStdExtD", "true",
"'D' (Double-Precision Floating-Point)",
[FeatureStdExtF]>;
def HasStdExtD : Predicate<"Subtarget->hasStdExtD()">,
[TableGen] Support combining AssemblerPredicates with ORs For context, the proposed RISC-V bit manipulation extension has a subset of instructions which require one of two SubtargetFeatures to be enabled, 'zbb' or 'zbp', and there is no defined feature which both of these can imply to use as a constraint either (see comments in D65649). AssemblerPredicates allow multiple SubtargetFeatures to be declared in the "AssemblerCondString" field, separated by commas, and this means that the two features must both be enabled. There is no equivalent to say that _either_ feature X or feature Y must be enabled, short of creating a dummy SubtargetFeature for this purpose and having features X and Y imply the new feature. To solve the case where X or Y is needed without adding a new feature, and to better match a typical TableGen style, this replaces the existing "AssemblerCondString" with a dag "AssemblerCondDag" which represents the same information. Two operators are defined for use with AssemblerCondDag, "all_of", which matches the current behaviour, and "any_of", which adds the new proposed ORing features functionality. This was originally proposed in the RFC at http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html Changes to all current backends are mechanical to support the replaced functionality, and are NFCI. At this stage, it is illegal to combine features with ands and ors in a single AssemblerCondDag. I suspect this case is sufficiently rare that adding more complex changes to support it are unnecessary. Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
AssemblerPredicate<(all_of FeatureStdExtD),
[RISCV] Improve assembler missing feature warnings This adds support for printing improved missing feature error messages from the assembler, which now indicates which feature caused the parse to fail. Differential Revision: https://reviews.llvm.org/D69899
2019-12-11 00:44:48 +08:00
"'D' (Double-Precision Floating-Point)">;
[RISCV] MC layer support for the standard RV32D instruction set extension As the FPR32 and FPR64 registers have the same names, use validateTargetOperandClass in RISCVAsmParser to coerce a parsed FPR32 to an FPR64 when necessary. The rest of this patch is very similar to the RV32F patch. Differential Revision: https://reviews.llvm.org/D39895 llvm-svn: 320023
2017-12-07 18:46:23 +08:00
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 22:57:59 +08:00
def FeatureExtZfh
: SubtargetFeature<"experimental-zfh", "HasStdExtZfh", "true",
"'Zfh' (Half-Precision Floating-Point)",
[FeatureStdExtF]>;
def HasStdExtZfh : Predicate<"Subtarget->hasStdExtZfh()">,
AssemblerPredicate<(all_of FeatureExtZfh),
"'Zfh' (Half-Precision Floating-Point)">;
[RISCV] MC layer support for load/store instructions of the C (compressed) extension Differential Revision: https://reviews.llvm.org/D40001 Patch by Shiva Chen. llvm-svn: 320037
2017-12-07 20:50:32 +08:00
def FeatureStdExtC
: SubtargetFeature<"c", "HasStdExtC", "true",
"'C' (Compressed Instructions)">;
def HasStdExtC : Predicate<"Subtarget->hasStdExtC()">,
[TableGen] Support combining AssemblerPredicates with ORs For context, the proposed RISC-V bit manipulation extension has a subset of instructions which require one of two SubtargetFeatures to be enabled, 'zbb' or 'zbp', and there is no defined feature which both of these can imply to use as a constraint either (see comments in D65649). AssemblerPredicates allow multiple SubtargetFeatures to be declared in the "AssemblerCondString" field, separated by commas, and this means that the two features must both be enabled. There is no equivalent to say that _either_ feature X or feature Y must be enabled, short of creating a dummy SubtargetFeature for this purpose and having features X and Y imply the new feature. To solve the case where X or Y is needed without adding a new feature, and to better match a typical TableGen style, this replaces the existing "AssemblerCondString" with a dag "AssemblerCondDag" which represents the same information. Two operators are defined for use with AssemblerCondDag, "all_of", which matches the current behaviour, and "any_of", which adds the new proposed ORing features functionality. This was originally proposed in the RFC at http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html Changes to all current backends are mechanical to support the replaced functionality, and are NFCI. At this stage, it is illegal to combine features with ands and ors in a single AssemblerCondDag. I suspect this case is sufficiently rare that adding more complex changes to support it are unnecessary. Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
AssemblerPredicate<(all_of FeatureStdExtC),
[RISCV] Improve assembler missing feature warnings This adds support for printing improved missing feature error messages from the assembler, which now indicates which feature caused the parse to fail. Differential Revision: https://reviews.llvm.org/D69899
2019-12-11 00:44:48 +08:00
"'C' (Compressed Instructions)">;
[RISCV] MC layer support for load/store instructions of the C (compressed) extension Differential Revision: https://reviews.llvm.org/D40001 Patch by Shiva Chen. llvm-svn: 320037
2017-12-07 20:50:32 +08:00
[RISCV] Add MC layer support for proposed Bit Manipulation extension (version 0.92) This adds the instruction encoding and mnenomics for the proposed RISC-V Bit Manipulation extension (version 0.92). It is implemented with each category of instruction as its own target feature, with the 'b' extension feature enabling all options. Since this extension is not yet ratified, all target features are prefixed with 'experimental-' to note their status. Differential Revision: https://reviews.llvm.org/D65649
2020-04-10 00:51:10 +08:00
def FeatureExtZbb
: SubtargetFeature<"experimental-zbb", "HasStdExtZbb", "true",
"'Zbb' (Base 'B' Instructions)">;
def HasStdExtZbb : Predicate<"Subtarget->hasStdExtZbb()">,
AssemblerPredicate<(all_of FeatureExtZbb),
"'Zbb' (Base 'B' Instructions)">;
def FeatureExtZbc
: SubtargetFeature<"experimental-zbc", "HasStdExtZbc", "true",
"'Zbc' (Carry-Less 'B' Instructions)">;
def HasStdExtZbc : Predicate<"Subtarget->hasStdExtZbc()">,
AssemblerPredicate<(all_of FeatureExtZbc),
"'Zbc' (Carry-Less 'B' Instructions)">;
def FeatureExtZbe
: SubtargetFeature<"experimental-zbe", "HasStdExtZbe", "true",
"'Zbe' (Extract-Deposit 'B' Instructions)">;
def HasStdExtZbe : Predicate<"Subtarget->hasStdExtZbe()">,
AssemblerPredicate<(all_of FeatureExtZbe),
"'Zbe' (Extract-Deposit 'B' Instructions)">;
def FeatureExtZbf
: SubtargetFeature<"experimental-zbf", "HasStdExtZbf", "true",
"'Zbf' (Bit-Field 'B' Instructions)">;
def HasStdExtZbf : Predicate<"Subtarget->hasStdExtZbf()">,
AssemblerPredicate<(all_of FeatureExtZbf),
"'Zbf' (Bit-Field 'B' Instructions)">;
def FeatureExtZbm
: SubtargetFeature<"experimental-zbm", "HasStdExtZbm", "true",
"'Zbm' (Matrix 'B' Instructions)">;
def HasStdExtZbm : Predicate<"Subtarget->hasStdExtZbm()">,
AssemblerPredicate<(all_of FeatureExtZbm),
"'Zbm' (Matrix 'B' Instructions)">;
def FeatureExtZbp
: SubtargetFeature<"experimental-zbp", "HasStdExtZbp", "true",
"'Zbp' (Permutation 'B' Instructions)">;
def HasStdExtZbp : Predicate<"Subtarget->hasStdExtZbp()">,
AssemblerPredicate<(all_of FeatureExtZbp),
"'Zbp' (Permutation 'B' Instructions)">;
def FeatureExtZbr
: SubtargetFeature<"experimental-zbr", "HasStdExtZbr", "true",
"'Zbr' (Polynomial Reduction 'B' Instructions)">;
def HasStdExtZbr : Predicate<"Subtarget->hasStdExtZbr()">,
AssemblerPredicate<(all_of FeatureExtZbr),
"'Zbr' (Polynomial Reduction 'B' Instructions)">;
def FeatureExtZbs
: SubtargetFeature<"experimental-zbs", "HasStdExtZbs", "true",
"'Zbs' (Single-Bit 'B' Instructions)">;
def HasStdExtZbs : Predicate<"Subtarget->hasStdExtZbs()">,
AssemblerPredicate<(all_of FeatureExtZbs),
"'Zbs' (Single-Bit 'B' Instructions)">;
def FeatureExtZbt
: SubtargetFeature<"experimental-zbt", "HasStdExtZbt", "true",
"'Zbt' (Ternary 'B' Instructions)">;
def HasStdExtZbt : Predicate<"Subtarget->hasStdExtZbt()">,
AssemblerPredicate<(all_of FeatureExtZbt),
"'Zbt' (Ternary 'B' Instructions)">;
// Some instructions belong to both the basic and the permutation
// subextensions. They should be enabled if either has been specified.
def HasStdExtZbbOrZbp
: Predicate<"Subtarget->hasStdExtZbb() || Subtarget->hasStdExtZbp()">,
AssemblerPredicate<(any_of FeatureExtZbb, FeatureExtZbp)>;
[RISCV] Add isel patterns for using PACK for zext.h and zext.w. Differential Revision: https://reviews.llvm.org/D91024
2020-11-10 02:01:55 +08:00
def NotHasStdExtZbbOrZbp
: Predicate<"!(Subtarget->hasStdExtZbb() || Subtarget->hasStdExtZbp())">;
[RISCV] Add (Proposed) Assembler Extend Pseudo-Instructions There is an in-progress proposal for the following pseudo-instructions in the assembler, to complement the existing `sext.w` rv64i instruction: - sext.b - sext.h - zext.b - zext.h - zext.w The `.b` and `.h` variants are available with rv32i and rv64i, and `zext.w` is only available with `rv64i`. These are implemented primarily as pseudo-instructions, as these instructions expand to multiple real instructions. In the case of `zext.b`, this expands to a single rv32/64i instruction, so it is implemented with an InstAlias (like `sext.w` is on rv64i). The proposal is available here: https://github.com/riscv/riscv-asm-manual/pull/61 Reviewed By: asb Differential Revision: https://reviews.llvm.org/D92793
2020-12-11 03:23:46 +08:00
def NotHasStdExtZbb : Predicate<"!Subtarget->hasStdExtZbb()">;
[RISCV] Add MC layer support for proposed Bit Manipulation extension (version 0.92) This adds the instruction encoding and mnenomics for the proposed RISC-V Bit Manipulation extension (version 0.92). It is implemented with each category of instruction as its own target feature, with the 'b' extension feature enabling all options. Since this extension is not yet ratified, all target features are prefixed with 'experimental-' to note their status. Differential Revision: https://reviews.llvm.org/D65649
2020-04-10 00:51:10 +08:00
def FeatureExtZbproposedc
: SubtargetFeature<"experimental-zbproposedc", "HasStdExtZbproposedc", "true",
"'Zbproposedc' (Proposed Compressed 'B' Instructions)">;
def HasStdExtZbproposedc : Predicate<"Subtarget->hasStdExtZbproposedc()">,
AssemblerPredicate<(all_of FeatureExtZbproposedc),
"'Zbproposedc' (Proposed Compressed 'B' Instructions)">;
def FeatureStdExtB
: SubtargetFeature<"experimental-b", "HasStdExtB", "true",
"'B' (Bit Manipulation Instructions)",
[FeatureExtZbb,
FeatureExtZbc,
FeatureExtZbe,
FeatureExtZbf,
FeatureExtZbm,
FeatureExtZbp,
FeatureExtZbr,
FeatureExtZbs,
FeatureExtZbt]>;
def HasStdExtB : Predicate<"Subtarget->hasStdExtB()">,
AssemblerPredicate<(all_of FeatureStdExtB),
"'B' (Bit Manipulation Instructions)">;
[RISCV] Refactor FeatureRVCHints to make ProcessorModel more intuitive Reviewers: luismarques, asb, evandro Reviewed By: asb, evandro Tags: #llvm Differential Revision: https://reviews.llvm.org/D77030
2020-04-30 18:24:19 +08:00
def FeatureNoRVCHints
: SubtargetFeature<"no-rvc-hints", "EnableRVCHintInstrs", "false",
"Disable RVC Hint Instructions.">;
[RISCV] Add support for RVC HINT instructions The hint instructions are enabled by default (if the standard C extension is enabled). To disable them pass -mattr=-rvc-hints. Differential Revision: https://reviews.llvm.org/D62592 llvm-svn: 369528
2019-08-21 22:00:58 +08:00
def HasRVCHints : Predicate<"Subtarget->enableRVCHintInstrs()">,
[RISCV] Refactor FeatureRVCHints to make ProcessorModel more intuitive Reviewers: luismarques, asb, evandro Reviewed By: asb, evandro Tags: #llvm Differential Revision: https://reviews.llvm.org/D77030
2020-04-30 18:24:19 +08:00
AssemblerPredicate<(all_of(not FeatureNoRVCHints)),
[RISCV] Fix formatting (NFC)
2020-09-26 04:44:44 +08:00
"RVC Hint Instructions">;
[RISCV] MC layer support for load/store instructions of the C (compressed) extension Differential Revision: https://reviews.llvm.org/D40001 Patch by Shiva Chen. llvm-svn: 320037
2017-12-07 20:50:32 +08:00
[RISCV] Assemble/Disassemble v-ext instructions. Assemble/disassemble RISC-V V extension instructions according to latest version spec in https://github.com/riscv/riscv-v-spec/. I have tested this patch using GNU toolchain. The encoding is aligned to GNU assembler output. In this patch, there is a test case for each instruction at least. The V register definition is just for assemble/disassemble. Its type is not important in this stage. I think it will be reviewed and modified as we want to do codegen for scalable vector types. This patch does not include Zvamo, Zvlsseg, and Zvediv. Differential revision: https://reviews.llvm.org/D69987
2019-10-24 12:29:28 +08:00
def FeatureStdExtV
: SubtargetFeature<"experimental-v", "HasStdExtV", "true",
[RISCV] V does not imply F. If users want to use vector floating point instructions, they need to specify 'F' extension additionally. Differential Revision: https://reviews.llvm.org/D93282
2020-12-15 14:59:22 +08:00
"'V' (Vector Instructions)">;
[RISCV] Assemble/Disassemble v-ext instructions. Assemble/disassemble RISC-V V extension instructions according to latest version spec in https://github.com/riscv/riscv-v-spec/. I have tested this patch using GNU toolchain. The encoding is aligned to GNU assembler output. In this patch, there is a test case for each instruction at least. The V register definition is just for assemble/disassemble. Its type is not important in this stage. I think it will be reviewed and modified as we want to do codegen for scalable vector types. This patch does not include Zvamo, Zvlsseg, and Zvediv. Differential revision: https://reviews.llvm.org/D69987
2019-10-24 12:29:28 +08:00
def HasStdExtV : Predicate<"Subtarget->hasStdExtV()">,
AssemblerPredicate<(all_of FeatureStdExtV),
"'V' (Vector Instructions)">;
[RISCV] add the assemble and disassemble support of Zvlsseg instructions This implements the assemble and disassemble support of RISCV Vector extension Zvlsseg instructions, base on the 0.9 spec version. Reviewed by HsiangKai Differential Revision: https://reviews.llvm.org/D84416
2020-07-23 13:45:14 +08:00
def FeatureStdExtZvlsseg
: SubtargetFeature<"experimental-zvlsseg", "HasStdExtZvlsseg", "true",
"'Zvlsseg' (Vector segment load/store instructions)",
[FeatureStdExtV]>;
def HasStdExtZvlsseg : Predicate<"Subtarget->hasStdExtZvlsseg()">,
AssemblerPredicate<(all_of FeatureStdExtZvlsseg),
"'Zvlsseg' (Vector segment load/store instructions)">;
[RISCV] add the MC layer support of riscv vector Zvamo extension Implements the assemble and disassemble support of RISCV Vector extension zvamo instructions, base on the 0.9 spec version. Reviewed by HsiangKai Differential Revision: https://reviews.llvm.org/D85069
2020-07-31 13:03:57 +08:00
def FeatureExtZvamo
: SubtargetFeature<"experimental-zvamo", "HasStdExtZvamo", "true",
"'Zvamo'(Vector AMO Operations)",
[FeatureStdExtV]>;
def HasStdExtZvamo : Predicate<"Subtarget->hasStdExtZvamo()">,
AssemblerPredicate<(all_of FeatureExtZvamo),
"'Zvamo'(Vector AMO Operations)">;
[RISCV] add the assemble and disassemble support of Zvlsseg instructions This implements the assemble and disassemble support of RISCV Vector extension Zvlsseg instructions, base on the 0.9 spec version. Reviewed by HsiangKai Differential Revision: https://reviews.llvm.org/D84416
2020-07-23 13:45:14 +08:00
[RISCV] MC layer support for the standard RV32A instruction set extension llvm-svn: 317791
2017-11-09 23:00:03 +08:00
def Feature64Bit
: SubtargetFeature<"64bit", "HasRV64", "true", "Implements RV64">;
[RISCV] MC layer support for the standard RV64I instructions llvm-svn: 320024
2017-12-07 18:53:48 +08:00
def IsRV64 : Predicate<"Subtarget->is64Bit()">,
[TableGen] Support combining AssemblerPredicates with ORs For context, the proposed RISC-V bit manipulation extension has a subset of instructions which require one of two SubtargetFeatures to be enabled, 'zbb' or 'zbp', and there is no defined feature which both of these can imply to use as a constraint either (see comments in D65649). AssemblerPredicates allow multiple SubtargetFeatures to be declared in the "AssemblerCondString" field, separated by commas, and this means that the two features must both be enabled. There is no equivalent to say that _either_ feature X or feature Y must be enabled, short of creating a dummy SubtargetFeature for this purpose and having features X and Y imply the new feature. To solve the case where X or Y is needed without adding a new feature, and to better match a typical TableGen style, this replaces the existing "AssemblerCondString" with a dag "AssemblerCondDag" which represents the same information. Two operators are defined for use with AssemblerCondDag, "all_of", which matches the current behaviour, and "any_of", which adds the new proposed ORing features functionality. This was originally proposed in the RFC at http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html Changes to all current backends are mechanical to support the replaced functionality, and are NFCI. At this stage, it is illegal to combine features with ands and ors in a single AssemblerCondDag. I suspect this case is sufficiently rare that adding more complex changes to support it are unnecessary. Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
AssemblerPredicate<(all_of Feature64Bit),
[RISCV] Improve assembler missing feature warnings This adds support for printing improved missing feature error messages from the assembler, which now indicates which feature caused the parse to fail. Differential Revision: https://reviews.llvm.org/D69899
2019-12-11 00:44:48 +08:00
"RV64I Base Instruction Set">;
[RISCV] Implement assembler pseudo instructions for RV32I and RV64I Adds the assembler pseudo instructions of RV32I and RV64I which can be mapped to a single canonical instruction. The missing pseudo instructions (e.g., call, tail, ...) are marked as TODO. Other things, like for example PCREL_LO, have to be implemented first. Currently, alias emission is disabled by default to keep the patch minimal. Alias emission by default will be enabled in a subsequent patch which also updates all affected tests. Note that this patch should actually break the floating point MC tests. However, the used FileCheck configuration is not tight enought to detect the breakage. Differential Revision: https://reviews.llvm.org/D40902 Patch by Mario Werner. llvm-svn: 320487
2017-12-12 23:46:15 +08:00
def IsRV32 : Predicate<"!Subtarget->is64Bit()">,
[TableGen] Support combining AssemblerPredicates with ORs For context, the proposed RISC-V bit manipulation extension has a subset of instructions which require one of two SubtargetFeatures to be enabled, 'zbb' or 'zbp', and there is no defined feature which both of these can imply to use as a constraint either (see comments in D65649). AssemblerPredicates allow multiple SubtargetFeatures to be declared in the "AssemblerCondString" field, separated by commas, and this means that the two features must both be enabled. There is no equivalent to say that _either_ feature X or feature Y must be enabled, short of creating a dummy SubtargetFeature for this purpose and having features X and Y imply the new feature. To solve the case where X or Y is needed without adding a new feature, and to better match a typical TableGen style, this replaces the existing "AssemblerCondString" with a dag "AssemblerCondDag" which represents the same information. Two operators are defined for use with AssemblerCondDag, "all_of", which matches the current behaviour, and "any_of", which adds the new proposed ORing features functionality. This was originally proposed in the RFC at http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html Changes to all current backends are mechanical to support the replaced functionality, and are NFCI. At this stage, it is illegal to combine features with ands and ors in a single AssemblerCondDag. I suspect this case is sufficiently rare that adding more complex changes to support it are unnecessary. Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
AssemblerPredicate<(all_of (not Feature64Bit)),
[RISCV] Improve assembler missing feature warnings This adds support for printing improved missing feature error messages from the assembler, which now indicates which feature caused the parse to fail. Differential Revision: https://reviews.llvm.org/D69899
2019-12-11 00:44:48 +08:00
"RV32I Base Instruction Set">;
[RISCV] MC layer support for the standard RV32M instruction set extension llvm-svn: 317788
2017-11-09 22:46:30 +08:00
[RISCV] Remove RV32 HwMode. Use DefaultMode for RV32 Prior to this the DefaultMode was never selected, but RISCVGenDAGISel.inc, RISCVGenRegisterInfo.inc, RISCVGenGlobalISel.inc all ended up with extra table entries for that mode. This patch removes the RV32 and uses DefaultMode for RV32. This impressively reduces the size of my release+asserts llc binary by about 270K. About 15K from RISCVGenDAGISel.inc, 1-2K from RISCVGenRegisterInfo.inc, but the vast majority from RISCVGenGlobalISel.inc. Differential Revision: https://reviews.llvm.org/D90973
2020-11-21 02:42:51 +08:00
defvar RV32 = DefaultMode;
[RISCV] MC layer support for the standard RV32M instruction set extension llvm-svn: 317788
2017-11-09 22:46:30 +08:00
def RV64 : HwMode<"+64bit">;
[RISCV] Prepare for the use of variable-sized register classes While parameterising by XLen, also take the opportunity to clean up the formatting of the RISCV .td files. This commit unifies the in-tree code with my patchset at <https://github.com/lowrisc/riscv-llvm>. llvm-svn: 316159
2017-10-19 22:29:03 +08:00
[RISCV] Add basic RV32E definitions and MC layer support The RISC-V ISA defines RV32E as an alternative "base" instruction set encoding, that differs from RV32I by having only 16 rather than 32 registers. This patch adds basic definitions for RV32E as well as MC layer support (assembling, disassembling) and tests. The only supported ABI on RV32E is ILP32E. Add a new RISCVFeatures::validate() helper to RISCVUtils which can be called from codegen or MC layer libraries to validate the combination of TargetTriple and FeatureBitSet. Other targets have similar checks (e.g. erroring if SPE is enabled on PPC64 or oddspreg + o32 ABI on Mips), but they either duplicate the checks (Mips), or fail to check for both codegen and MC codepaths (PPC). Codegen for the ILP32E ABI support and RV32E codegen are left for a future patch/patches. Differential Revision: https://reviews.llvm.org/D59470 llvm-svn: 356744
2019-03-22 19:21:40 +08:00
def FeatureRV32E
: SubtargetFeature<"e", "IsRV32E", "true",
"Implements RV32E (provides 16 rather than 32 GPRs)">;
def IsRV32E : Predicate<"Subtarget->isRV32E()">,
[TableGen] Support combining AssemblerPredicates with ORs For context, the proposed RISC-V bit manipulation extension has a subset of instructions which require one of two SubtargetFeatures to be enabled, 'zbb' or 'zbp', and there is no defined feature which both of these can imply to use as a constraint either (see comments in D65649). AssemblerPredicates allow multiple SubtargetFeatures to be declared in the "AssemblerCondString" field, separated by commas, and this means that the two features must both be enabled. There is no equivalent to say that _either_ feature X or feature Y must be enabled, short of creating a dummy SubtargetFeature for this purpose and having features X and Y imply the new feature. To solve the case where X or Y is needed without adding a new feature, and to better match a typical TableGen style, this replaces the existing "AssemblerCondString" with a dag "AssemblerCondDag" which represents the same information. Two operators are defined for use with AssemblerCondDag, "all_of", which matches the current behaviour, and "any_of", which adds the new proposed ORing features functionality. This was originally proposed in the RFC at http://lists.llvm.org/pipermail/llvm-dev/2020-February/139138.html Changes to all current backends are mechanical to support the replaced functionality, and are NFCI. At this stage, it is illegal to combine features with ands and ors in a single AssemblerCondDag. I suspect this case is sufficiently rare that adding more complex changes to support it are unnecessary. Differential Revision: https://reviews.llvm.org/D74338
2020-03-14 01:13:51 +08:00
AssemblerPredicate<(all_of FeatureRV32E)>;
[RISCV] Add basic RV32E definitions and MC layer support The RISC-V ISA defines RV32E as an alternative "base" instruction set encoding, that differs from RV32I by having only 16 rather than 32 registers. This patch adds basic definitions for RV32E as well as MC layer support (assembling, disassembling) and tests. The only supported ABI on RV32E is ILP32E. Add a new RISCVFeatures::validate() helper to RISCVUtils which can be called from codegen or MC layer libraries to validate the combination of TargetTriple and FeatureBitSet. Other targets have similar checks (e.g. erroring if SPE is enabled on PPC64 or oddspreg + o32 ABI on Mips), but they either duplicate the checks (Mips), or fail to check for both codegen and MC codepaths (PPC). Codegen for the ILP32E ABI support and RV32E codegen are left for a future patch/patches. Differential Revision: https://reviews.llvm.org/D59470 llvm-svn: 356744
2019-03-22 19:21:40 +08:00
[RISCV] Define FeatureRelax and shouldForceRelocation for RISCV linker relaxation 1. Deine FeatureRelax to enable/disable linker relaxation. 2. Define shouldForceRelocation to preserve relocation types even if the fixup can be resolved when linker relaxation enabled. This is necessary for correctness as offsets may change during relaxation. Differential Revision: https://reviews.llvm.org/D46674 llvm-svn: 332318
2018-05-15 09:28:50 +08:00
def FeatureRelax
: SubtargetFeature<"relax", "EnableLinkerRelax", "true",
"Enable Linker relaxation.">;
[RISCV] Add support for -ffixed-xX flags This adds support for reserving GPRs such that the compiler will not choose a register for register allocation. The implementation follows the same design as for AArch64; each reserved register becomes a target feature and used for getting the reserved registers for a given MachineFunction. The backend checks that it does not need to write to any reserved register; if it does a relevant error is generated. Differential Revision: https://reviews.llvm.org/D67185
2019-10-23 04:25:01 +08:00
foreach i = {1-31} in
def FeatureReserveX#i :
SubtargetFeature<"reserve-x"#i, "UserReservedRegister[RISCV::X"#i#"]",
"true", "Reserve X"#i>;
[RISCV] Add support for save/restore of callee-saved registers via libcalls This patch adds the support required for using the __riscv_save and __riscv_restore libcalls to implement a size-optimization for prologue and epilogue code, whereby the spill and restore code of callee-saved registers is implemented by common functions to reduce code duplication. Logic is also included to ensure that if both this optimization and shrink wrapping are enabled then the prologue and epilogue code can be safely inserted into the basic blocks chosen by shrink wrapping. Differential Revision: https://reviews.llvm.org/D62686
2020-02-12 05:23:03 +08:00
def FeatureSaveRestore : SubtargetFeature<"save-restore", "EnableSaveRestore",
"true", "Enable save/restore.">;
[RISCV] Prepare for the use of variable-sized register classes While parameterising by XLen, also take the opportunity to clean up the formatting of the RISCV .td files. This commit unifies the in-tree code with my patchset at <https://github.com/lowrisc/riscv-llvm>. llvm-svn: 316159
2017-10-19 22:29:03 +08:00
//===----------------------------------------------------------------------===//
[RISCV][NFC] Replace hard-coded CSR duplication with symbolic references Reviewers: asb, lenary Reviewed By: asb, lenary Subscribers: MaskRay, hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64139 Patch by James Clarke (jrtc27) llvm-svn: 365195
2019-07-05 20:16:40 +08:00
// Named operands for CSR instructions.
[RISCV] Prepare for the use of variable-sized register classes While parameterising by XLen, also take the opportunity to clean up the formatting of the RISCV .td files. This commit unifies the in-tree code with my patchset at <https://github.com/lowrisc/riscv-llvm>. llvm-svn: 316159
2017-10-19 22:29:03 +08:00
//===----------------------------------------------------------------------===//
[RISCV][NFC] Replace hard-coded CSR duplication with symbolic references Reviewers: asb, lenary Reviewed By: asb, lenary Subscribers: MaskRay, hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64139 Patch by James Clarke (jrtc27) llvm-svn: 365195
2019-07-05 20:16:40 +08:00
include "RISCVSystemOperands.td"
[RISCV 4/10] Add basic RISCV{InstrFormats,InstrInfo,RegisterInfo,}.td For now, only add instruction definitions for basic ALU operations. Our initial target is a working MC layer rather than codegen, so appropriate SelectionDAG patterns will come later. Differential Revision: https://reviews.llvm.org/D23561 llvm-svn: 285769
2016-11-02 07:40:28 +08:00
[RISCV] Support named operands for CSR instructions. Reviewers: asb, mgrang Reviewed By: asb Subscribers: jocewei, mgorny, jfb, PkmX, MartinMosbeck, brucehoult, the_o, rkruppe, rogfer01, rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones Differential Revision: https://reviews.llvm.org/D46759 llvm-svn: 343822
2018-10-05 05:50:54 +08:00
//===----------------------------------------------------------------------===//
[RISCV][NFC] Replace hard-coded CSR duplication with symbolic references Reviewers: asb, lenary Reviewed By: asb, lenary Subscribers: MaskRay, hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64139 Patch by James Clarke (jrtc27) llvm-svn: 365195
2019-07-05 20:16:40 +08:00
// Registers, calling conventions, instruction descriptions.
[RISCV] Support named operands for CSR instructions. Reviewers: asb, mgrang Reviewed By: asb Subscribers: jocewei, mgorny, jfb, PkmX, MartinMosbeck, brucehoult, the_o, rkruppe, rogfer01, rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones Differential Revision: https://reviews.llvm.org/D46759 llvm-svn: 343822
2018-10-05 05:50:54 +08:00
//===----------------------------------------------------------------------===//
[RISCV] Scheduler description for the Rocket core Pipeline scheduler model for the RISC-V Rocket micro-architecture using the MIScheduler interface. Support for both 32 and 64-bit Rocket cores is implemented. Differential revision: https://reviews.llvm.org/D68685
2020-01-24 04:51:04 +08:00
include "RISCVSchedule.td"
[RISCV][NFC] Replace hard-coded CSR duplication with symbolic references Reviewers: asb, lenary Reviewed By: asb, lenary Subscribers: MaskRay, hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64139 Patch by James Clarke (jrtc27) llvm-svn: 365195
2019-07-05 20:16:40 +08:00
include "RISCVRegisterInfo.td"
include "RISCVCallingConv.td"
include "RISCVInstrInfo.td"
[RISCV GlobalISel] Adding initial GlobalISel infrastructure Summary: Add an initial GlobalISel skeleton for RISCV. It can only run ir translator for `ret void`. Patch by Andrew Wei Reviewers: asb, sabuasal, apazos, lenary, simoncook, lewis-revill, edward-jones, rogfer01, xiangzhai, rovka, Petar.Avramovic, mgorny, dsanders Reviewed By: dsanders Subscribers: pzheng, s.egerton, dsanders, hiraditya, rbar, johnrusso, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, psnobl, benna, Jim, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65219 llvm-svn: 369467
2019-08-21 06:53:24 +08:00
include "RISCVRegisterBanks.td"
[RISCV] Merge the pipeline models for Rocket Merge the 32 and 64 bit pipeline models for Rocket into a single file. Differential Revision: https://reviews.llvm.org/D87873
2020-09-18 07:20:50 +08:00
include "RISCVSchedRocket.td"
[RISCV] Use the commercial name for scheduling model (NFC) Use the commercial name for the scheduling model for the SiFive 7 Series.
2020-10-09 05:20:24 +08:00
include "RISCVSchedSiFive7.td"
[RISCV] Support named operands for CSR instructions. Reviewers: asb, mgrang Reviewed By: asb Subscribers: jocewei, mgorny, jfb, PkmX, MartinMosbeck, brucehoult, the_o, rkruppe, rogfer01, rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones Differential Revision: https://reviews.llvm.org/D46759 llvm-svn: 343822
2018-10-05 05:50:54 +08:00
[RISCV] Prepare for the use of variable-sized register classes While parameterising by XLen, also take the opportunity to clean up the formatting of the RISCV .td files. This commit unifies the in-tree code with my patchset at <https://github.com/lowrisc/riscv-llvm>. llvm-svn: 316159
2017-10-19 22:29:03 +08:00
//===----------------------------------------------------------------------===//
// RISC-V processors supported.
//===----------------------------------------------------------------------===//
[RISCV 4/10] Add basic RISCV{InstrFormats,InstrInfo,RegisterInfo,}.td For now, only add instruction definitions for basic ALU operations. Our initial target is a working MC layer rather than codegen, so appropriate SelectionDAG patterns will come later. Differential Revision: https://reviews.llvm.org/D23561 llvm-svn: 285769
2016-11-02 07:40:28 +08:00
[RISCV] Refactor FeatureRVCHints to make ProcessorModel more intuitive Reviewers: luismarques, asb, evandro Reviewed By: asb, evandro Tags: #llvm Differential Revision: https://reviews.llvm.org/D77030
2020-04-30 18:24:19 +08:00
def : ProcessorModel<"generic-rv32", NoSchedModel, []>;
def : ProcessorModel<"generic-rv64", NoSchedModel, [Feature64Bit]>;
[RISCV 4/10] Add basic RISCV{InstrFormats,InstrInfo,RegisterInfo,}.td For now, only add instruction definitions for basic ALU operations. Our initial target is a working MC layer rather than codegen, so appropriate SelectionDAG patterns will come later. Differential Revision: https://reviews.llvm.org/D23561 llvm-svn: 285769
2016-11-02 07:40:28 +08:00
[RISCV] Merge the pipeline models for Rocket Merge the 32 and 64 bit pipeline models for Rocket into a single file. Differential Revision: https://reviews.llvm.org/D87873
2020-09-18 07:20:50 +08:00
def : ProcessorModel<"rocket-rv32", RocketModel, []>;
def : ProcessorModel<"rocket-rv64", RocketModel, [Feature64Bit]>;
[RISCV] Scheduler description for the Rocket core Pipeline scheduler model for the RISC-V Rocket micro-architecture using the MIScheduler interface. Support for both 32 and 64-bit Rocket cores is implemented. Differential revision: https://reviews.llvm.org/D68685
2020-01-24 04:51:04 +08:00
[RISCV] Use the commercial name for scheduling model (NFC) Use the commercial name for the scheduling model for the SiFive 7 Series.
2020-10-09 05:20:24 +08:00
def : ProcessorModel<"sifive-7-rv32", SiFive7Model, []>;
def : ProcessorModel<"sifive-7-rv64", SiFive7Model, [Feature64Bit]>;
[RISCV] Scheduler description for Bullet Add the pipeline model for the RISC-V Bullet micro architecture. Co-authored-by: Evandro Menezes <evandro.menezes@sifive.com>
2020-09-26 06:59:08 +08:00
[RISCV] Use the extensions in the canonical order (NFC) Use the ISA extensions for specific processors in the conventional canonical order.
2020-09-30 06:11:12 +08:00
def : ProcessorModel<"sifive-e31", RocketModel, [FeatureStdExtM,
FeatureStdExtA,
FeatureStdExtC]>;
[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-17 01:32:01 +08:00
[RISCV] Merge the pipeline models for Rocket Merge the 32 and 64 bit pipeline models for Rocket into a single file. Differential Revision: https://reviews.llvm.org/D87873
2020-09-18 07:20:50 +08:00
def : ProcessorModel<"sifive-u54", RocketModel, [Feature64Bit,
[RISCV] Use the extensions in the canonical order (NFC) Use the ISA extensions for specific processors in the conventional canonical order.
2020-09-30 06:11:12 +08:00
FeatureStdExtM,
[RISCV] Merge the pipeline models for Rocket Merge the 32 and 64 bit pipeline models for Rocket into a single file. Differential Revision: https://reviews.llvm.org/D87873
2020-09-18 07:20:50 +08:00
FeatureStdExtA,
[RISCV] Use the extensions in the canonical order (NFC) Fix a mistake in the ordering.
2020-10-03 05:26:49 +08:00
FeatureStdExtF,
[RISCV] Merge the pipeline models for Rocket Merge the 32 and 64 bit pipeline models for Rocket into a single file. Differential Revision: https://reviews.llvm.org/D87873
2020-09-18 07:20:50 +08:00
FeatureStdExtD,
[RISCV] Use the extensions in the canonical order (NFC) Use the ISA extensions for specific processors in the conventional canonical order.
2020-09-30 06:11:12 +08:00
FeatureStdExtC]>;
[RISCV] Scheduler description for the Rocket core Pipeline scheduler model for the RISC-V Rocket micro-architecture using the MIScheduler interface. Support for both 32 and 64-bit Rocket cores is implemented. Differential revision: https://reviews.llvm.org/D68685
2020-01-24 04:51:04 +08:00
[RISCV] Use the commercial name for scheduling model (NFC) Use the commercial name for the scheduling model for the SiFive 7 Series.
2020-10-09 05:20:24 +08:00
def : ProcessorModel<"sifive-e76", SiFive7Model, [FeatureStdExtM,
FeatureStdExtA,
FeatureStdExtF,
FeatureStdExtC]>;
def : ProcessorModel<"sifive-u74", SiFive7Model, [Feature64Bit,
FeatureStdExtM,
FeatureStdExtA,
FeatureStdExtF,
FeatureStdExtD,
FeatureStdExtC]>;
[RISCV] Add SiFive cores to the CPU option Add the SiFive cores E76 and U74 using the SiFive 7 series microarchitecture. Differential Revision: https://reviews.llvm.org/D88759
2020-10-03 05:44:32 +08:00
[RISCV] Prepare for the use of variable-sized register classes While parameterising by XLen, also take the opportunity to clean up the formatting of the RISCV .td files. This commit unifies the in-tree code with my patchset at <https://github.com/lowrisc/riscv-llvm>. llvm-svn: 316159
2017-10-19 22:29:03 +08:00
//===----------------------------------------------------------------------===//
// Define the RISC-V target.
//===----------------------------------------------------------------------===//
[RISCV] Initial codegen support for ALU operations This adds the minimum necessary to support codegen for simple ALU operations on RV32. Prolog and epilog insertion, support for memory operations etc etc follow in future patches. Leave guessInstructionProperties=1 until https://reviews.llvm.org/D37065 is reviewed and lands. Differential Revision: https://reviews.llvm.org/D29933 llvm-svn: 316188
2017-10-20 05:37:38 +08:00
def RISCVInstrInfo : InstrInfo {
[NFCI] Ensure TargetOpcode::* are compatible with guessInstructionProperties=0 rL162640 introduced CodeGenTarget::guessInstructionProperties. If a target sets guessInstructionProperties=0 in its FooInstrInfo, tablegen will error if it has to guess properties from patterns. Unfortunately, guessInstructionProperties=0 can't be used with current upstream LLVM as instructions in the TargetOpcode namespace are always included and sometimes have inferred properties for mayLoad, mayStore, and hasSideEffects. This patch provides the simplest possible fix to this problem, setting default values for these fields in the TargetOpcode scope. There is no intended functional change, as the explicitly set properties should match what was previously inferred. A number of the instructions had hasSideEffects=1 inferred unintentionally. This patch makes it explicit, while future patches (such as D37097) correct the property. Differential Revision: https://reviews.llvm.org/D37065 llvm-svn: 317674
2017-11-08 17:26:06 +08:00
let guessInstructionProperties = 0;
[RISCV] Initial codegen support for ALU operations This adds the minimum necessary to support codegen for simple ALU operations on RV32. Prolog and epilog insertion, support for memory operations etc etc follow in future patches. Leave guessInstructionProperties=1 until https://reviews.llvm.org/D37065 is reviewed and lands. Differential Revision: https://reviews.llvm.org/D29933 llvm-svn: 316188
2017-10-20 05:37:38 +08:00
}
[RISCV] Prepare for the use of variable-sized register classes While parameterising by XLen, also take the opportunity to clean up the formatting of the RISCV .td files. This commit unifies the in-tree code with my patchset at <https://github.com/lowrisc/riscv-llvm>. llvm-svn: 316159
2017-10-19 22:29:03 +08:00
[RISCV] Add basic RISCVAsmParser This doesn't yet support parsing things like %pcrel_hi(foo), but will handle basic instructions with register or immediate operands. Differential Revision: https://reviews.llvm.org/D23563 llvm-svn: 310361
2017-08-08 22:32:35 +08:00
def RISCVAsmParser : AsmParser {
let ShouldEmitMatchRegisterAltName = 1;
[RISCV] MC layer support for the standard RV32D instruction set extension As the FPR32 and FPR64 registers have the same names, use validateTargetOperandClass in RISCVAsmParser to coerce a parsed FPR32 to an FPR64 when necessary. The rest of this patch is very similar to the RV32F patch. Differential Revision: https://reviews.llvm.org/D39895 llvm-svn: 320023
2017-12-07 18:46:23 +08:00
let AllowDuplicateRegisterNames = 1;
[RISCV] Add basic RISCVAsmParser This doesn't yet support parsing things like %pcrel_hi(foo), but will handle basic instructions with register or immediate operands. Differential Revision: https://reviews.llvm.org/D23563 llvm-svn: 310361
2017-08-08 22:32:35 +08:00
}
[RISCV] Pass MCSubtargetInfo to print methods. Summary: This change allows checking for ISA extensions in print methods. Reviewers: asb, niosHD Reviewed By: asb, niosHD Subscribers: llvm-commits, niosHD, asb, rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal Differential Revision: https://reviews.llvm.org/D41503 llvm-svn: 322345
2018-01-12 10:27:00 +08:00
def RISCVAsmWriter : AsmWriter {
int PassSubtarget = 1;
}
[RISCV 4/10] Add basic RISCV{InstrFormats,InstrInfo,RegisterInfo,}.td For now, only add instruction definitions for basic ALU operations. Our initial target is a working MC layer rather than codegen, so appropriate SelectionDAG patterns will come later. Differential Revision: https://reviews.llvm.org/D23561 llvm-svn: 285769
2016-11-02 07:40:28 +08:00
def RISCV : Target {
let InstructionSet = RISCVInstrInfo;
[RISCV] Add basic RISCVAsmParser This doesn't yet support parsing things like %pcrel_hi(foo), but will handle basic instructions with register or immediate operands. Differential Revision: https://reviews.llvm.org/D23563 llvm-svn: 310361
2017-08-08 22:32:35 +08:00
let AssemblyParsers = [RISCVAsmParser];
[RISCV] Pass MCSubtargetInfo to print methods. Summary: This change allows checking for ISA extensions in print methods. Reviewers: asb, niosHD Reviewed By: asb, niosHD Subscribers: llvm-commits, niosHD, asb, rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal Differential Revision: https://reviews.llvm.org/D41503 llvm-svn: 322345
2018-01-12 10:27:00 +08:00
let AssemblyWriters = [RISCVAsmWriter];
[MachineOperand][Target] MachineOperand::isRenamable semantics changes Summary: Add a target option AllowRegisterRenaming that is used to opt in to post-register-allocation renaming of registers. This is set to 0 by default, which causes the hasExtraSrcRegAllocReq/hasExtraDstRegAllocReq fields of all opcodes to be set to 1, causing MachineOperand::isRenamable to always return false. Set the AllowRegisterRenaming flag to 1 for all in-tree targets that have lit tests that were effected by enabling COPY forwarding in MachineCopyPropagation (AArch64, AMDGPU, ARM, Hexagon, Mips, PowerPC, RISCV, Sparc, SystemZ and X86). Add some more comments describing the semantics of the MachineOperand::isRenamable function and how it is set and maintained. Change isRenamable to check the operand's opcode hasExtraSrcRegAllocReq/hasExtraDstRegAllocReq bit directly instead of relying on it being consistently reflected in the IsRenamable bit setting. Clear the IsRenamable bit when changing an operand's register value. Remove target code that was clearing the IsRenamable bit when changing registers/opcodes now that this is done conservatively by default. Change setting of hasExtraSrcRegAllocReq in AMDGPU target to be done in one place covering all opcodes that have constant pipe read limit restrictions. Reviewers: qcolombet, MatzeB Subscribers: aemerson, arsenm, jyknight, mcrosier, sdardis, nhaehnle, javed.absar, tpr, arichardson, kristof.beyls, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, jordy.potman.lists, apazos, sabuasal, niosHD, escha, nemanjai, llvm-commits Differential Revision: https://reviews.llvm.org/D43042 llvm-svn: 325931
2018-02-24 02:25:08 +08:00
let AllowRegisterRenaming = 1;
[RISCV 4/10] Add basic RISCV{InstrFormats,InstrInfo,RegisterInfo,}.td For now, only add instruction definitions for basic ALU operations. Our initial target is a working MC layer rather than codegen, so appropriate SelectionDAG patterns will come later. Differential Revision: https://reviews.llvm.org/D23561 llvm-svn: 285769
2016-11-02 07:40:28 +08:00
}