Implement XCVsimd intrinsics for CV32E40P according to the specification.
This commit is part of a patch-set to upstream the 7 vendor specific extensions of CV32E40P.
Contributors: @CharKeaney, @jeremybennett, @lewis-revill, @liaolucy, Nandni Jamnadas, @PaoloS, @simoncook, @xmj.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D153721
Implement XCValu intrinsics for CV32E40P according to the specification.
This is a commit of the patch-set to upstream the 7 vendor specific extensions of CV32E40P.
Contributors: @CharKeaney, Nandni Jamnadas, Serkan Muhcu, @jeremybennett, @lewis-revill, @liaolucy, @simoncook, @xmj
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D153748
Implement XCVmac intrinsics for CV32E40P according to the specification.
This is the first commit of a patch-set to upstream the 7 vendor specific extensions of CV32E40P.
The patch-set aims at upstreaming the extensions on MC. The following will be on CodeGen, and the final patch-set will be on builtins if possible. The implemented version is on [0].
Contributors: @CharKeaney, Serkan Muhcu, @jeremybennett, @lewis-revill, @liaolucy, @simoncook, @xmj
Spec: 62bec66b36/docs/source/instruction_set_extensions.rst
[0] https://github.com/openhwgroup/corev-llvm-project
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D152821
Implement XCVbitmanip intrinsics for CV32E40P according to the specification.
This commit is part of a patch-set to upstream the 7 vendor specific extensions of CV32E40P.
Contributors: @CharKeaney, @jeremybennett, @lewis-revill, @liaolucy, @simoncook, @xmj.
Spec: 62bec66b36/docs/source/instruction_set_extensions.rst
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D152915
The decoding parts are reduplicative, we add a macro to simplify
the code.
Reviewed By: craig.topper, kito-cheng
Differential Revision: https://reviews.llvm.org/D151309
Previously we added the SP operands when an immediate operand was added
to certain opcodes.
This patch moves it to a post processing step using the information
in MCInstrDesc. This avoids an explicit opcode list in RISCVDisassembler.cpp.
In considered using a custom DecoderMethod, but the bit swizzling we
need to do for the immediates on these instructions made that
unattractive.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D149931
This patch add the instructions of zcmp extension.
Instructions in zcmp extension try to optimise `mv` inst and the prologue & epilogue in functions
co-author: @Scott Egerton, @ZirconLiu, @Lukacma, @Heda Chen, @luxufan, @heyiliang, @liaochunyu
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D132819
The Zcmt instructions overlap encoding space with some C extension
instructions. Isolate to a separate namespace.
Reviewed By: VincentWu
Differential Revision: https://reviews.llvm.org/D149891
Rather than using operator[] on getFeatureBits we can use
hasFeature to shorten the code.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D144300
For 4 byte instructions we were always setting size to 4 eventually. Same
for 2 byte instructions. So do it as soon as we know the from the opcode.
Add a return to the end of the 4 byte code so we don't have to have an else
around the 2 byte code.
Differential Revision: https://reviews.llvm.org/D143445
As we prepare the tree to add more vendor-defined extensions that are
originating with T-Head, the debug message announcing the XTheadVdot
decoder namespace should refer to XTHeadVdot instead of all T-Head
custom extensions.
The tablegen generated code is templated based on the type of Insn
passed to decodeInstruction which is currently uint32_t. All of the
fields extracted will this type.
This change provides an implementation of the XVentanaCondOps vendor extension. This extension is defined in version 1.0.0 of the VTx-family custom instructions specification (https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf) by Ventana Micro Systems.
In addition to the technical contribution, this change is intended to be a test case for our vendor extension policy.
Once this lands, I plan to use this extension to prototype selection lowering to conditional moves. There's an RVI proposal in flight, and the expectation is that lowering to these and the new RVI instructions is likely to be substantially similar.
Differential Revision: https://reviews.llvm.org/D137350
The name `MCFixedLenDisassembler.h` is out of date after D120958.
Rename it as `MCDecoderOps.h` to reflect the change.
Reviewed By: myhsu
Differential Revision: https://reviews.llvm.org/D124987
All LLVM backends use MCDisassembler as a base class for their
instruction decoders. Use "const MCDisassembler *" for the decoder
instead of "const void *". Remove unnecessary static casts.
Reviewed By: skan
Differential Revision: https://reviews.llvm.org/D122245
This patch added the MC layer support of Zfinx extension.
Authored-by: StephenFan
Co-Authored-by: Shao-Ce Sun
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D93298
This reverts commit 7798ecca9c3db42241169d31fea4fb820ed01830.
As reported in https://reviews.llvm.org/D93298#3331641 and
following, this causes assertion failures with inline assembly.
This patch added the MC layer support of Zfinx extension.
Authored-by: StephenFan
Co-Authored-by: Shao-Ce Sun
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D93298
This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually use the target, so we might as well move this out of Support.
This allows us to ensure that Support doesn't have includes from MC/*.
Differential Revision: https://reviews.llvm.org/D111454
This consists of 3 compressed instructions, c.not, c.neg, and c.zext.w.
I believe these have been picked up by the Zce effort using different
encodings. I don't think it makes sense to keep them in bitmanip. It
will eventually cause a conflict if/when Zce is implemented in llvm.
Differential Revision: https://reviews.llvm.org/D110871
Rename prefix `FeatureExt*` to `FeatureStdExt*` for all sub-extension for consistency
Reviewed By: HsiangKai, asb
Differential Revision: https://reviews.llvm.org/D108187
In vector v0.10, there are whole vector register load/store
instructions. I suggest to use the whole register load/store
instructions for generic load/store for scalable vector types. It could
save up vset{i}vl{i} for these load/store.
For fractional LMUL, I keep to use vle{eew}.v/vse{eew}.v instructions to
load/store partial vector registers.
Differential Revision: https://reviews.llvm.org/D95853
MCTargetDesc includes headers from Utils and Utils includes headers
from MCTargetDesc. So from a library layering perspective it makes sense
for them to be in the same library. I guess the other option might be to
move the tablegen includes from RISCVMCTargetDesc.h to RISCVBaseInfo.h
so that RISCVBaseInfo.h didn't need to include RISCVMCTargetDesc.h.
Everything else that depends on Utils also depends on MCTargetDesc so
having one library seemed simpler.
Differential Revision: https://reviews.llvm.org/D93168
-Use MCRegister instead of Register in MC layer.
-Move some enums from RISCVInstrInfo.h to RISCVBaseInfo.h to be with other TSFlags bits.
Differential Revision: https://reviews.llvm.org/D91114
