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/ARM/ARMInstrVFP.td

2479 lines
96 KiB
TableGen
Raw Normal View History

Emacs-tag and some comment fix for all ARM, CellSPU, Hexagon, MBlaze, MSP430, PPC, PTX, Sparc, X86, XCore. llvm-svn: 150878
2012-02-18 20:03:15 +08:00
//===-- ARMInstrVFP.td - VFP support for ARM ---------------*- tablegen -*-===//
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
//
// The LLVM Compiler Infrastructure
//
Remove attribution from file headers, per discussion on llvmdev. llvm-svn: 45418
2007-12-30 04:36:04 +08:00
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
//
//===----------------------------------------------------------------------===//
//
udpate header comment: s/VP/VFP/ llvm-svn: 56126
2008-09-12 05:41:29 +08:00
// This file describes the ARM VFP instruction set.
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
//
//===----------------------------------------------------------------------===//
[ARM] Use VCMP, not VCMPE, for floating point equality comparisons When generating a floating point comparison we currently unconditionally generate VCMPE. This has the sideeffect of setting the cumulative Invalid bit in FPSCR if any of the operands are QNaN. It is expected that use of a relational predicate on a QNaN value should raise Invalid. Quoting from the C standard: The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of relationships the less, greater, equal and is true. Relational operators may raise the floating-point exception when argument values are NaNs. The standard doesn't explicitly state the expectation for equality operators, but the implication and obvious expectation is that equality operators should not raise Invalid on a QNaN input, as those predicates are wholly defined on unordered inputs (to return not equal). Therefore, add a new operand to ARMISD::FPCMP and FPCMPZ indicating if QNaN should raise Invalid, and pipe that through to TableGen. llvm-svn: 294945
2017-02-13 20:32:47 +08:00
def SDT_CMPFP0 : SDTypeProfile<0, 2, [SDTCisFP<0>, SDTCisVT<1, i32>]>;
Reformatting. No functionalogicality changes. llvm-svn: 116625
2010-10-16 05:50:45 +08:00
def SDT_VMOVDRR : SDTypeProfile<1, 2, [SDTCisVT<0, f64>, SDTCisVT<1, i32>,
SDTCisSameAs<1, 2>]>;
[ARM] Replace some C++ selection code with TableGen patterns. NFC. Differential Revision: https://reviews.llvm.org/D30794 llvm-svn: 297768
2017-03-15 02:43:37 +08:00
def SDT_VMOVRRD : SDTypeProfile<2, 1, [SDTCisVT<0, i32>, SDTCisSameAs<0, 1>,
SDTCisVT<2, f64>]>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
[ARM] Support float literals under XO When targeting execute-only and fp-armv8, float constants in a compare resulted in instruction selection failures. This is now fixed by using vmov.f32 where possible, otherwise the floating point constant is lowered into a integer constant that is moved into a floating point register. This patch also restores using fpcmp with immediate 0 under fp-armv8. Change-Id: Ie87229706f4ed879a0c0cf66631b6047ed6c6443 llvm-svn: 328313
2018-03-23 21:02:03 +08:00
def SDT_VMOVSR : SDTypeProfile<1, 1, [SDTCisVT<0, f32>, SDTCisVT<1, i32>]>;
Flag -> Glue, the ongoing saga llvm-svn: 122513
2010-12-24 02:28:41 +08:00
def arm_fmstat : SDNode<"ARMISD::FMSTAT", SDTNone, [SDNPInGlue, SDNPOutGlue]>;
[ARM] Use VCMP, not VCMPE, for floating point equality comparisons When generating a floating point comparison we currently unconditionally generate VCMPE. This has the sideeffect of setting the cumulative Invalid bit in FPSCR if any of the operands are QNaN. It is expected that use of a relational predicate on a QNaN value should raise Invalid. Quoting from the C standard: The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of relationships the less, greater, equal and is true. Relational operators may raise the floating-point exception when argument values are NaNs. The standard doesn't explicitly state the expectation for equality operators, but the implication and obvious expectation is that equality operators should not raise Invalid on a QNaN input, as those predicates are wholly defined on unordered inputs (to return not equal). Therefore, add a new operand to ARMISD::FPCMP and FPCMPZ indicating if QNaN should raise Invalid, and pipe that through to TableGen. llvm-svn: 294945
2017-02-13 20:32:47 +08:00
def arm_cmpfp : SDNode<"ARMISD::CMPFP", SDT_ARMFCmp, [SDNPOutGlue]>;
Flag -> Glue, the ongoing saga llvm-svn: 122513
2010-12-24 02:28:41 +08:00
def arm_cmpfp0 : SDNode<"ARMISD::CMPFPw0", SDT_CMPFP0, [SDNPOutGlue]>;
Reformatting. No functionalogicality changes. llvm-svn: 116625
2010-10-16 05:50:45 +08:00
def arm_fmdrr : SDNode<"ARMISD::VMOVDRR", SDT_VMOVDRR>;
[ARM] Replace some C++ selection code with TableGen patterns. NFC. Differential Revision: https://reviews.llvm.org/D30794 llvm-svn: 297768
2017-03-15 02:43:37 +08:00
def arm_fmrrd : SDNode<"ARMISD::VMOVRRD", SDT_VMOVRRD>;
[ARM] Support float literals under XO When targeting execute-only and fp-armv8, float constants in a compare resulted in instruction selection failures. This is now fixed by using vmov.f32 where possible, otherwise the floating point constant is lowered into a integer constant that is moved into a floating point register. This patch also restores using fpcmp with immediate 0 under fp-armv8. Change-Id: Ie87229706f4ed879a0c0cf66631b6047ed6c6443 llvm-svn: 328313
2018-03-23 21:02:03 +08:00
def arm_vmovsr : SDNode<"ARMISD::VMOVSR", SDT_VMOVSR>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
[ARM] Armv8.2-A FP16 code generation (part 2/3) Half-precision arguments and return values are passed as if it were an int or float for ARM. This results in truncates and bitcasts to/from i16 and f16 values, which are legalized very early to stack stores/loads. When FullFP16 is enabled, we want to avoid codegen for these bitcasts as it is unnecessary and inefficient. Differential Revision: https://reviews.llvm.org/D42580 llvm-svn: 323861
2018-01-31 18:18:29 +08:00
def SDT_VMOVhr : SDTypeProfile<1, 1, [SDTCisFP<0>, SDTCisVT<1, i32>] >;
def SDT_VMOVrh : SDTypeProfile<1, 1, [SDTCisVT<0, i32>, SDTCisFP<1>] >;
def arm_vmovhr : SDNode<"ARMISD::VMOVhr", SDT_VMOVhr>;
def arm_vmovrh : SDNode<"ARMISD::VMOVrh", SDT_VMOVrh>;
Use fconsts and fconstd to materialize small fp constants. llvm-svn: 85362
2009-10-28 09:44:26 +08:00
//===----------------------------------------------------------------------===//
// Operand Definitions.
//
ARM assembly parsing and encoding for VMOV immediate. llvm-svn: 141046
2011-10-04 07:38:36 +08:00
// 8-bit floating-point immediate encodings.
def FPImmOperand : AsmOperandClass {
let Name = "FPImm";
let ParserMethod = "parseFPImm";
}
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def vfp_f16imm : Operand<f16>,
PatLeaf<(f16 fpimm), [{
return ARM_AM::getFP16Imm(N->getValueAPF()) != -1;
}], SDNodeXForm<fpimm, [{
APFloat InVal = N->getValueAPF();
uint32_t enc = ARM_AM::getFP16Imm(InVal);
[ARM] FP16 mov imm pattern This is a follow up of r324321, adding a match pattern for mov with a FP16 immediate (also fixing operand vfp_f16imm that wasn't even compiling). Differential Revision: https://reviews.llvm.org/D42973 llvm-svn: 324456
2018-02-07 16:37:17 +08:00
return CurDAG->getTargetConstant(enc, SDLoc(N), MVT::i32);
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
}]>> {
let PrintMethod = "printFPImmOperand";
let ParserMatchClass = FPImmOperand;
}
Use fconsts and fconstd to materialize small fp constants. llvm-svn: 85362
2009-10-28 09:44:26 +08:00
def vfp_f32imm : Operand<f32>,
PatLeaf<(f32 fpimm), [{
ARM fix encoding of VMOV.f32 and VMOV.f64 immediates. Encode the immediate into its 8-bit form as part of isel rather than later, which simplifies things for mapping the encoding bits, allows the removal of the custom disassembler decoding hook, makes the operand printer trivial, and prepares things more cleanly for handling these in the asm parser. rdar://10211428 llvm-svn: 140834
2011-09-30 08:50:06 +08:00
return ARM_AM::getFP32Imm(N->getValueAPF()) != -1;
}], SDNodeXForm<fpimm, [{
APFloat InVal = N->getValueAPF();
uint32_t enc = ARM_AM::getFP32Imm(InVal);
Reapply r235977 "[DebugInfo] Add debug locations to constant SD nodes" [DebugInfo] Add debug locations to constant SD nodes This adds debug location to constant nodes of Selection DAG and updates all places that create constants to pass debug locations (see PR13269). Can't guarantee that all locations are correct, but in a lot of cases choice is obvious, so most of them should be. At least all tests pass. Tests for these changes do not cover everything, instead just check it for SDNodes, ARM and AArch64 where it's easy to get incorrect locations on constants. This is not complete fix as FastISel contains workaround for wrong debug locations, which drops locations from instructions on processing constants, but there isn't currently a way to use debug locations from constants there as llvm::Constant doesn't cache it (yet). Although this is a bit different issue, not directly related to these changes. Differential Revision: http://reviews.llvm.org/D9084 llvm-svn: 235989
2015-04-28 22:05:47 +08:00
return CurDAG->getTargetConstant(enc, SDLoc(N), MVT::i32);
ARM fix encoding of VMOV.f32 and VMOV.f64 immediates. Encode the immediate into its 8-bit form as part of isel rather than later, which simplifies things for mapping the encoding bits, allows the removal of the custom disassembler decoding hook, makes the operand printer trivial, and prepares things more cleanly for handling these in the asm parser. rdar://10211428 llvm-svn: 140834
2011-09-30 08:50:06 +08:00
}]>> {
let PrintMethod = "printFPImmOperand";
ARM assembly parsing and encoding for VMOV immediate. llvm-svn: 141046
2011-10-04 07:38:36 +08:00
let ParserMatchClass = FPImmOperand;
Use fconsts and fconstd to materialize small fp constants. llvm-svn: 85362
2009-10-28 09:44:26 +08:00
}
def vfp_f64imm : Operand<f64>,
PatLeaf<(f64 fpimm), [{
ARM fix encoding of VMOV.f32 and VMOV.f64 immediates. Encode the immediate into its 8-bit form as part of isel rather than later, which simplifies things for mapping the encoding bits, allows the removal of the custom disassembler decoding hook, makes the operand printer trivial, and prepares things more cleanly for handling these in the asm parser. rdar://10211428 llvm-svn: 140834
2011-09-30 08:50:06 +08:00
return ARM_AM::getFP64Imm(N->getValueAPF()) != -1;
}], SDNodeXForm<fpimm, [{
APFloat InVal = N->getValueAPF();
uint32_t enc = ARM_AM::getFP64Imm(InVal);
Reapply r235977 "[DebugInfo] Add debug locations to constant SD nodes" [DebugInfo] Add debug locations to constant SD nodes This adds debug location to constant nodes of Selection DAG and updates all places that create constants to pass debug locations (see PR13269). Can't guarantee that all locations are correct, but in a lot of cases choice is obvious, so most of them should be. At least all tests pass. Tests for these changes do not cover everything, instead just check it for SDNodes, ARM and AArch64 where it's easy to get incorrect locations on constants. This is not complete fix as FastISel contains workaround for wrong debug locations, which drops locations from instructions on processing constants, but there isn't currently a way to use debug locations from constants there as llvm::Constant doesn't cache it (yet). Although this is a bit different issue, not directly related to these changes. Differential Revision: http://reviews.llvm.org/D9084 llvm-svn: 235989
2015-04-28 22:05:47 +08:00
return CurDAG->getTargetConstant(enc, SDLoc(N), MVT::i32);
ARM fix encoding of VMOV.f32 and VMOV.f64 immediates. Encode the immediate into its 8-bit form as part of isel rather than later, which simplifies things for mapping the encoding bits, allows the removal of the custom disassembler decoding hook, makes the operand printer trivial, and prepares things more cleanly for handling these in the asm parser. rdar://10211428 llvm-svn: 140834
2011-09-30 08:50:06 +08:00
}]>> {
let PrintMethod = "printFPImmOperand";
ARM assembly parsing and encoding for VMOV immediate. llvm-svn: 141046
2011-10-04 07:38:36 +08:00
let ParserMatchClass = FPImmOperand;
Use fconsts and fconstd to materialize small fp constants. llvm-svn: 85362
2009-10-28 09:44:26 +08:00
}
[ARM] Armv8.2-A FP16 code generation (part 1/3) This is the groundwork for Armv8.2-A FP16 code generation . Clang passes and returns _Float16 values as floats, together with the required bitconverts and truncs etc. to implement correct AAPCS behaviour, see D42318. We will implement half-precision argument passing/returning lowering in the ARM backend soon, but for now this means that this: _Float16 sub(_Float16 a, _Float16 b) { return a + b; } gets lowered to this: define float @sub(float %a.coerce, float %b.coerce) { entry: %0 = bitcast float %a.coerce to i32 %tmp.0.extract.trunc = trunc i32 %0 to i16 %1 = bitcast i16 %tmp.0.extract.trunc to half <SNIP> %add = fadd half %1, %3 <SNIP> } When FullFP16 is *not* supported, we don't make f16 a legal type, and we get legalization for "free", i.e. nothing changes and everything works as before. And also f16 argument passing/returning is handled. When FullFP16 is supported, we do make f16 a legal type, and have 2 places that we need to patch up: f16 argument passing and returning, which involves minor tweaks to avoid unnecessary code generation for some bitcasts. As a "demonstrator" that this works for the different FP16, FullFP16, softfp modes, etc., I've added match rules to the VSUB instruction description showing that we can codegen this instruction from IR, but more importantly, also to some conversion instructions. These conversions were causing issue before in the FP16 and FullFP16 cases. I've also added match rules to the VLDRH and VSTRH desriptions, so that we can actually compile the entire half-precision sub code example above. This showed that these loads and stores had the wrong addressing mode specified: AddrMode5 instead of AddrMode5FP16, which turned out not be implemented at all, so that has also been added. This is the minimal patch that shows all the different moving parts. In patch 2/3 I will add some efficient lowering of bitcasts, and in 2/3 I will add the remaining Armv8.2-A FP16 instruction descriptions. Thanks to Sam Parker and Oliver Stannard for their help and reviews! Differential Revision: https://reviews.llvm.org/D38315 llvm-svn: 323512
2018-01-26 17:26:40 +08:00
def alignedload16 : PatFrag<(ops node:$ptr), (load node:$ptr), [{
return cast<LoadSDNode>(N)->getAlignment() >= 2;
}]>;
Use vld1/vst1 to load/store f64 if alignment is < 4 and the target allows unaligned access. rdar://12091029 llvm-svn: 161962
2012-08-16 01:44:53 +08:00
def alignedload32 : PatFrag<(ops node:$ptr), (load node:$ptr), [{
return cast<LoadSDNode>(N)->getAlignment() >= 4;
}]>;
[ARM] Armv8.2-A FP16 code generation (part 1/3) This is the groundwork for Armv8.2-A FP16 code generation . Clang passes and returns _Float16 values as floats, together with the required bitconverts and truncs etc. to implement correct AAPCS behaviour, see D42318. We will implement half-precision argument passing/returning lowering in the ARM backend soon, but for now this means that this: _Float16 sub(_Float16 a, _Float16 b) { return a + b; } gets lowered to this: define float @sub(float %a.coerce, float %b.coerce) { entry: %0 = bitcast float %a.coerce to i32 %tmp.0.extract.trunc = trunc i32 %0 to i16 %1 = bitcast i16 %tmp.0.extract.trunc to half <SNIP> %add = fadd half %1, %3 <SNIP> } When FullFP16 is *not* supported, we don't make f16 a legal type, and we get legalization for "free", i.e. nothing changes and everything works as before. And also f16 argument passing/returning is handled. When FullFP16 is supported, we do make f16 a legal type, and have 2 places that we need to patch up: f16 argument passing and returning, which involves minor tweaks to avoid unnecessary code generation for some bitcasts. As a "demonstrator" that this works for the different FP16, FullFP16, softfp modes, etc., I've added match rules to the VSUB instruction description showing that we can codegen this instruction from IR, but more importantly, also to some conversion instructions. These conversions were causing issue before in the FP16 and FullFP16 cases. I've also added match rules to the VLDRH and VSTRH desriptions, so that we can actually compile the entire half-precision sub code example above. This showed that these loads and stores had the wrong addressing mode specified: AddrMode5 instead of AddrMode5FP16, which turned out not be implemented at all, so that has also been added. This is the minimal patch that shows all the different moving parts. In patch 2/3 I will add some efficient lowering of bitcasts, and in 2/3 I will add the remaining Armv8.2-A FP16 instruction descriptions. Thanks to Sam Parker and Oliver Stannard for their help and reviews! Differential Revision: https://reviews.llvm.org/D38315 llvm-svn: 323512
2018-01-26 17:26:40 +08:00
def alignedstore16 : PatFrag<(ops node:$val, node:$ptr),
(store node:$val, node:$ptr), [{
return cast<StoreSDNode>(N)->getAlignment() >= 2;
}]>;
Use vld1/vst1 to load/store f64 if alignment is < 4 and the target allows unaligned access. rdar://12091029 llvm-svn: 161962
2012-08-16 01:44:53 +08:00
def alignedstore32 : PatFrag<(ops node:$val, node:$ptr),
(store node:$val, node:$ptr), [{
return cast<StoreSDNode>(N)->getAlignment() >= 4;
}]>;
ARM VFP assembly parsing and encoding for VCVT(float <--> fixed point). rdar://10558523 llvm-svn: 147189
2011-12-23 06:19:05 +08:00
// The VCVT to/from fixed-point instructions encode the 'fbits' operand
// (the number of fixed bits) differently than it appears in the assembly
// source. It's encoded as "Size - fbits" where Size is the size of the
// fixed-point representation (32 or 16) and fbits is the value appearing
// in the assembly source, an integer in [0,16] or (0,32], depending on size.
def fbits32_asm_operand : AsmOperandClass { let Name = "FBits32"; }
def fbits32 : Operand<i32> {
let PrintMethod = "printFBits32";
let ParserMatchClass = fbits32_asm_operand;
}
def fbits16_asm_operand : AsmOperandClass { let Name = "FBits16"; }
def fbits16 : Operand<i32> {
let PrintMethod = "printFBits16";
let ParserMatchClass = fbits16_asm_operand;
}
Use fconsts and fconstd to materialize small fp constants. llvm-svn: 85362
2009-10-28 09:44:26 +08:00
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
//===----------------------------------------------------------------------===//
// Load / store Instructions.
//
The mayHaveSideEffects flag is no longer used. llvm-svn: 97348
2010-02-28 07:47:46 +08:00
let canFoldAsLoad = 1, isReMaterializable = 1 in {
The MC code couldn't handle ARM LDR instructions with negative offsets: vldr.64 d1, [r0, #-32] The problem was with how the addressing mode 5 encodes the offsets. This change makes sure that the way offsets are handled in addressing mode 5 is consistent throughout the MC code. It involves re-refactoring the "getAddrModeImmOpValue" method into an "Imm12" and "addressing mode 5" version. But not to worry! The majority of the duplicated code has been unified. llvm-svn: 118144
2010-11-03 09:49:29 +08:00
Add encodings for movement between ARM core registers and single-precision registers. llvm-svn: 116961
2010-10-21 06:44:54 +08:00
def VLDRD : ADI5<0b1101, 0b01, (outs DPR:$Dd), (ins addrmode5:$addr),
ARM VLDR/VSTR instructions don't need a size suffix. Canonicallize on the non-suffixed form, but continue to accept assembly that has any correctly sized type suffix. llvm-svn: 144583
2011-11-15 07:03:21 +08:00
IIC_fpLoad64, "vldr", "\t$Dd, $addr",
Use vld1/vst1 to load/store f64 if alignment is < 4 and the target allows unaligned access. rdar://12091029 llvm-svn: 161962
2012-08-16 01:44:53 +08:00
[(set DPR:$Dd, (f64 (alignedload32 addrmode5:$addr)))]>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
The MC code couldn't handle ARM LDR instructions with negative offsets: vldr.64 d1, [r0, #-32] The problem was with how the addressing mode 5 encodes the offsets. This change makes sure that the way offsets are handled in addressing mode 5 is consistent throughout the MC code. It involves re-refactoring the "getAddrModeImmOpValue" method into an "Imm12" and "addressing mode 5" version. But not to worry! The majority of the duplicated code has been unified. llvm-svn: 118144
2010-11-03 09:49:29 +08:00
def VLDRS : ASI5<0b1101, 0b01, (outs SPR:$Sd), (ins addrmode5:$addr),
ARM VLDR/VSTR instructions don't need a size suffix. Canonicallize on the non-suffixed form, but continue to accept assembly that has any correctly sized type suffix. llvm-svn: 144583
2011-11-15 07:03:21 +08:00
IIC_fpLoad32, "vldr", "\t$Sd, $addr",
ARM: make sure VFP loads and stores are properly aligned. Both VLDRS and VLDRD fault if the memory is not 4 byte aligned, which wasn't really being checked before, leading to faults at runtime. llvm-svn: 251352
2015-10-27 05:32:53 +08:00
[(set SPR:$Sd, (alignedload32 addrmode5:$addr))]> {
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
// Some single precision VFP instructions may be executed on both NEON and VFP
// pipelines.
let D = VFPNeonDomain;
}
The MC code couldn't handle ARM LDR instructions with negative offsets: vldr.64 d1, [r0, #-32] The problem was with how the addressing mode 5 encodes the offsets. This change makes sure that the way offsets are handled in addressing mode 5 is consistent throughout the MC code. It involves re-refactoring the "getAddrModeImmOpValue" method into an "Imm12" and "addressing mode 5" version. But not to worry! The majority of the duplicated code has been unified. llvm-svn: 118144
2010-11-03 09:49:29 +08:00
[ARM] Armv8.2-A FP16 code generation (part 1/3) This is the groundwork for Armv8.2-A FP16 code generation . Clang passes and returns _Float16 values as floats, together with the required bitconverts and truncs etc. to implement correct AAPCS behaviour, see D42318. We will implement half-precision argument passing/returning lowering in the ARM backend soon, but for now this means that this: _Float16 sub(_Float16 a, _Float16 b) { return a + b; } gets lowered to this: define float @sub(float %a.coerce, float %b.coerce) { entry: %0 = bitcast float %a.coerce to i32 %tmp.0.extract.trunc = trunc i32 %0 to i16 %1 = bitcast i16 %tmp.0.extract.trunc to half <SNIP> %add = fadd half %1, %3 <SNIP> } When FullFP16 is *not* supported, we don't make f16 a legal type, and we get legalization for "free", i.e. nothing changes and everything works as before. And also f16 argument passing/returning is handled. When FullFP16 is supported, we do make f16 a legal type, and have 2 places that we need to patch up: f16 argument passing and returning, which involves minor tweaks to avoid unnecessary code generation for some bitcasts. As a "demonstrator" that this works for the different FP16, FullFP16, softfp modes, etc., I've added match rules to the VSUB instruction description showing that we can codegen this instruction from IR, but more importantly, also to some conversion instructions. These conversions were causing issue before in the FP16 and FullFP16 cases. I've also added match rules to the VLDRH and VSTRH desriptions, so that we can actually compile the entire half-precision sub code example above. This showed that these loads and stores had the wrong addressing mode specified: AddrMode5 instead of AddrMode5FP16, which turned out not be implemented at all, so that has also been added. This is the minimal patch that shows all the different moving parts. In patch 2/3 I will add some efficient lowering of bitcasts, and in 2/3 I will add the remaining Armv8.2-A FP16 instruction descriptions. Thanks to Sam Parker and Oliver Stannard for their help and reviews! Differential Revision: https://reviews.llvm.org/D38315 llvm-svn: 323512
2018-01-26 17:26:40 +08:00
def VLDRH : AHI5<0b1101, 0b01, (outs HPR:$Sd), (ins addrmode5fp16:$addr),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpLoad16, "vldr", ".16\t$Sd, $addr",
[ARM] Armv8.2-A FP16 code generation (part 1/3) This is the groundwork for Armv8.2-A FP16 code generation . Clang passes and returns _Float16 values as floats, together with the required bitconverts and truncs etc. to implement correct AAPCS behaviour, see D42318. We will implement half-precision argument passing/returning lowering in the ARM backend soon, but for now this means that this: _Float16 sub(_Float16 a, _Float16 b) { return a + b; } gets lowered to this: define float @sub(float %a.coerce, float %b.coerce) { entry: %0 = bitcast float %a.coerce to i32 %tmp.0.extract.trunc = trunc i32 %0 to i16 %1 = bitcast i16 %tmp.0.extract.trunc to half <SNIP> %add = fadd half %1, %3 <SNIP> } When FullFP16 is *not* supported, we don't make f16 a legal type, and we get legalization for "free", i.e. nothing changes and everything works as before. And also f16 argument passing/returning is handled. When FullFP16 is supported, we do make f16 a legal type, and have 2 places that we need to patch up: f16 argument passing and returning, which involves minor tweaks to avoid unnecessary code generation for some bitcasts. As a "demonstrator" that this works for the different FP16, FullFP16, softfp modes, etc., I've added match rules to the VSUB instruction description showing that we can codegen this instruction from IR, but more importantly, also to some conversion instructions. These conversions were causing issue before in the FP16 and FullFP16 cases. I've also added match rules to the VLDRH and VSTRH desriptions, so that we can actually compile the entire half-precision sub code example above. This showed that these loads and stores had the wrong addressing mode specified: AddrMode5 instead of AddrMode5FP16, which turned out not be implemented at all, so that has also been added. This is the minimal patch that shows all the different moving parts. In patch 2/3 I will add some efficient lowering of bitcasts, and in 2/3 I will add the remaining Armv8.2-A FP16 instruction descriptions. Thanks to Sam Parker and Oliver Stannard for their help and reviews! Differential Revision: https://reviews.llvm.org/D38315 llvm-svn: 323512
2018-01-26 17:26:40 +08:00
[(set HPR:$Sd, (alignedload16 addrmode5fp16:$addr))]>,
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
Requires<[HasFullFP16]>;
The MC code couldn't handle ARM LDR instructions with negative offsets: vldr.64 d1, [r0, #-32] The problem was with how the addressing mode 5 encodes the offsets. This change makes sure that the way offsets are handled in addressing mode 5 is consistent throughout the MC code. It involves re-refactoring the "getAddrModeImmOpValue" method into an "Imm12" and "addressing mode 5" version. But not to worry! The majority of the duplicated code has been unified. llvm-svn: 118144
2010-11-03 09:49:29 +08:00
} // End of 'let canFoldAsLoad = 1, isReMaterializable = 1 in'
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
Add encoding for VSTR. llvm-svn: 118220
2010-11-04 08:59:42 +08:00
def VSTRD : ADI5<0b1101, 0b00, (outs), (ins DPR:$Dd, addrmode5:$addr),
ARM VLDR/VSTR instructions don't need a size suffix. Canonicallize on the non-suffixed form, but continue to accept assembly that has any correctly sized type suffix. llvm-svn: 144583
2011-11-15 07:03:21 +08:00
IIC_fpStore64, "vstr", "\t$Dd, $addr",
Use vld1/vst1 to load/store f64 if alignment is < 4 and the target allows unaligned access. rdar://12091029 llvm-svn: 161962
2012-08-16 01:44:53 +08:00
[(alignedstore32 (f64 DPR:$Dd), addrmode5:$addr)]>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
Add encoding for VSTR. llvm-svn: 118220
2010-11-04 08:59:42 +08:00
def VSTRS : ASI5<0b1101, 0b00, (outs), (ins SPR:$Sd, addrmode5:$addr),
ARM VLDR/VSTR instructions don't need a size suffix. Canonicallize on the non-suffixed form, but continue to accept assembly that has any correctly sized type suffix. llvm-svn: 144583
2011-11-15 07:03:21 +08:00
IIC_fpStore32, "vstr", "\t$Sd, $addr",
ARM: make sure VFP loads and stores are properly aligned. Both VLDRS and VLDRD fault if the memory is not 4 byte aligned, which wasn't really being checked before, leading to faults at runtime. llvm-svn: 251352
2015-10-27 05:32:53 +08:00
[(alignedstore32 SPR:$Sd, addrmode5:$addr)]> {
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
// Some single precision VFP instructions may be executed on both NEON and VFP
// pipelines.
let D = VFPNeonDomain;
}
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
[ARM] Armv8.2-A FP16 code generation (part 1/3) This is the groundwork for Armv8.2-A FP16 code generation . Clang passes and returns _Float16 values as floats, together with the required bitconverts and truncs etc. to implement correct AAPCS behaviour, see D42318. We will implement half-precision argument passing/returning lowering in the ARM backend soon, but for now this means that this: _Float16 sub(_Float16 a, _Float16 b) { return a + b; } gets lowered to this: define float @sub(float %a.coerce, float %b.coerce) { entry: %0 = bitcast float %a.coerce to i32 %tmp.0.extract.trunc = trunc i32 %0 to i16 %1 = bitcast i16 %tmp.0.extract.trunc to half <SNIP> %add = fadd half %1, %3 <SNIP> } When FullFP16 is *not* supported, we don't make f16 a legal type, and we get legalization for "free", i.e. nothing changes and everything works as before. And also f16 argument passing/returning is handled. When FullFP16 is supported, we do make f16 a legal type, and have 2 places that we need to patch up: f16 argument passing and returning, which involves minor tweaks to avoid unnecessary code generation for some bitcasts. As a "demonstrator" that this works for the different FP16, FullFP16, softfp modes, etc., I've added match rules to the VSUB instruction description showing that we can codegen this instruction from IR, but more importantly, also to some conversion instructions. These conversions were causing issue before in the FP16 and FullFP16 cases. I've also added match rules to the VLDRH and VSTRH desriptions, so that we can actually compile the entire half-precision sub code example above. This showed that these loads and stores had the wrong addressing mode specified: AddrMode5 instead of AddrMode5FP16, which turned out not be implemented at all, so that has also been added. This is the minimal patch that shows all the different moving parts. In patch 2/3 I will add some efficient lowering of bitcasts, and in 2/3 I will add the remaining Armv8.2-A FP16 instruction descriptions. Thanks to Sam Parker and Oliver Stannard for their help and reviews! Differential Revision: https://reviews.llvm.org/D38315 llvm-svn: 323512
2018-01-26 17:26:40 +08:00
def VSTRH : AHI5<0b1101, 0b00, (outs), (ins HPR:$Sd, addrmode5fp16:$addr),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpStore16, "vstr", ".16\t$Sd, $addr",
[ARM] Armv8.2-A FP16 code generation (part 1/3) This is the groundwork for Armv8.2-A FP16 code generation . Clang passes and returns _Float16 values as floats, together with the required bitconverts and truncs etc. to implement correct AAPCS behaviour, see D42318. We will implement half-precision argument passing/returning lowering in the ARM backend soon, but for now this means that this: _Float16 sub(_Float16 a, _Float16 b) { return a + b; } gets lowered to this: define float @sub(float %a.coerce, float %b.coerce) { entry: %0 = bitcast float %a.coerce to i32 %tmp.0.extract.trunc = trunc i32 %0 to i16 %1 = bitcast i16 %tmp.0.extract.trunc to half <SNIP> %add = fadd half %1, %3 <SNIP> } When FullFP16 is *not* supported, we don't make f16 a legal type, and we get legalization for "free", i.e. nothing changes and everything works as before. And also f16 argument passing/returning is handled. When FullFP16 is supported, we do make f16 a legal type, and have 2 places that we need to patch up: f16 argument passing and returning, which involves minor tweaks to avoid unnecessary code generation for some bitcasts. As a "demonstrator" that this works for the different FP16, FullFP16, softfp modes, etc., I've added match rules to the VSUB instruction description showing that we can codegen this instruction from IR, but more importantly, also to some conversion instructions. These conversions were causing issue before in the FP16 and FullFP16 cases. I've also added match rules to the VLDRH and VSTRH desriptions, so that we can actually compile the entire half-precision sub code example above. This showed that these loads and stores had the wrong addressing mode specified: AddrMode5 instead of AddrMode5FP16, which turned out not be implemented at all, so that has also been added. This is the minimal patch that shows all the different moving parts. In patch 2/3 I will add some efficient lowering of bitcasts, and in 2/3 I will add the remaining Armv8.2-A FP16 instruction descriptions. Thanks to Sam Parker and Oliver Stannard for their help and reviews! Differential Revision: https://reviews.llvm.org/D38315 llvm-svn: 323512
2018-01-26 17:26:40 +08:00
[(alignedstore16 HPR:$Sd, addrmode5fp16:$addr)]>,
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
Requires<[HasFullFP16]>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
//===----------------------------------------------------------------------===//
// Load / store multiple Instructions.
//
Encode the multi-load/store instructions with their respective modes ('ia', 'db', 'ib', 'da') instead of having that mode as a separate field in the instruction. It's more convenient for the asm parser and much more readable for humans. <rdar://problem/8654088> llvm-svn: 119310
2010-11-16 09:16:36 +08:00
multiclass vfp_ldst_mult<string asm, bit L_bit,
InstrItinClass itin, InstrItinClass itin_upd> {
// Double Precision
def DIA :
Proper encoding for VLDM and VSTM instructions. The register lists for these instructions have to distinguish between lists of single- and double-precision registers in order for the ASM matcher to do a proper job. In all other respects, a list of single- or double-precision registers are the same as a list of GPR registers. llvm-svn: 119460
2010-11-17 12:32:08 +08:00
AXDI4<(outs), (ins GPR:$Rn, pred:$p, dpr_reglist:$regs, variable_ops),
Add *_ldst_mult multiclasses to the ARM back-end. These will be used in the future to separate out the ia, ib, da, db variants of the load/store multiple instructions. llvm-svn: 118995
2010-11-13 17:09:38 +08:00
IndexModeNone, itin,
Encode the multi-load/store instructions with their respective modes ('ia', 'db', 'ib', 'da') instead of having that mode as a separate field in the instruction. It's more convenient for the asm parser and much more readable for humans. <rdar://problem/8654088> llvm-svn: 119310
2010-11-16 09:16:36 +08:00
!strconcat(asm, "ia${p}\t$Rn, $regs"), "", []> {
Add *_ldst_mult multiclasses to the ARM back-end. These will be used in the future to separate out the ia, ib, da, db variants of the load/store multiple instructions. llvm-svn: 118995
2010-11-13 17:09:38 +08:00
let Inst{24-23} = 0b01; // Increment After
let Inst{21} = 0; // No writeback
let Inst{20} = L_bit;
}
Encode the multi-load/store instructions with their respective modes ('ia', 'db', 'ib', 'da') instead of having that mode as a separate field in the instruction. It's more convenient for the asm parser and much more readable for humans. <rdar://problem/8654088> llvm-svn: 119310
2010-11-16 09:16:36 +08:00
def DIA_UPD :
Clean up a few 80 column violations. llvm-svn: 132946
2011-06-14 06:54:22 +08:00
AXDI4<(outs GPR:$wb), (ins GPR:$Rn, pred:$p, dpr_reglist:$regs,
variable_ops),
Add *_ldst_mult multiclasses to the ARM back-end. These will be used in the future to separate out the ia, ib, da, db variants of the load/store multiple instructions. llvm-svn: 118995
2010-11-13 17:09:38 +08:00
IndexModeUpd, itin_upd,
Encode the multi-load/store instructions with their respective modes ('ia', 'db', 'ib', 'da') instead of having that mode as a separate field in the instruction. It's more convenient for the asm parser and much more readable for humans. <rdar://problem/8654088> llvm-svn: 119310
2010-11-16 09:16:36 +08:00
!strconcat(asm, "ia${p}\t$Rn!, $regs"), "$Rn = $wb", []> {
Add *_ldst_mult multiclasses to the ARM back-end. These will be used in the future to separate out the ia, ib, da, db variants of the load/store multiple instructions. llvm-svn: 118995
2010-11-13 17:09:38 +08:00
let Inst{24-23} = 0b01; // Increment After
let Inst{21} = 1; // Writeback
let Inst{20} = L_bit;
}
Encode the multi-load/store instructions with their respective modes ('ia', 'db', 'ib', 'da') instead of having that mode as a separate field in the instruction. It's more convenient for the asm parser and much more readable for humans. <rdar://problem/8654088> llvm-svn: 119310
2010-11-16 09:16:36 +08:00
def DDB_UPD :
Clean up a few 80 column violations. llvm-svn: 132946
2011-06-14 06:54:22 +08:00
AXDI4<(outs GPR:$wb), (ins GPR:$Rn, pred:$p, dpr_reglist:$regs,
variable_ops),
Add *_ldst_mult multiclasses to the ARM back-end. These will be used in the future to separate out the ia, ib, da, db variants of the load/store multiple instructions. llvm-svn: 118995
2010-11-13 17:09:38 +08:00
IndexModeUpd, itin_upd,
!strconcat(asm, "db${p}\t$Rn!, $regs"), "$Rn = $wb", []> {
let Inst{24-23} = 0b10; // Decrement Before
let Inst{21} = 1; // Writeback
let Inst{20} = L_bit;
}
Encode the multi-load/store instructions with their respective modes ('ia', 'db', 'ib', 'da') instead of having that mode as a separate field in the instruction. It's more convenient for the asm parser and much more readable for humans. <rdar://problem/8654088> llvm-svn: 119310
2010-11-16 09:16:36 +08:00
// Single Precision
def SIA :
Proper encoding for VLDM and VSTM instructions. The register lists for these instructions have to distinguish between lists of single- and double-precision registers in order for the ASM matcher to do a proper job. In all other respects, a list of single- or double-precision registers are the same as a list of GPR registers. llvm-svn: 119460
2010-11-17 12:32:08 +08:00
AXSI4<(outs), (ins GPR:$Rn, pred:$p, spr_reglist:$regs, variable_ops),
Add *_ldst_mult multiclasses to the ARM back-end. These will be used in the future to separate out the ia, ib, da, db variants of the load/store multiple instructions. llvm-svn: 118995
2010-11-13 17:09:38 +08:00
IndexModeNone, itin,
Encode the multi-load/store instructions with their respective modes ('ia', 'db', 'ib', 'da') instead of having that mode as a separate field in the instruction. It's more convenient for the asm parser and much more readable for humans. <rdar://problem/8654088> llvm-svn: 119310
2010-11-16 09:16:36 +08:00
!strconcat(asm, "ia${p}\t$Rn, $regs"), "", []> {
Add *_ldst_mult multiclasses to the ARM back-end. These will be used in the future to separate out the ia, ib, da, db variants of the load/store multiple instructions. llvm-svn: 118995
2010-11-13 17:09:38 +08:00
let Inst{24-23} = 0b01; // Increment After
let Inst{21} = 0; // No writeback
let Inst{20} = L_bit;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines.
let D = VFPNeonDomain;
Add *_ldst_mult multiclasses to the ARM back-end. These will be used in the future to separate out the ia, ib, da, db variants of the load/store multiple instructions. llvm-svn: 118995
2010-11-13 17:09:38 +08:00
}
Encode the multi-load/store instructions with their respective modes ('ia', 'db', 'ib', 'da') instead of having that mode as a separate field in the instruction. It's more convenient for the asm parser and much more readable for humans. <rdar://problem/8654088> llvm-svn: 119310
2010-11-16 09:16:36 +08:00
def SIA_UPD :
Clean up a few 80 column violations. llvm-svn: 132946
2011-06-14 06:54:22 +08:00
AXSI4<(outs GPR:$wb), (ins GPR:$Rn, pred:$p, spr_reglist:$regs,
variable_ops),
Add *_ldst_mult multiclasses to the ARM back-end. These will be used in the future to separate out the ia, ib, da, db variants of the load/store multiple instructions. llvm-svn: 118995
2010-11-13 17:09:38 +08:00
IndexModeUpd, itin_upd,
Encode the multi-load/store instructions with their respective modes ('ia', 'db', 'ib', 'da') instead of having that mode as a separate field in the instruction. It's more convenient for the asm parser and much more readable for humans. <rdar://problem/8654088> llvm-svn: 119310
2010-11-16 09:16:36 +08:00
!strconcat(asm, "ia${p}\t$Rn!, $regs"), "$Rn = $wb", []> {
Add *_ldst_mult multiclasses to the ARM back-end. These will be used in the future to separate out the ia, ib, da, db variants of the load/store multiple instructions. llvm-svn: 118995
2010-11-13 17:09:38 +08:00
let Inst{24-23} = 0b01; // Increment After
let Inst{21} = 1; // Writeback
let Inst{20} = L_bit;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines.
let D = VFPNeonDomain;
Add *_ldst_mult multiclasses to the ARM back-end. These will be used in the future to separate out the ia, ib, da, db variants of the load/store multiple instructions. llvm-svn: 118995
2010-11-13 17:09:38 +08:00
}
Encode the multi-load/store instructions with their respective modes ('ia', 'db', 'ib', 'da') instead of having that mode as a separate field in the instruction. It's more convenient for the asm parser and much more readable for humans. <rdar://problem/8654088> llvm-svn: 119310
2010-11-16 09:16:36 +08:00
def SDB_UPD :
Clean up a few 80 column violations. llvm-svn: 132946
2011-06-14 06:54:22 +08:00
AXSI4<(outs GPR:$wb), (ins GPR:$Rn, pred:$p, spr_reglist:$regs,
variable_ops),
Add *_ldst_mult multiclasses to the ARM back-end. These will be used in the future to separate out the ia, ib, da, db variants of the load/store multiple instructions. llvm-svn: 118995
2010-11-13 17:09:38 +08:00
IndexModeUpd, itin_upd,
!strconcat(asm, "db${p}\t$Rn!, $regs"), "$Rn = $wb", []> {
let Inst{24-23} = 0b10; // Decrement Before
let Inst{21} = 1; // Writeback
let Inst{20} = L_bit;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines.
let D = VFPNeonDomain;
Add *_ldst_mult multiclasses to the ARM back-end. These will be used in the future to separate out the ia, ib, da, db variants of the load/store multiple instructions. llvm-svn: 118995
2010-11-13 17:09:38 +08:00
}
}
Replace neverHasSideEffects=1 with hasSideEffects=0 in all .td files. llvm-svn: 222801
2014-11-26 08:46:26 +08:00
let hasSideEffects = 0 in {
Add uses of the *_ldst_multi multiclasses. These aren't used yet. llvm-svn: 118999
2010-11-13 18:57:02 +08:00
Encode the multi-load/store instructions with their respective modes ('ia', 'db', 'ib', 'da') instead of having that mode as a separate field in the instruction. It's more convenient for the asm parser and much more readable for humans. <rdar://problem/8654088> llvm-svn: 119310
2010-11-16 09:16:36 +08:00
let mayLoad = 1, hasExtraDefRegAllocReq = 1 in
defm VLDM : vfp_ldst_mult<"vldm", 1, IIC_fpLoad_m, IIC_fpLoad_mu>;
Add uses of the *_ldst_multi multiclasses. These aren't used yet. llvm-svn: 118999
2010-11-13 18:57:02 +08:00
Encode the multi-load/store instructions with their respective modes ('ia', 'db', 'ib', 'da') instead of having that mode as a separate field in the instruction. It's more convenient for the asm parser and much more readable for humans. <rdar://problem/8654088> llvm-svn: 119310
2010-11-16 09:16:36 +08:00
let mayStore = 1, hasExtraSrcRegAllocReq = 1 in
ARM: fix typo in VFP instruction definition The vstm family of VFP instructions belong to the VFP store itinerary class, not the VFP load itinerary class. llvm-svn: 198170
2013-12-30 01:58:27 +08:00
defm VSTM : vfp_ldst_mult<"vstm", 0, IIC_fpStore_m, IIC_fpStore_mu>;
Add uses of the *_ldst_multi multiclasses. These aren't used yet. llvm-svn: 118999
2010-11-13 18:57:02 +08:00
Replace neverHasSideEffects=1 with hasSideEffects=0 in all .td files. llvm-svn: 222801
2014-11-26 08:46:26 +08:00
} // hasSideEffects
Add uses of the *_ldst_multi multiclasses. These aren't used yet. llvm-svn: 118999
2010-11-13 18:57:02 +08:00
vldm and vstm are mnemonics for vldmia and vstmia resp. llvm-svn: 119321
2010-11-16 10:00:24 +08:00
def : MnemonicAlias<"vldm", "vldmia">;
def : MnemonicAlias<"vstm", "vstmia">;
[ARM] Add ARMv8-M security extension instructions to ARMv8-M Baseline/Mainline This patch was originally committed as r257883, but was reverted due to windows failures. The cause of these failures has been fixed under r258677, hence re-committing the original patch. llvm-svn: 258681
2016-01-25 19:24:47 +08:00
//===----------------------------------------------------------------------===//
// Lazy load / store multiple Instructions
//
let mayLoad = 1 in
def VLLDM : AXSI4<(outs), (ins GPRnopc:$Rn, pred:$p), IndexModeNone,
IIC_fpLoad_m, "vlldm${p}\t$Rn", "", []>,
Requires<[HasV8MMainline, Has8MSecExt]> {
let Inst{24-23} = 0b00;
let Inst{22} = 0;
let Inst{21} = 1;
let Inst{20} = 1;
let Inst{15-12} = 0;
let Inst{7-0} = 0;
let mayLoad = 1;
}
let mayStore = 1 in
def VLSTM : AXSI4<(outs), (ins GPRnopc:$Rn, pred:$p), IndexModeNone,
IIC_fpStore_m, "vlstm${p}\t$Rn", "", []>,
Requires<[HasV8MMainline, Has8MSecExt]> {
let Inst{24-23} = 0b00;
let Inst{22} = 0;
let Inst{21} = 1;
let Inst{20} = 0;
let Inst{15-12} = 0;
let Inst{7-0} = 0;
let mayStore = 1;
}
ARM target does not use printAliasInstr machinery which forces having special checks in ArmInstPrinter::printInstruction. This patch addresses this issue. Not all special checks could be removed: either they involve elaborated conditions under which the alias is emitted (e.g. ldm/stm on sp may be pop/push but only if the number of registers is >= 2) or the number of registers is multivalued (like happens again with ldm/stm) and they do not match the InstAlias pattern which assumes single-valued operands in the pattern. Patch by: Roger Ferrer Ibanez Differential Revision: http://reviews.llvm.org/D20237 llvm-svn: 271667
2016-06-03 21:19:43 +08:00
def : InstAlias<"vpush${p} $r", (VSTMDDB_UPD SP, pred:$p, dpr_reglist:$r), 0>,
ARM assembler support for vpush/vpop. Add aliases for the vpush/vpop mnemonics to the VFP load/store multiple writeback instructions w/ SP as the base pointer. rdar://9683231 llvm-svn: 133932
2011-06-28 04:00:07 +08:00
Requires<[HasVFP2]>;
ARM target does not use printAliasInstr machinery which forces having special checks in ArmInstPrinter::printInstruction. This patch addresses this issue. Not all special checks could be removed: either they involve elaborated conditions under which the alias is emitted (e.g. ldm/stm on sp may be pop/push but only if the number of registers is >= 2) or the number of registers is multivalued (like happens again with ldm/stm) and they do not match the InstAlias pattern which assumes single-valued operands in the pattern. Patch by: Roger Ferrer Ibanez Differential Revision: http://reviews.llvm.org/D20237 llvm-svn: 271667
2016-06-03 21:19:43 +08:00
def : InstAlias<"vpush${p} $r", (VSTMSDB_UPD SP, pred:$p, spr_reglist:$r), 0>,
ARM assembler support for vpush/vpop. Add aliases for the vpush/vpop mnemonics to the VFP load/store multiple writeback instructions w/ SP as the base pointer. rdar://9683231 llvm-svn: 133932
2011-06-28 04:00:07 +08:00
Requires<[HasVFP2]>;
ARM target does not use printAliasInstr machinery which forces having special checks in ArmInstPrinter::printInstruction. This patch addresses this issue. Not all special checks could be removed: either they involve elaborated conditions under which the alias is emitted (e.g. ldm/stm on sp may be pop/push but only if the number of registers is >= 2) or the number of registers is multivalued (like happens again with ldm/stm) and they do not match the InstAlias pattern which assumes single-valued operands in the pattern. Patch by: Roger Ferrer Ibanez Differential Revision: http://reviews.llvm.org/D20237 llvm-svn: 271667
2016-06-03 21:19:43 +08:00
def : InstAlias<"vpop${p} $r", (VLDMDIA_UPD SP, pred:$p, dpr_reglist:$r), 0>,
ARM assembler support for vpush/vpop. Add aliases for the vpush/vpop mnemonics to the VFP load/store multiple writeback instructions w/ SP as the base pointer. rdar://9683231 llvm-svn: 133932
2011-06-28 04:00:07 +08:00
Requires<[HasVFP2]>;
ARM target does not use printAliasInstr machinery which forces having special checks in ArmInstPrinter::printInstruction. This patch addresses this issue. Not all special checks could be removed: either they involve elaborated conditions under which the alias is emitted (e.g. ldm/stm on sp may be pop/push but only if the number of registers is >= 2) or the number of registers is multivalued (like happens again with ldm/stm) and they do not match the InstAlias pattern which assumes single-valued operands in the pattern. Patch by: Roger Ferrer Ibanez Differential Revision: http://reviews.llvm.org/D20237 llvm-svn: 271667
2016-06-03 21:19:43 +08:00
def : InstAlias<"vpop${p} $r", (VLDMSIA_UPD SP, pred:$p, spr_reglist:$r), 0>,
ARM assembler support for vpush/vpop. Add aliases for the vpush/vpop mnemonics to the VFP load/store multiple writeback instructions w/ SP as the base pointer. rdar://9683231 llvm-svn: 133932
2011-06-28 04:00:07 +08:00
Requires<[HasVFP2]>;
ARM vpush/vpop assembler mnemonics accept an optional size suffix. rdar://10988114 llvm-svn: 152068
2012-03-06 07:16:31 +08:00
defm : VFPDTAnyInstAlias<"vpush${p}", "$r",
(VSTMSDB_UPD SP, pred:$p, spr_reglist:$r)>;
defm : VFPDTAnyInstAlias<"vpush${p}", "$r",
(VSTMDDB_UPD SP, pred:$p, dpr_reglist:$r)>;
defm : VFPDTAnyInstAlias<"vpop${p}", "$r",
(VLDMSIA_UPD SP, pred:$p, spr_reglist:$r)>;
defm : VFPDTAnyInstAlias<"vpop${p}", "$r",
(VLDMDIA_UPD SP, pred:$p, dpr_reglist:$r)>;
ARM assembler support for vpush/vpop. Add aliases for the vpush/vpop mnemonics to the VFP load/store multiple writeback instructions w/ SP as the base pointer. rdar://9683231 llvm-svn: 133932
2011-06-28 04:00:07 +08:00
ARM: add fstmx and fldmx instructions for assembly These instructions are deprecated oddities, but we still need to be able to disassemble (and reassemble) them if and when they're encountered. Patch by Amaury de la Vieuville. llvm-svn: 183011
2013-05-31 23:55:51 +08:00
// FLDMX, FSTMX - Load and store multiple unknown precision registers for
// pre-armv6 cores.
// These instruction are deprecated so we don't want them to get selected.
[ARM] Remove pre-UAL FLDM/FSTM aliases These are pre-UAL syntax, and we don't support any other pre-UAL instructions, with the exception of FLDMX/FSTMX, which don't have a UAL equivalent. Therefore there's no reason to keep them or their AsmParser hacks around. With the AsmParser hacks removed, the FLDMX and FSTMX instructions get the same operand diagnostics as the UAL instructions. Differential revision: https://reviews.llvm.org/D39196 llvm-svn: 318777
2017-11-22 00:20:25 +08:00
// However, there is no UAL syntax for them, so we keep them around for
// (dis)assembly only.
ARM: add fstmx and fldmx instructions for assembly These instructions are deprecated oddities, but we still need to be able to disassemble (and reassemble) them if and when they're encountered. Patch by Amaury de la Vieuville. llvm-svn: 183011
2013-05-31 23:55:51 +08:00
multiclass vfp_ldstx_mult<string asm, bit L_bit> {
// Unknown precision
def XIA :
AXXI4<(outs), (ins GPR:$Rn, pred:$p, dpr_reglist:$regs, variable_ops),
IndexModeNone, !strconcat(asm, "iax${p}\t$Rn, $regs"), "", []> {
let Inst{24-23} = 0b01; // Increment After
let Inst{21} = 0; // No writeback
let Inst{20} = L_bit;
}
def XIA_UPD :
AXXI4<(outs GPR:$wb), (ins GPR:$Rn, pred:$p, dpr_reglist:$regs, variable_ops),
IndexModeUpd, !strconcat(asm, "iax${p}\t$Rn!, $regs"), "$Rn = $wb", []> {
let Inst{24-23} = 0b01; // Increment After
let Inst{21} = 1; // Writeback
let Inst{20} = L_bit;
}
def XDB_UPD :
AXXI4<(outs GPR:$wb), (ins GPR:$Rn, pred:$p, dpr_reglist:$regs, variable_ops),
IndexModeUpd, !strconcat(asm, "dbx${p}\t$Rn!, $regs"), "$Rn = $wb", []> {
let Inst{24-23} = 0b10; // Decrement Before
ARM: provide VFP aliases for pre-V6 mnemonics In order to provide compatibility with the GNU assembler, provide aliases for pre-UAL mnemonics for floating point operations. llvm-svn: 198172
2013-12-30 01:58:35 +08:00
let Inst{21} = 1; // Writeback
ARM: add fstmx and fldmx instructions for assembly These instructions are deprecated oddities, but we still need to be able to disassemble (and reassemble) them if and when they're encountered. Patch by Amaury de la Vieuville. llvm-svn: 183011
2013-05-31 23:55:51 +08:00
let Inst{20} = L_bit;
}
}
defm FLDM : vfp_ldstx_mult<"fldm", 1>;
defm FSTM : vfp_ldstx_mult<"fstm", 0>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
ARM: provide VFP aliases for pre-V6 mnemonics In order to provide compatibility with the GNU assembler, provide aliases for pre-UAL mnemonics for floating point operations. llvm-svn: 198172
2013-12-30 01:58:35 +08:00
def : VFP2MnemonicAlias<"fldmeax", "fldmdbx">;
def : VFP2MnemonicAlias<"fldmfdx", "fldmiax">;
def : VFP2MnemonicAlias<"fstmeax", "fstmiax">;
def : VFP2MnemonicAlias<"fstmfdx", "fstmdbx">;
Refactor some of the encoding logic into a base class. This keeps us from having to add 10+ lines to every instruction. It may turn out that we can move this base class into it's parent class. llvm-svn: 116362
2010-10-13 07:06:54 +08:00
//===----------------------------------------------------------------------===//
// FP Binary Operations.
//
Add VCMP (VFP floating-point compare without 'E' bit set) for disassembly purpose. llvm-svn: 95560
2010-02-09 03:41:48 +08:00
ARM some VFP tblgen'erated two-operand aliases. llvm-svn: 155178
2012-04-20 08:15:00 +08:00
let TwoOperandAliasConstraint = "$Dn = $Dd" in
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VADDD : ADbI<0b11100, 0b11, 0, 0,
(outs DPR:$Dd), (ins DPR:$Dn, DPR:$Dm),
IIC_fpALU64, "vadd", ".f64\t$Dd, $Dn, $Dm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[(set DPR:$Dd, (fadd DPR:$Dn, (f64 DPR:$Dm)))]>,
Sched<[WriteFPALU64]>;
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
ARM some VFP tblgen'erated two-operand aliases. llvm-svn: 155178
2012-04-20 08:15:00 +08:00
let TwoOperandAliasConstraint = "$Sn = $Sd" in
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VADDS : ASbIn<0b11100, 0b11, 0, 0,
(outs SPR:$Sd), (ins SPR:$Sn, SPR:$Sm),
IIC_fpALU32, "vadd", ".f32\t$Sd, $Sn, $Sm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[(set SPR:$Sd, (fadd SPR:$Sn, SPR:$Sm))]>,
Sched<[WriteFPALU32]> {
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
}
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
let TwoOperandAliasConstraint = "$Sn = $Sd" in
def VADDH : AHbI<0b11100, 0b11, 0, 0,
[ARM] Armv8.2-A FP16 code generation (part 1/3) This is the groundwork for Armv8.2-A FP16 code generation . Clang passes and returns _Float16 values as floats, together with the required bitconverts and truncs etc. to implement correct AAPCS behaviour, see D42318. We will implement half-precision argument passing/returning lowering in the ARM backend soon, but for now this means that this: _Float16 sub(_Float16 a, _Float16 b) { return a + b; } gets lowered to this: define float @sub(float %a.coerce, float %b.coerce) { entry: %0 = bitcast float %a.coerce to i32 %tmp.0.extract.trunc = trunc i32 %0 to i16 %1 = bitcast i16 %tmp.0.extract.trunc to half <SNIP> %add = fadd half %1, %3 <SNIP> } When FullFP16 is *not* supported, we don't make f16 a legal type, and we get legalization for "free", i.e. nothing changes and everything works as before. And also f16 argument passing/returning is handled. When FullFP16 is supported, we do make f16 a legal type, and have 2 places that we need to patch up: f16 argument passing and returning, which involves minor tweaks to avoid unnecessary code generation for some bitcasts. As a "demonstrator" that this works for the different FP16, FullFP16, softfp modes, etc., I've added match rules to the VSUB instruction description showing that we can codegen this instruction from IR, but more importantly, also to some conversion instructions. These conversions were causing issue before in the FP16 and FullFP16 cases. I've also added match rules to the VLDRH and VSTRH desriptions, so that we can actually compile the entire half-precision sub code example above. This showed that these loads and stores had the wrong addressing mode specified: AddrMode5 instead of AddrMode5FP16, which turned out not be implemented at all, so that has also been added. This is the minimal patch that shows all the different moving parts. In patch 2/3 I will add some efficient lowering of bitcasts, and in 2/3 I will add the remaining Armv8.2-A FP16 instruction descriptions. Thanks to Sam Parker and Oliver Stannard for their help and reviews! Differential Revision: https://reviews.llvm.org/D38315 llvm-svn: 323512
2018-01-26 17:26:40 +08:00
(outs HPR:$Sd), (ins HPR:$Sn, HPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpALU16, "vadd", ".f16\t$Sd, $Sn, $Sm",
[ARM] Armv8.2-A FP16 code generation (part 1/3) This is the groundwork for Armv8.2-A FP16 code generation . Clang passes and returns _Float16 values as floats, together with the required bitconverts and truncs etc. to implement correct AAPCS behaviour, see D42318. We will implement half-precision argument passing/returning lowering in the ARM backend soon, but for now this means that this: _Float16 sub(_Float16 a, _Float16 b) { return a + b; } gets lowered to this: define float @sub(float %a.coerce, float %b.coerce) { entry: %0 = bitcast float %a.coerce to i32 %tmp.0.extract.trunc = trunc i32 %0 to i16 %1 = bitcast i16 %tmp.0.extract.trunc to half <SNIP> %add = fadd half %1, %3 <SNIP> } When FullFP16 is *not* supported, we don't make f16 a legal type, and we get legalization for "free", i.e. nothing changes and everything works as before. And also f16 argument passing/returning is handled. When FullFP16 is supported, we do make f16 a legal type, and have 2 places that we need to patch up: f16 argument passing and returning, which involves minor tweaks to avoid unnecessary code generation for some bitcasts. As a "demonstrator" that this works for the different FP16, FullFP16, softfp modes, etc., I've added match rules to the VSUB instruction description showing that we can codegen this instruction from IR, but more importantly, also to some conversion instructions. These conversions were causing issue before in the FP16 and FullFP16 cases. I've also added match rules to the VLDRH and VSTRH desriptions, so that we can actually compile the entire half-precision sub code example above. This showed that these loads and stores had the wrong addressing mode specified: AddrMode5 instead of AddrMode5FP16, which turned out not be implemented at all, so that has also been added. This is the minimal patch that shows all the different moving parts. In patch 2/3 I will add some efficient lowering of bitcasts, and in 2/3 I will add the remaining Armv8.2-A FP16 instruction descriptions. Thanks to Sam Parker and Oliver Stannard for their help and reviews! Differential Revision: https://reviews.llvm.org/D38315 llvm-svn: 323512
2018-01-26 17:26:40 +08:00
[(set HPR:$Sd, (fadd HPR:$Sn, HPR:$Sm))]>,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Sched<[WriteFPALU32]>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
ARM some VFP tblgen'erated two-operand aliases. llvm-svn: 155178
2012-04-20 08:15:00 +08:00
let TwoOperandAliasConstraint = "$Dn = $Dd" in
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VSUBD : ADbI<0b11100, 0b11, 1, 0,
(outs DPR:$Dd), (ins DPR:$Dn, DPR:$Dm),
IIC_fpALU64, "vsub", ".f64\t$Dd, $Dn, $Dm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[(set DPR:$Dd, (fsub DPR:$Dn, (f64 DPR:$Dm)))]>,
Sched<[WriteFPALU64]>;
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
ARM some VFP tblgen'erated two-operand aliases. llvm-svn: 155178
2012-04-20 08:15:00 +08:00
let TwoOperandAliasConstraint = "$Sn = $Sd" in
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VSUBS : ASbIn<0b11100, 0b11, 1, 0,
(outs SPR:$Sd), (ins SPR:$Sn, SPR:$Sm),
IIC_fpALU32, "vsub", ".f32\t$Sd, $Sn, $Sm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[(set SPR:$Sd, (fsub SPR:$Sn, SPR:$Sm))]>,
Sched<[WriteFPALU32]>{
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
}
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
let TwoOperandAliasConstraint = "$Sn = $Sd" in
def VSUBH : AHbI<0b11100, 0b11, 1, 0,
[ARM] Armv8.2-A FP16 code generation (part 1/3) This is the groundwork for Armv8.2-A FP16 code generation . Clang passes and returns _Float16 values as floats, together with the required bitconverts and truncs etc. to implement correct AAPCS behaviour, see D42318. We will implement half-precision argument passing/returning lowering in the ARM backend soon, but for now this means that this: _Float16 sub(_Float16 a, _Float16 b) { return a + b; } gets lowered to this: define float @sub(float %a.coerce, float %b.coerce) { entry: %0 = bitcast float %a.coerce to i32 %tmp.0.extract.trunc = trunc i32 %0 to i16 %1 = bitcast i16 %tmp.0.extract.trunc to half <SNIP> %add = fadd half %1, %3 <SNIP> } When FullFP16 is *not* supported, we don't make f16 a legal type, and we get legalization for "free", i.e. nothing changes and everything works as before. And also f16 argument passing/returning is handled. When FullFP16 is supported, we do make f16 a legal type, and have 2 places that we need to patch up: f16 argument passing and returning, which involves minor tweaks to avoid unnecessary code generation for some bitcasts. As a "demonstrator" that this works for the different FP16, FullFP16, softfp modes, etc., I've added match rules to the VSUB instruction description showing that we can codegen this instruction from IR, but more importantly, also to some conversion instructions. These conversions were causing issue before in the FP16 and FullFP16 cases. I've also added match rules to the VLDRH and VSTRH desriptions, so that we can actually compile the entire half-precision sub code example above. This showed that these loads and stores had the wrong addressing mode specified: AddrMode5 instead of AddrMode5FP16, which turned out not be implemented at all, so that has also been added. This is the minimal patch that shows all the different moving parts. In patch 2/3 I will add some efficient lowering of bitcasts, and in 2/3 I will add the remaining Armv8.2-A FP16 instruction descriptions. Thanks to Sam Parker and Oliver Stannard for their help and reviews! Differential Revision: https://reviews.llvm.org/D38315 llvm-svn: 323512
2018-01-26 17:26:40 +08:00
(outs HPR:$Sd), (ins HPR:$Sn, HPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpALU16, "vsub", ".f16\t$Sd, $Sn, $Sm",
[ARM] Armv8.2-A FP16 code generation (part 1/3) This is the groundwork for Armv8.2-A FP16 code generation . Clang passes and returns _Float16 values as floats, together with the required bitconverts and truncs etc. to implement correct AAPCS behaviour, see D42318. We will implement half-precision argument passing/returning lowering in the ARM backend soon, but for now this means that this: _Float16 sub(_Float16 a, _Float16 b) { return a + b; } gets lowered to this: define float @sub(float %a.coerce, float %b.coerce) { entry: %0 = bitcast float %a.coerce to i32 %tmp.0.extract.trunc = trunc i32 %0 to i16 %1 = bitcast i16 %tmp.0.extract.trunc to half <SNIP> %add = fadd half %1, %3 <SNIP> } When FullFP16 is *not* supported, we don't make f16 a legal type, and we get legalization for "free", i.e. nothing changes and everything works as before. And also f16 argument passing/returning is handled. When FullFP16 is supported, we do make f16 a legal type, and have 2 places that we need to patch up: f16 argument passing and returning, which involves minor tweaks to avoid unnecessary code generation for some bitcasts. As a "demonstrator" that this works for the different FP16, FullFP16, softfp modes, etc., I've added match rules to the VSUB instruction description showing that we can codegen this instruction from IR, but more importantly, also to some conversion instructions. These conversions were causing issue before in the FP16 and FullFP16 cases. I've also added match rules to the VLDRH and VSTRH desriptions, so that we can actually compile the entire half-precision sub code example above. This showed that these loads and stores had the wrong addressing mode specified: AddrMode5 instead of AddrMode5FP16, which turned out not be implemented at all, so that has also been added. This is the minimal patch that shows all the different moving parts. In patch 2/3 I will add some efficient lowering of bitcasts, and in 2/3 I will add the remaining Armv8.2-A FP16 instruction descriptions. Thanks to Sam Parker and Oliver Stannard for their help and reviews! Differential Revision: https://reviews.llvm.org/D38315 llvm-svn: 323512
2018-01-26 17:26:40 +08:00
[(set HPR:$Sd, (fsub HPR:$Sn, HPR:$Sm))]>,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Sched<[WriteFPALU32]>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
ARM some VFP tblgen'erated two-operand aliases. llvm-svn: 155178
2012-04-20 08:15:00 +08:00
let TwoOperandAliasConstraint = "$Dn = $Dd" in
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VDIVD : ADbI<0b11101, 0b00, 0, 0,
(outs DPR:$Dd), (ins DPR:$Dn, DPR:$Dm),
IIC_fpDIV64, "vdiv", ".f64\t$Dd, $Dn, $Dm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[(set DPR:$Dd, (fdiv DPR:$Dn, (f64 DPR:$Dm)))]>,
Sched<[WriteFPDIV64]>;
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
ARM some VFP tblgen'erated two-operand aliases. llvm-svn: 155178
2012-04-20 08:15:00 +08:00
let TwoOperandAliasConstraint = "$Sn = $Sd" in
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VDIVS : ASbI<0b11101, 0b00, 0, 0,
(outs SPR:$Sd), (ins SPR:$Sn, SPR:$Sm),
IIC_fpDIV32, "vdiv", ".f32\t$Sd, $Sn, $Sm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[(set SPR:$Sd, (fdiv SPR:$Sn, SPR:$Sm))]>,
Sched<[WriteFPDIV32]>;
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
let TwoOperandAliasConstraint = "$Sn = $Sd" in
def VDIVH : AHbI<0b11101, 0b00, 0, 0,
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
(outs HPR:$Sd), (ins HPR:$Sn, HPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpDIV16, "vdiv", ".f16\t$Sd, $Sn, $Sm",
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
[(set HPR:$Sd, (fdiv HPR:$Sn, HPR:$Sm))]>,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Sched<[WriteFPDIV32]>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
ARM some VFP tblgen'erated two-operand aliases. llvm-svn: 155178
2012-04-20 08:15:00 +08:00
let TwoOperandAliasConstraint = "$Dn = $Dd" in
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VMULD : ADbI<0b11100, 0b10, 0, 0,
(outs DPR:$Dd), (ins DPR:$Dn, DPR:$Dm),
IIC_fpMUL64, "vmul", ".f64\t$Dd, $Dn, $Dm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[(set DPR:$Dd, (fmul DPR:$Dn, (f64 DPR:$Dm)))]>,
Sched<[WriteFPMUL64, ReadFPMUL, ReadFPMUL]>;
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
ARM some VFP tblgen'erated two-operand aliases. llvm-svn: 155178
2012-04-20 08:15:00 +08:00
let TwoOperandAliasConstraint = "$Sn = $Sd" in
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VMULS : ASbIn<0b11100, 0b10, 0, 0,
(outs SPR:$Sd), (ins SPR:$Sn, SPR:$Sm),
IIC_fpMUL32, "vmul", ".f32\t$Sd, $Sn, $Sm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[(set SPR:$Sd, (fmul SPR:$Sn, SPR:$Sm))]>,
Sched<[WriteFPMUL32, ReadFPMUL, ReadFPMUL]> {
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
}
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
let TwoOperandAliasConstraint = "$Sn = $Sd" in
def VMULH : AHbI<0b11100, 0b10, 0, 0,
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
(outs HPR:$Sd), (ins HPR:$Sn, HPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpMUL16, "vmul", ".f16\t$Sd, $Sn, $Sm",
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
[(set HPR:$Sd, (fmul HPR:$Sn, HPR:$Sm))]>,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Sched<[WriteFPMUL32, ReadFPMUL, ReadFPMUL]>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VNMULD : ADbI<0b11100, 0b10, 1, 0,
(outs DPR:$Dd), (ins DPR:$Dn, DPR:$Dm),
IIC_fpMUL64, "vnmul", ".f64\t$Dd, $Dn, $Dm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[(set DPR:$Dd, (fneg (fmul DPR:$Dn, (f64 DPR:$Dm))))]>,
Sched<[WriteFPMUL64, ReadFPMUL, ReadFPMUL]>;
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VNMULS : ASbI<0b11100, 0b10, 1, 0,
(outs SPR:$Sd), (ins SPR:$Sn, SPR:$Sm),
IIC_fpMUL32, "vnmul", ".f32\t$Sd, $Sn, $Sm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[(set SPR:$Sd, (fneg (fmul SPR:$Sn, SPR:$Sm)))]>,
Sched<[WriteFPMUL32, ReadFPMUL, ReadFPMUL]> {
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
}
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VNMULH : AHbI<0b11100, 0b10, 1, 0,
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
(outs HPR:$Sd), (ins HPR:$Sn, HPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpMUL16, "vnmul", ".f16\t$Sd, $Sn, $Sm",
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
[(set HPR:$Sd, (fneg (fmul HPR:$Sn, HPR:$Sm)))]>,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Sched<[WriteFPMUL32, ReadFPMUL, ReadFPMUL]>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
[ARMv8] Add CodeGen support for VSEL. This uses the ARMcmov pattern that Tim cleaned up in r188995. Thanks to Simon Tatham for his floating point help! llvm-svn: 189024
2013-08-22 23:29:11 +08:00
multiclass vsel_inst<string op, bits<2> opc, int CC> {
let DecoderNamespace = "VFPV8", PostEncoderMethod = "",
Uses = [CPSR], AddedComplexity = 4 in {
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def H : AHbInp<0b11100, opc, 0,
[ARM] FP16 codegen support for VSEL This implements lowering of SELECT_CC for f16s, which enables codegen of VSEL with f16 types. Differential Revision: https://reviews.llvm.org/D44518 llvm-svn: 327695
2018-03-16 16:06:25 +08:00
(outs HPR:$Sd), (ins HPR:$Sn, HPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
NoItinerary, !strconcat("vsel", op, ".f16\t$Sd, $Sn, $Sm"),
[ARM] FP16 codegen support for VSEL This implements lowering of SELECT_CC for f16s, which enables codegen of VSEL with f16 types. Differential Revision: https://reviews.llvm.org/D44518 llvm-svn: 327695
2018-03-16 16:06:25 +08:00
[(set HPR:$Sd, (ARMcmov HPR:$Sm, HPR:$Sn, CC))]>,
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
Requires<[HasFullFP16]>;
Add MC support for the v8fp instructions: vmaxnm and vminnm. llvm-svn: 185767
2013-07-07 04:50:18 +08:00
def S : ASbInp<0b11100, opc, 0,
Add support for MC assembling and disassembling of vsel{ge, gt, eq, vs} instructions. This adds a new decoder table/namespace 'VFPV8', as these instructions have their top 4 bits as 0b1111, while other Thumb instructions have 0b1110. llvm-svn: 185642
2013-07-04 22:57:20 +08:00
(outs SPR:$Sd), (ins SPR:$Sn, SPR:$Sm),
NoItinerary, !strconcat("vsel", op, ".f32\t$Sd, $Sn, $Sm"),
[ARMv8] Add CodeGen support for VSEL. This uses the ARMcmov pattern that Tim cleaned up in r188995. Thanks to Simon Tatham for his floating point help! llvm-svn: 189024
2013-08-22 23:29:11 +08:00
[(set SPR:$Sd, (ARMcmov SPR:$Sm, SPR:$Sn, CC))]>,
[ARMv8] Change hasV8Fp to hasFPARMv8, and other command line options to be more consistent. llvm-svn: 190692
2013-09-13 21:46:57 +08:00
Requires<[HasFPARMv8]>;
Add support for MC assembling and disassembling of vsel{ge, gt, eq, vs} instructions. This adds a new decoder table/namespace 'VFPV8', as these instructions have their top 4 bits as 0b1111, while other Thumb instructions have 0b1110. llvm-svn: 185642
2013-07-04 22:57:20 +08:00
Add MC support for the v8fp instructions: vmaxnm and vminnm. llvm-svn: 185767
2013-07-07 04:50:18 +08:00
def D : ADbInp<0b11100, opc, 0,
Add support for MC assembling and disassembling of vsel{ge, gt, eq, vs} instructions. This adds a new decoder table/namespace 'VFPV8', as these instructions have their top 4 bits as 0b1111, while other Thumb instructions have 0b1110. llvm-svn: 185642
2013-07-04 22:57:20 +08:00
(outs DPR:$Dd), (ins DPR:$Dn, DPR:$Dm),
NoItinerary, !strconcat("vsel", op, ".f64\t$Dd, $Dn, $Dm"),
[ARMv8] Add CodeGen support for VSEL. This uses the ARMcmov pattern that Tim cleaned up in r188995. Thanks to Simon Tatham for his floating point help! llvm-svn: 189024
2013-08-22 23:29:11 +08:00
[(set DPR:$Dd, (ARMcmov (f64 DPR:$Dm), (f64 DPR:$Dn), CC))]>,
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
Requires<[HasFPARMv8, HasDPVFP]>;
Add support for MC assembling and disassembling of vsel{ge, gt, eq, vs} instructions. This adds a new decoder table/namespace 'VFPV8', as these instructions have their top 4 bits as 0b1111, while other Thumb instructions have 0b1110. llvm-svn: 185642
2013-07-04 22:57:20 +08:00
}
}
[ARMv8] Add CodeGen support for VSEL. This uses the ARMcmov pattern that Tim cleaned up in r188995. Thanks to Simon Tatham for his floating point help! llvm-svn: 189024
2013-08-22 23:29:11 +08:00
// The CC constants here match ARMCC::CondCodes.
defm VSELGT : vsel_inst<"gt", 0b11, 12>;
defm VSELGE : vsel_inst<"ge", 0b10, 10>;
defm VSELEQ : vsel_inst<"eq", 0b00, 0>;
defm VSELVS : vsel_inst<"vs", 0b01, 6>;
Add support for MC assembling and disassembling of vsel{ge, gt, eq, vs} instructions. This adds a new decoder table/namespace 'VFPV8', as these instructions have their top 4 bits as 0b1111, while other Thumb instructions have 0b1110. llvm-svn: 185642
2013-07-04 22:57:20 +08:00
[ARMv8] Add CodeGen for VMAXNM/VMINNM. llvm-svn: 189103
2013-08-23 20:01:13 +08:00
multiclass vmaxmin_inst<string op, bit opc, SDNode SD> {
Add MC support for the v8fp instructions: vmaxnm and vminnm. llvm-svn: 185767
2013-07-07 04:50:18 +08:00
let DecoderNamespace = "VFPV8", PostEncoderMethod = "" in {
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def H : AHbInp<0b11101, 0b00, opc,
(outs SPR:$Sd), (ins SPR:$Sn, SPR:$Sm),
NoItinerary, !strconcat(op, ".f16\t$Sd, $Sn, $Sm"),
[]>,
Requires<[HasFullFP16]>;
Add MC support for the v8fp instructions: vmaxnm and vminnm. llvm-svn: 185767
2013-07-07 04:50:18 +08:00
def S : ASbInp<0b11101, 0b00, opc,
(outs SPR:$Sd), (ins SPR:$Sn, SPR:$Sm),
NoItinerary, !strconcat(op, ".f32\t$Sd, $Sn, $Sm"),
[ARMv8] Add CodeGen for VMAXNM/VMINNM. llvm-svn: 189103
2013-08-23 20:01:13 +08:00
[(set SPR:$Sd, (SD SPR:$Sn, SPR:$Sm))]>,
[ARMv8] Change hasV8Fp to hasFPARMv8, and other command line options to be more consistent. llvm-svn: 190692
2013-09-13 21:46:57 +08:00
Requires<[HasFPARMv8]>;
Add MC support for the v8fp instructions: vmaxnm and vminnm. llvm-svn: 185767
2013-07-07 04:50:18 +08:00
def D : ADbInp<0b11101, 0b00, opc,
(outs DPR:$Dd), (ins DPR:$Dn, DPR:$Dm),
NoItinerary, !strconcat(op, ".f64\t$Dd, $Dn, $Dm"),
[ARMv8] Add CodeGen for VMAXNM/VMINNM. llvm-svn: 189103
2013-08-23 20:01:13 +08:00
[(set DPR:$Dd, (f64 (SD (f64 DPR:$Dn), (f64 DPR:$Dm))))]>,
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
Requires<[HasFPARMv8, HasDPVFP]>;
Add MC support for the v8fp instructions: vmaxnm and vminnm. llvm-svn: 185767
2013-07-07 04:50:18 +08:00
}
}
[ARM] Replace ARMISD::VMINNM/VMAXNM with ISD::FMINNUM/FMAXNUM NFCI. This replaces another custom ISDNode with a generic equivalent. llvm-svn: 244591
2015-08-11 20:06:22 +08:00
defm VMAXNM : vmaxmin_inst<"vmaxnm", 0, fmaxnum>;
defm VMINNM : vmaxmin_inst<"vminnm", 1, fminnum>;
Add MC support for the v8fp instructions: vmaxnm and vminnm. llvm-svn: 185767
2013-07-07 04:50:18 +08:00
match a reassociated form of fnmul. This implements CodeGen/ARM/fnmul.ll llvm-svn: 36660
2007-05-03 08:32:00 +08:00
// Match reassociated forms only if not sign dependent rounding.
fix a bunch of partially ambiguous patterns on ARM. As an example, this: (set DPR:$dst, (fsub (fneg (fmul DPR:$a, DPR:$b)), DPR:$dstin)) is ambiguous because DPR contains both f64 and v2f32. tblgen currently accidentally picks f64 because it's first in the regclass. llvm-svn: 97955
2010-03-09 02:51:21 +08:00
def : Pat<(fmul (fneg DPR:$a), (f64 DPR:$b)),
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
(VNMULD DPR:$a, DPR:$b)>,
Requires<[NoHonorSignDependentRounding,HasDPVFP]>;
match a reassociated form of fnmul. This implements CodeGen/ARM/fnmul.ll llvm-svn: 36660
2007-05-03 08:32:00 +08:00
def : Pat<(fmul (fneg SPR:$a), SPR:$b),
Use Unified Assembly Syntax for the ARM backend. llvm-svn: 86494
2009-11-09 08:11:35 +08:00
(VNMULS SPR:$a, SPR:$b)>, Requires<[NoHonorSignDependentRounding]>;
match a reassociated form of fnmul. This implements CodeGen/ARM/fnmul.ll llvm-svn: 36660
2007-05-03 08:32:00 +08:00
Add encoding for VSUB and VCMP. Fear not! I'm going to try a refactoring right now. :) llvm-svn: 116359
2010-10-13 06:55:35 +08:00
// These are encoded as unary instructions.
Split fpscr into two registers: FPSCR and FPSCR_NZCV. The fpscr register contains both flags (set by FP operations/comparisons) and control bits. The control bits (FPSCR) should be reserved, since they're always available and needn't be defined before use. The flag bits (FPSCR_NZCV) should like to be unreserved so they can be hoisted by MachineCSE. This fixes PR12165. llvm-svn: 152076
2012-03-06 08:19:55 +08:00
let Defs = [FPSCR_NZCV] in {
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VCMPED : ADuI<0b11101, 0b11, 0b0100, 0b11, 0,
(outs), (ins DPR:$Dd, DPR:$Dm),
IIC_fpCMP64, "vcmpe", ".f64\t$Dd, $Dm",
[ARM] Use VCMP, not VCMPE, for floating point equality comparisons When generating a floating point comparison we currently unconditionally generate VCMPE. This has the sideeffect of setting the cumulative Invalid bit in FPSCR if any of the operands are QNaN. It is expected that use of a relational predicate on a QNaN value should raise Invalid. Quoting from the C standard: The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of relationships the less, greater, equal and is true. Relational operators may raise the floating-point exception when argument values are NaNs. The standard doesn't explicitly state the expectation for equality operators, but the implication and obvious expectation is that equality operators should not raise Invalid on a QNaN input, as those predicates are wholly defined on unordered inputs (to return not equal). Therefore, add a new operand to ARMISD::FPCMP and FPCMPZ indicating if QNaN should raise Invalid, and pipe that through to TableGen. llvm-svn: 294945
2017-02-13 20:32:47 +08:00
[(arm_cmpfp DPR:$Dd, (f64 DPR:$Dm), (i32 1))]>;
Refactor VCMP instructions. llvm-svn: 116379
2010-10-13 08:04:29 +08:00
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VCMPES : ASuI<0b11101, 0b11, 0b0100, 0b11, 0,
(outs), (ins SPR:$Sd, SPR:$Sm),
IIC_fpCMP32, "vcmpe", ".f32\t$Sd, $Sm",
[ARM] Use VCMP, not VCMPE, for floating point equality comparisons When generating a floating point comparison we currently unconditionally generate VCMPE. This has the sideeffect of setting the cumulative Invalid bit in FPSCR if any of the operands are QNaN. It is expected that use of a relational predicate on a QNaN value should raise Invalid. Quoting from the C standard: The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of relationships the less, greater, equal and is true. Relational operators may raise the floating-point exception when argument values are NaNs. The standard doesn't explicitly state the expectation for equality operators, but the implication and obvious expectation is that equality operators should not raise Invalid on a QNaN input, as those predicates are wholly defined on unordered inputs (to return not equal). Therefore, add a new operand to ARMISD::FPCMP and FPCMPZ indicating if QNaN should raise Invalid, and pipe that through to TableGen. llvm-svn: 294945
2017-02-13 20:32:47 +08:00
[(arm_cmpfp SPR:$Sd, SPR:$Sm, (i32 1))]> {
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
}
Add encoding for VSUB and VCMP. Fear not! I'm going to try a refactoring right now. :) llvm-svn: 116359
2010-10-13 06:55:35 +08:00
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VCMPEH : AHuI<0b11101, 0b11, 0b0100, 0b11, 0,
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
(outs), (ins HPR:$Sd, HPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpCMP16, "vcmpe", ".f16\t$Sd, $Sm",
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
[(arm_cmpfp HPR:$Sd, HPR:$Sm, (i32 1))]>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VCMPD : ADuI<0b11101, 0b11, 0b0100, 0b01, 0,
(outs), (ins DPR:$Dd, DPR:$Dm),
IIC_fpCMP64, "vcmp", ".f64\t$Dd, $Dm",
[ARM] Use VCMP, not VCMPE, for floating point equality comparisons When generating a floating point comparison we currently unconditionally generate VCMPE. This has the sideeffect of setting the cumulative Invalid bit in FPSCR if any of the operands are QNaN. It is expected that use of a relational predicate on a QNaN value should raise Invalid. Quoting from the C standard: The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of relationships the less, greater, equal and is true. Relational operators may raise the floating-point exception when argument values are NaNs. The standard doesn't explicitly state the expectation for equality operators, but the implication and obvious expectation is that equality operators should not raise Invalid on a QNaN input, as those predicates are wholly defined on unordered inputs (to return not equal). Therefore, add a new operand to ARMISD::FPCMP and FPCMPZ indicating if QNaN should raise Invalid, and pipe that through to TableGen. llvm-svn: 294945
2017-02-13 20:32:47 +08:00
[(arm_cmpfp DPR:$Dd, (f64 DPR:$Dm), (i32 0))]>;
Add encoding for VSUB and VCMP. Fear not! I'm going to try a refactoring right now. :) llvm-svn: 116359
2010-10-13 06:55:35 +08:00
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VCMPS : ASuI<0b11101, 0b11, 0b0100, 0b01, 0,
(outs), (ins SPR:$Sd, SPR:$Sm),
IIC_fpCMP32, "vcmp", ".f32\t$Sd, $Sm",
[ARM] Use VCMP, not VCMPE, for floating point equality comparisons When generating a floating point comparison we currently unconditionally generate VCMPE. This has the sideeffect of setting the cumulative Invalid bit in FPSCR if any of the operands are QNaN. It is expected that use of a relational predicate on a QNaN value should raise Invalid. Quoting from the C standard: The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of relationships the less, greater, equal and is true. Relational operators may raise the floating-point exception when argument values are NaNs. The standard doesn't explicitly state the expectation for equality operators, but the implication and obvious expectation is that equality operators should not raise Invalid on a QNaN input, as those predicates are wholly defined on unordered inputs (to return not equal). Therefore, add a new operand to ARMISD::FPCMP and FPCMPZ indicating if QNaN should raise Invalid, and pipe that through to TableGen. llvm-svn: 294945
2017-02-13 20:32:47 +08:00
[(arm_cmpfp SPR:$Sd, SPR:$Sm, (i32 0))]> {
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Add encoding for VSUB and VCMP. Fear not! I'm going to try a refactoring right now. :) llvm-svn: 116359
2010-10-13 06:55:35 +08:00
}
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VCMPH : AHuI<0b11101, 0b11, 0b0100, 0b01, 0,
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
(outs), (ins HPR:$Sd, HPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpCMP16, "vcmp", ".f16\t$Sd, $Sm",
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
[(arm_cmpfp HPR:$Sd, HPR:$Sm, (i32 0))]>;
Split fpscr into two registers: FPSCR and FPSCR_NZCV. The fpscr register contains both flags (set by FP operations/comparisons) and control bits. The control bits (FPSCR) should be reserved, since they're always available and needn't be defined before use. The flag bits (FPSCR_NZCV) should like to be unreserved so they can be hoisted by MachineCSE. This fixes PR12165. llvm-svn: 152076
2012-03-06 08:19:55 +08:00
} // Defs = [FPSCR_NZCV]
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
//===----------------------------------------------------------------------===//
// FP Unary Operations.
//
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VABSD : ADuI<0b11101, 0b11, 0b0000, 0b11, 0,
(outs DPR:$Dd), (ins DPR:$Dm),
IIC_fpUNA64, "vabs", ".f64\t$Dd, $Dm",
[(set DPR:$Dd, (fabs (f64 DPR:$Dm)))]>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VABSS : ASuIn<0b11101, 0b11, 0b0000, 0b11, 0,
(outs SPR:$Sd), (ins SPR:$Sm),
IIC_fpUNA32, "vabs", ".f32\t$Sd, $Sm",
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
[(set SPR:$Sd, (fabs SPR:$Sm))]> {
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
}
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VABSH : AHuI<0b11101, 0b11, 0b0000, 0b11, 0,
(outs SPR:$Sd), (ins SPR:$Sm),
IIC_fpUNA16, "vabs", ".f16\t$Sd, $Sm",
[]>;
Split fpscr into two registers: FPSCR and FPSCR_NZCV. The fpscr register contains both flags (set by FP operations/comparisons) and control bits. The control bits (FPSCR) should be reserved, since they're always available and needn't be defined before use. The flag bits (FPSCR_NZCV) should like to be unreserved so they can be hoisted by MachineCSE. This fixes PR12165. llvm-svn: 152076
2012-03-06 08:19:55 +08:00
let Defs = [FPSCR_NZCV] in {
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VCMPEZD : ADuI<0b11101, 0b11, 0b0101, 0b11, 0,
(outs), (ins DPR:$Dd),
IIC_fpCMP64, "vcmpe", ".f64\t$Dd, #0",
[ARM] Use VCMP, not VCMPE, for floating point equality comparisons When generating a floating point comparison we currently unconditionally generate VCMPE. This has the sideeffect of setting the cumulative Invalid bit in FPSCR if any of the operands are QNaN. It is expected that use of a relational predicate on a QNaN value should raise Invalid. Quoting from the C standard: The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of relationships the less, greater, equal and is true. Relational operators may raise the floating-point exception when argument values are NaNs. The standard doesn't explicitly state the expectation for equality operators, but the implication and obvious expectation is that equality operators should not raise Invalid on a QNaN input, as those predicates are wholly defined on unordered inputs (to return not equal). Therefore, add a new operand to ARMISD::FPCMP and FPCMPZ indicating if QNaN should raise Invalid, and pipe that through to TableGen. llvm-svn: 294945
2017-02-13 20:32:47 +08:00
[(arm_cmpfp0 (f64 DPR:$Dd), (i32 1))]> {
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
let Inst{3-0} = 0b0000;
let Inst{5} = 0;
Add VCMPZ and VABS. llvm-svn: 116383
2010-10-13 08:38:07 +08:00
}
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VCMPEZS : ASuI<0b11101, 0b11, 0b0101, 0b11, 0,
(outs), (ins SPR:$Sd),
IIC_fpCMP32, "vcmpe", ".f32\t$Sd, #0",
[ARM] Use VCMP, not VCMPE, for floating point equality comparisons When generating a floating point comparison we currently unconditionally generate VCMPE. This has the sideeffect of setting the cumulative Invalid bit in FPSCR if any of the operands are QNaN. It is expected that use of a relational predicate on a QNaN value should raise Invalid. Quoting from the C standard: The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of relationships the less, greater, equal and is true. Relational operators may raise the floating-point exception when argument values are NaNs. The standard doesn't explicitly state the expectation for equality operators, but the implication and obvious expectation is that equality operators should not raise Invalid on a QNaN input, as those predicates are wholly defined on unordered inputs (to return not equal). Therefore, add a new operand to ARMISD::FPCMP and FPCMPZ indicating if QNaN should raise Invalid, and pipe that through to TableGen. llvm-svn: 294945
2017-02-13 20:32:47 +08:00
[(arm_cmpfp0 SPR:$Sd, (i32 1))]> {
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
let Inst{3-0} = 0b0000;
let Inst{5} = 0;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Add VCMPZ and VABS. llvm-svn: 116383
2010-10-13 08:38:07 +08:00
}
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VCMPEZH : AHuI<0b11101, 0b11, 0b0101, 0b11, 0,
[ARM] f16 vcmp fixes This adds f16 VCMP match rules and fixes the test cases. Differential Revision: https://reviews.llvm.org/D43291 llvm-svn: 325228
2018-02-15 18:33:07 +08:00
(outs), (ins HPR:$Sd),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpCMP16, "vcmpe", ".f16\t$Sd, #0",
[ARM] f16 vcmp fixes This adds f16 VCMP match rules and fixes the test cases. Differential Revision: https://reviews.llvm.org/D43291 llvm-svn: 325228
2018-02-15 18:33:07 +08:00
[(arm_cmpfp0 HPR:$Sd, (i32 1))]> {
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
let Inst{3-0} = 0b0000;
let Inst{5} = 0;
}
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VCMPZD : ADuI<0b11101, 0b11, 0b0101, 0b01, 0,
(outs), (ins DPR:$Dd),
IIC_fpCMP64, "vcmp", ".f64\t$Dd, #0",
[ARM] Use VCMP, not VCMPE, for floating point equality comparisons When generating a floating point comparison we currently unconditionally generate VCMPE. This has the sideeffect of setting the cumulative Invalid bit in FPSCR if any of the operands are QNaN. It is expected that use of a relational predicate on a QNaN value should raise Invalid. Quoting from the C standard: The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of relationships the less, greater, equal and is true. Relational operators may raise the floating-point exception when argument values are NaNs. The standard doesn't explicitly state the expectation for equality operators, but the implication and obvious expectation is that equality operators should not raise Invalid on a QNaN input, as those predicates are wholly defined on unordered inputs (to return not equal). Therefore, add a new operand to ARMISD::FPCMP and FPCMPZ indicating if QNaN should raise Invalid, and pipe that through to TableGen. llvm-svn: 294945
2017-02-13 20:32:47 +08:00
[(arm_cmpfp0 (f64 DPR:$Dd), (i32 0))]> {
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
let Inst{3-0} = 0b0000;
let Inst{5} = 0;
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
}
Add VCMP (VFP floating-point compare without 'E' bit set) for disassembly purpose. llvm-svn: 95560
2010-02-09 03:41:48 +08:00
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VCMPZS : ASuI<0b11101, 0b11, 0b0101, 0b01, 0,
(outs), (ins SPR:$Sd),
IIC_fpCMP32, "vcmp", ".f32\t$Sd, #0",
[ARM] Use VCMP, not VCMPE, for floating point equality comparisons When generating a floating point comparison we currently unconditionally generate VCMPE. This has the sideeffect of setting the cumulative Invalid bit in FPSCR if any of the operands are QNaN. It is expected that use of a relational predicate on a QNaN value should raise Invalid. Quoting from the C standard: The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of relationships the less, greater, equal and is true. Relational operators may raise the floating-point exception when argument values are NaNs. The standard doesn't explicitly state the expectation for equality operators, but the implication and obvious expectation is that equality operators should not raise Invalid on a QNaN input, as those predicates are wholly defined on unordered inputs (to return not equal). Therefore, add a new operand to ARMISD::FPCMP and FPCMPZ indicating if QNaN should raise Invalid, and pipe that through to TableGen. llvm-svn: 294945
2017-02-13 20:32:47 +08:00
[(arm_cmpfp0 SPR:$Sd, (i32 0))]> {
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
let Inst{3-0} = 0b0000;
let Inst{5} = 0;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
}
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VCMPZH : AHuI<0b11101, 0b11, 0b0101, 0b01, 0,
[ARM] f16 vcmp fixes This adds f16 VCMP match rules and fixes the test cases. Differential Revision: https://reviews.llvm.org/D43291 llvm-svn: 325228
2018-02-15 18:33:07 +08:00
(outs), (ins HPR:$Sd),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpCMP16, "vcmp", ".f16\t$Sd, #0",
[ARM] f16 vcmp fixes This adds f16 VCMP match rules and fixes the test cases. Differential Revision: https://reviews.llvm.org/D43291 llvm-svn: 325228
2018-02-15 18:33:07 +08:00
[(arm_cmpfp0 HPR:$Sd, (i32 0))]> {
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
let Inst{3-0} = 0b0000;
let Inst{5} = 0;
}
Split fpscr into two registers: FPSCR and FPSCR_NZCV. The fpscr register contains both flags (set by FP operations/comparisons) and control bits. The control bits (FPSCR) should be reserved, since they're always available and needn't be defined before use. The flag bits (FPSCR_NZCV) should like to be unreserved so they can be hoisted by MachineCSE. This fixes PR12165. llvm-svn: 152076
2012-03-06 08:19:55 +08:00
} // Defs = [FPSCR_NZCV]
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
Add encodings for VCVT instructions. llvm-svn: 116385
2010-10-13 08:56:35 +08:00
def VCVTDS : ASuI<0b11101, 0b11, 0b0111, 0b11, 0,
(outs DPR:$Dd), (ins SPR:$Sm),
IIC_fpCVTDS, "vcvt", ".f64.f32\t$Dd, $Sm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[(set DPR:$Dd, (fpextend SPR:$Sm))]>,
Sched<[WriteFPCVT]> {
Add encodings for VCVT instructions. llvm-svn: 116385
2010-10-13 08:56:35 +08:00
// Instruction operands.
bits<5> Dd;
bits<5> Sm;
// Encode instruction operands.
let Inst{3-0} = Sm{4-1};
let Inst{5} = Sm{0};
let Inst{15-12} = Dd{3-0};
let Inst{22} = Dd{4};
[ARM] Enable DP copy, load and store instructions for FPv4-SP The FPv4-SP floating-point unit is generally referred to as single-precision only, but it does have double-precision registers and load, store and GPR<->DPR move instructions which operate on them. This patch enables the use of these registers, the main advantage of which is that we now comply with the AAPCS-VFP calling convention. This partially reverts r209650, which added some AAPCS-VFP support, but did not handle return values or alignment of double arguments in registers. This patch also adds tests for Thumb2 code generation for floating-point instructions and intrinsics, which previously only existed for ARM. llvm-svn: 216172
2014-08-21 20:50:31 +08:00
let Predicates = [HasVFP2, HasDPVFP];
Add encodings for VCVT instructions. llvm-svn: 116385
2010-10-13 08:56:35 +08:00
}
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
Encode VFP arithmetic instructions. llvm-svn: 59016
2008-11-11 10:11:05 +08:00
// Special case encoding: bits 11-8 is 0b1011.
Add encodings for VCVT instructions. llvm-svn: 116385
2010-10-13 08:56:35 +08:00
def VCVTSD : VFPAI<(outs SPR:$Sd), (ins DPR:$Dm), VFPUnaryFrm,
IIC_fpCVTSD, "vcvt", ".f32.f64\t$Sd, $Dm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[(set SPR:$Sd, (fpround DPR:$Dm))]>,
Sched<[WriteFPCVT]> {
Add encodings for VCVT instructions. llvm-svn: 116385
2010-10-13 08:56:35 +08:00
// Instruction operands.
bits<5> Sd;
bits<5> Dm;
// Encode instruction operands.
let Inst{3-0} = Dm{3-0};
let Inst{5} = Dm{4};
let Inst{15-12} = Sd{4-1};
let Inst{22} = Sd{0};
Encode VFP arithmetic instructions. llvm-svn: 59016
2008-11-11 10:11:05 +08:00
let Inst{27-23} = 0b11101;
let Inst{21-16} = 0b110111;
let Inst{11-8} = 0b1011;
Modified encoding bits specification for VFP instructions. In particular, the D bit (Inst{22}) and the M bit (Inst{5}) should be left unspecified. For binary format instructions, Inst{6} and Inst{4} need to specified for proper decodings. llvm-svn: 94855
2010-01-30 07:21:10 +08:00
let Inst{7-6} = 0b11;
let Inst{4} = 0;
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
let Predicates = [HasVFP2, HasDPVFP];
Encode VFP arithmetic instructions. llvm-svn: 59016
2008-11-11 10:11:05 +08:00
}
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
[ARM] Armv8.2-A FP16 code generation (part 1/3) This is the groundwork for Armv8.2-A FP16 code generation . Clang passes and returns _Float16 values as floats, together with the required bitconverts and truncs etc. to implement correct AAPCS behaviour, see D42318. We will implement half-precision argument passing/returning lowering in the ARM backend soon, but for now this means that this: _Float16 sub(_Float16 a, _Float16 b) { return a + b; } gets lowered to this: define float @sub(float %a.coerce, float %b.coerce) { entry: %0 = bitcast float %a.coerce to i32 %tmp.0.extract.trunc = trunc i32 %0 to i16 %1 = bitcast i16 %tmp.0.extract.trunc to half <SNIP> %add = fadd half %1, %3 <SNIP> } When FullFP16 is *not* supported, we don't make f16 a legal type, and we get legalization for "free", i.e. nothing changes and everything works as before. And also f16 argument passing/returning is handled. When FullFP16 is supported, we do make f16 a legal type, and have 2 places that we need to patch up: f16 argument passing and returning, which involves minor tweaks to avoid unnecessary code generation for some bitcasts. As a "demonstrator" that this works for the different FP16, FullFP16, softfp modes, etc., I've added match rules to the VSUB instruction description showing that we can codegen this instruction from IR, but more importantly, also to some conversion instructions. These conversions were causing issue before in the FP16 and FullFP16 cases. I've also added match rules to the VLDRH and VSTRH desriptions, so that we can actually compile the entire half-precision sub code example above. This showed that these loads and stores had the wrong addressing mode specified: AddrMode5 instead of AddrMode5FP16, which turned out not be implemented at all, so that has also been added. This is the minimal patch that shows all the different moving parts. In patch 2/3 I will add some efficient lowering of bitcasts, and in 2/3 I will add the remaining Armv8.2-A FP16 instruction descriptions. Thanks to Sam Parker and Oliver Stannard for their help and reviews! Differential Revision: https://reviews.llvm.org/D38315 llvm-svn: 323512
2018-01-26 17:26:40 +08:00
// Between half, single and double-precision.
The names of VFP variants of half-to-float conversion instructions were reversed. This leads to wrong codegen for float-to-half conversion intrinsics which are used to support storage-only fp16 type. NEON variants of same instructions are fine. llvm-svn: 161907
2012-08-15 07:36:01 +08:00
def VCVTBHS: ASuI<0b11101, 0b11, 0b0010, 0b01, 0, (outs SPR:$Sd), (ins SPR:$Sm),
Provide operand encoding information for half-precision VCVT instructions. Found by randomized testing. llvm-svn: 138273
2011-08-23 05:34:00 +08:00
/* FIXME */ IIC_fpCVTSH, "vcvtb", ".f32.f16\t$Sd, $Sm",
[ARM] f16 conversions This is a follow up of r324321, adding f16 <-> f32 and f16 <-> f64 conversion match patterns. Differential Revision: https://reviews.llvm.org/D42954 llvm-svn: 324360
2018-02-07 00:28:43 +08:00
[/* Intentionally left blank, see patterns below */]>,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasFP16]>,
Sched<[WriteFPCVT]>;
Get rid of target-specific nodes for fp16 <-> fp32 conversion. llvm-svn: 98888
2010-03-19 06:35:37 +08:00
[ARM] FP16Pat and FullFP16Pat patterns. NFC. Create and use FP16Pat FullFP16Pat helper patterns to make the difference explicit. Differential Revision: https://reviews.llvm.org/D42634 llvm-svn: 323640
2018-01-29 19:28:06 +08:00
def : FullFP16Pat<(f32 (fpextend HPR:$Sm)),
(VCVTBHS (COPY_TO_REGCLASS HPR:$Sm, SPR))>;
[ARM] f16 conversions This is a follow up of r324321, adding f16 <-> f32 and f16 <-> f64 conversion match patterns. Differential Revision: https://reviews.llvm.org/D42954 llvm-svn: 324360
2018-02-07 00:28:43 +08:00
def : FP16Pat<(f16_to_fp GPR:$a),
(VCVTBHS (COPY_TO_REGCLASS GPR:$a, SPR))>;
[ARM] Armv8.2-A FP16 code generation (part 1/3) This is the groundwork for Armv8.2-A FP16 code generation . Clang passes and returns _Float16 values as floats, together with the required bitconverts and truncs etc. to implement correct AAPCS behaviour, see D42318. We will implement half-precision argument passing/returning lowering in the ARM backend soon, but for now this means that this: _Float16 sub(_Float16 a, _Float16 b) { return a + b; } gets lowered to this: define float @sub(float %a.coerce, float %b.coerce) { entry: %0 = bitcast float %a.coerce to i32 %tmp.0.extract.trunc = trunc i32 %0 to i16 %1 = bitcast i16 %tmp.0.extract.trunc to half <SNIP> %add = fadd half %1, %3 <SNIP> } When FullFP16 is *not* supported, we don't make f16 a legal type, and we get legalization for "free", i.e. nothing changes and everything works as before. And also f16 argument passing/returning is handled. When FullFP16 is supported, we do make f16 a legal type, and have 2 places that we need to patch up: f16 argument passing and returning, which involves minor tweaks to avoid unnecessary code generation for some bitcasts. As a "demonstrator" that this works for the different FP16, FullFP16, softfp modes, etc., I've added match rules to the VSUB instruction description showing that we can codegen this instruction from IR, but more importantly, also to some conversion instructions. These conversions were causing issue before in the FP16 and FullFP16 cases. I've also added match rules to the VLDRH and VSTRH desriptions, so that we can actually compile the entire half-precision sub code example above. This showed that these loads and stores had the wrong addressing mode specified: AddrMode5 instead of AddrMode5FP16, which turned out not be implemented at all, so that has also been added. This is the minimal patch that shows all the different moving parts. In patch 2/3 I will add some efficient lowering of bitcasts, and in 2/3 I will add the remaining Armv8.2-A FP16 instruction descriptions. Thanks to Sam Parker and Oliver Stannard for their help and reviews! Differential Revision: https://reviews.llvm.org/D38315 llvm-svn: 323512
2018-01-26 17:26:40 +08:00
The names of VFP variants of half-to-float conversion instructions were reversed. This leads to wrong codegen for float-to-half conversion intrinsics which are used to support storage-only fp16 type. NEON variants of same instructions are fine. llvm-svn: 161907
2012-08-15 07:36:01 +08:00
def VCVTBSH: ASuI<0b11101, 0b11, 0b0011, 0b01, 0, (outs SPR:$Sd), (ins SPR:$Sm),
Provide operand encoding information for half-precision VCVT instructions. Found by randomized testing. llvm-svn: 138273
2011-08-23 05:34:00 +08:00
/* FIXME */ IIC_fpCVTHS, "vcvtb", ".f16.f32\t$Sd, $Sm",
[ARM] f16 conversions This is a follow up of r324321, adding f16 <-> f32 and f16 <-> f64 conversion match patterns. Differential Revision: https://reviews.llvm.org/D42954 llvm-svn: 324360
2018-02-07 00:28:43 +08:00
[/* Intentionally left blank, see patterns below */]>,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasFP16]>,
Sched<[WriteFPCVT]>;
Get rid of target-specific nodes for fp16 <-> fp32 conversion. llvm-svn: 98888
2010-03-19 06:35:37 +08:00
[ARM] f16 conversions This is a follow up of r324321, adding f16 <-> f32 and f16 <-> f64 conversion match patterns. Differential Revision: https://reviews.llvm.org/D42954 llvm-svn: 324360
2018-02-07 00:28:43 +08:00
def : FullFP16Pat<(f16 (fpround SPR:$Sm)),
(COPY_TO_REGCLASS (VCVTBSH SPR:$Sm), HPR)>;
def : FP16Pat<(fp_to_f16 SPR:$a),
(i32 (COPY_TO_REGCLASS (VCVTBSH SPR:$a), GPR))>;
The names of VFP variants of half-to-float conversion instructions were reversed. This leads to wrong codegen for float-to-half conversion intrinsics which are used to support storage-only fp16 type. NEON variants of same instructions are fine. llvm-svn: 161907
2012-08-15 07:36:01 +08:00
def VCVTTHS: ASuI<0b11101, 0b11, 0b0010, 0b11, 0, (outs SPR:$Sd), (ins SPR:$Sm),
Provide operand encoding information for half-precision VCVT instructions. Found by randomized testing. llvm-svn: 138273
2011-08-23 05:34:00 +08:00
/* FIXME */ IIC_fpCVTSH, "vcvtt", ".f32.f16\t$Sd, $Sm",
[ARM] Flag vcvt{t,b} with an f16 type specifier as part of the FP16 extension Additionally correct the Cortex-R7 definition to allow the FP16 feature. llvm-svn: 254900
2015-12-07 18:54:36 +08:00
[/* For disassembly only; pattern left blank */]>,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasFP16]>,
Sched<[WriteFPCVT]>;
Added vcvtb/vcvtt (between half-precision and single-precision, VFP). For disassembly only. A8.6.300 llvm-svn: 95669
2010-02-10 01:21:56 +08:00
The names of VFP variants of half-to-float conversion instructions were reversed. This leads to wrong codegen for float-to-half conversion intrinsics which are used to support storage-only fp16 type. NEON variants of same instructions are fine. llvm-svn: 161907
2012-08-15 07:36:01 +08:00
def VCVTTSH: ASuI<0b11101, 0b11, 0b0011, 0b11, 0, (outs SPR:$Sd), (ins SPR:$Sm),
Provide operand encoding information for half-precision VCVT instructions. Found by randomized testing. llvm-svn: 138273
2011-08-23 05:34:00 +08:00
/* FIXME */ IIC_fpCVTHS, "vcvtt", ".f16.f32\t$Sd, $Sm",
[ARM] Flag vcvt{t,b} with an f16 type specifier as part of the FP16 extension Additionally correct the Cortex-R7 definition to allow the FP16 feature. llvm-svn: 254900
2015-12-07 18:54:36 +08:00
[/* For disassembly only; pattern left blank */]>,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasFP16]>,
Sched<[WriteFPCVT]>;
Added vcvtb/vcvtt (between half-precision and single-precision, VFP). For disassembly only. A8.6.300 llvm-svn: 95669
2010-02-10 01:21:56 +08:00
Add a V8FP instruction 'vcvt{b,t}' to convert between half and double precision. llvm-svn: 185620
2013-07-04 18:04:08 +08:00
def VCVTBHD : ADuI<0b11101, 0b11, 0b0010, 0b01, 0,
(outs DPR:$Dd), (ins SPR:$Sm),
NoItinerary, "vcvtb", ".f64.f16\t$Dd, $Sm",
[ARM] f16 conversions This is a follow up of r324321, adding f16 <-> f32 and f16 <-> f64 conversion match patterns. Differential Revision: https://reviews.llvm.org/D42954 llvm-svn: 324360
2018-02-07 00:28:43 +08:00
[/* Intentionally left blank, see patterns below */]>,
Requires<[HasFPARMv8, HasDPVFP]>,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Sched<[WriteFPCVT]> {
Add a V8FP instruction 'vcvt{b,t}' to convert between half and double precision. llvm-svn: 185620
2013-07-04 18:04:08 +08:00
// Instruction operands.
bits<5> Sm;
// Encode instruction operands.
let Inst{3-0} = Sm{4-1};
let Inst{5} = Sm{0};
}
[ARM] f16 conversions This is a follow up of r324321, adding f16 <-> f32 and f16 <-> f64 conversion match patterns. Differential Revision: https://reviews.llvm.org/D42954 llvm-svn: 324360
2018-02-07 00:28:43 +08:00
def : FullFP16Pat<(f64 (fpextend HPR:$Sm)),
(VCVTBHD (COPY_TO_REGCLASS HPR:$Sm, SPR))>;
def : FP16Pat<(f64 (f16_to_fp GPR:$a)),
(VCVTBHD (COPY_TO_REGCLASS GPR:$a, SPR))>;
Add a V8FP instruction 'vcvt{b,t}' to convert between half and double precision. llvm-svn: 185620
2013-07-04 18:04:08 +08:00
def VCVTBDH : ADuI<0b11101, 0b11, 0b0011, 0b01, 0,
(outs SPR:$Sd), (ins DPR:$Dm),
NoItinerary, "vcvtb", ".f16.f64\t$Sd, $Dm",
[ARM] f16 conversions This is a follow up of r324321, adding f16 <-> f32 and f16 <-> f64 conversion match patterns. Differential Revision: https://reviews.llvm.org/D42954 llvm-svn: 324360
2018-02-07 00:28:43 +08:00
[/* Intentionally left blank, see patterns below */]>,
Requires<[HasFPARMv8, HasDPVFP]> {
Add a V8FP instruction 'vcvt{b,t}' to convert between half and double precision. llvm-svn: 185620
2013-07-04 18:04:08 +08:00
// Instruction operands.
bits<5> Sd;
bits<5> Dm;
// Encode instruction operands.
let Inst{3-0} = Dm{3-0};
let Inst{5} = Dm{4};
let Inst{15-12} = Sd{4-1};
let Inst{22} = Sd{0};
}
[ARM] f16 conversions This is a follow up of r324321, adding f16 <-> f32 and f16 <-> f64 conversion match patterns. Differential Revision: https://reviews.llvm.org/D42954 llvm-svn: 324360
2018-02-07 00:28:43 +08:00
def : FullFP16Pat<(f16 (fpround DPR:$Dm)),
(COPY_TO_REGCLASS (VCVTBDH DPR:$Dm), HPR)>;
def : FP16Pat<(fp_to_f16 (f64 DPR:$a)),
(i32 (COPY_TO_REGCLASS (VCVTBDH DPR:$a), GPR))>;
Add a V8FP instruction 'vcvt{b,t}' to convert between half and double precision. llvm-svn: 185620
2013-07-04 18:04:08 +08:00
def VCVTTHD : ADuI<0b11101, 0b11, 0b0010, 0b11, 0,
(outs DPR:$Dd), (ins SPR:$Sm),
NoItinerary, "vcvtt", ".f64.f16\t$Dd, $Sm",
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
[]>, Requires<[HasFPARMv8, HasDPVFP]> {
Add a V8FP instruction 'vcvt{b,t}' to convert between half and double precision. llvm-svn: 185620
2013-07-04 18:04:08 +08:00
// Instruction operands.
bits<5> Sm;
// Encode instruction operands.
let Inst{3-0} = Sm{4-1};
let Inst{5} = Sm{0};
}
def VCVTTDH : ADuI<0b11101, 0b11, 0b0011, 0b11, 0,
(outs SPR:$Sd), (ins DPR:$Dm),
NoItinerary, "vcvtt", ".f16.f64\t$Sd, $Dm",
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
[]>, Requires<[HasFPARMv8, HasDPVFP]> {
Add a V8FP instruction 'vcvt{b,t}' to convert between half and double precision. llvm-svn: 185620
2013-07-04 18:04:08 +08:00
// Instruction operands.
bits<5> Sd;
bits<5> Dm;
// Encode instruction operands.
let Inst{15-12} = Sd{4-1};
let Inst{22} = Sd{0};
let Inst{3-0} = Dm{3-0};
let Inst{5} = Dm{4};
}
[AArch32] Add patterns for VCVT{A,N,P,M}. Patterns for lowering libm calls to VCVT{A,N,P,M} are also included. Phabricator Revision: http://reviews.llvm.org/D5033 llvm-svn: 216388
2014-08-26 00:56:33 +08:00
multiclass vcvt_inst<string opc, bits<2> rm,
SDPatternOperator node = null_frag> {
Add Thumb tests for the ARMv8 FP instructions that I recently added. Also, fix the namespace for two instructions that I missed previously. llvm-svn: 186572
2013-07-18 18:20:25 +08:00
let PostEncoderMethod = "", DecoderNamespace = "VFPV8" in {
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def SH : AHuInp<0b11101, 0b11, 0b1100, 0b11, 0,
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
(outs SPR:$Sd), (ins HPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
NoItinerary, !strconcat("vcvt", opc, ".s32.f16\t$Sd, $Sm"),
[]>,
Requires<[HasFullFP16]> {
let Inst{17-16} = rm;
}
def UH : AHuInp<0b11101, 0b11, 0b1100, 0b01, 0,
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
(outs SPR:$Sd), (ins HPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
NoItinerary, !strconcat("vcvt", opc, ".u32.f16\t$Sd, $Sm"),
[]>,
Requires<[HasFullFP16]> {
let Inst{17-16} = rm;
}
Add MC assembly/disassembly support for VCVT{A, N, P, M} to V8FP. llvm-svn: 185922
2013-07-09 17:59:04 +08:00
def SS : ASuInp<0b11101, 0b11, 0b1100, 0b11, 0,
(outs SPR:$Sd), (ins SPR:$Sm),
NoItinerary, !strconcat("vcvt", opc, ".s32.f32\t$Sd, $Sm"),
[ARM] Remove target-specific ITOFP/FPTOI nodes Anton tried this 5 years ago but it was reverted due to extra VMOVs being emitted. This can be easily fixed with a liberal application of patterns - matching loads/stores and extractelts. llvm-svn: 232958
2015-03-24 00:15:16 +08:00
[]>,
[AArch32] Add patterns for VCVT{A,N,P,M}. Patterns for lowering libm calls to VCVT{A,N,P,M} are also included. Phabricator Revision: http://reviews.llvm.org/D5033 llvm-svn: 216388
2014-08-26 00:56:33 +08:00
Requires<[HasFPARMv8]> {
Add MC assembly/disassembly support for VCVT{A, N, P, M} to V8FP. llvm-svn: 185922
2013-07-09 17:59:04 +08:00
let Inst{17-16} = rm;
}
def US : ASuInp<0b11101, 0b11, 0b1100, 0b01, 0,
(outs SPR:$Sd), (ins SPR:$Sm),
NoItinerary, !strconcat("vcvt", opc, ".u32.f32\t$Sd, $Sm"),
[ARM] Remove target-specific ITOFP/FPTOI nodes Anton tried this 5 years ago but it was reverted due to extra VMOVs being emitted. This can be easily fixed with a liberal application of patterns - matching loads/stores and extractelts. llvm-svn: 232958
2015-03-24 00:15:16 +08:00
[]>,
[AArch32] Add patterns for VCVT{A,N,P,M}. Patterns for lowering libm calls to VCVT{A,N,P,M} are also included. Phabricator Revision: http://reviews.llvm.org/D5033 llvm-svn: 216388
2014-08-26 00:56:33 +08:00
Requires<[HasFPARMv8]> {
Add MC assembly/disassembly support for VCVT{A, N, P, M} to V8FP. llvm-svn: 185922
2013-07-09 17:59:04 +08:00
let Inst{17-16} = rm;
}
def SD : ASuInp<0b11101, 0b11, 0b1100, 0b11, 0,
(outs SPR:$Sd), (ins DPR:$Dm),
NoItinerary, !strconcat("vcvt", opc, ".s32.f64\t$Sd, $Dm"),
[ARM] Remove target-specific ITOFP/FPTOI nodes Anton tried this 5 years ago but it was reverted due to extra VMOVs being emitted. This can be easily fixed with a liberal application of patterns - matching loads/stores and extractelts. llvm-svn: 232958
2015-03-24 00:15:16 +08:00
[]>,
[AArch32] Add patterns for VCVT{A,N,P,M}. Patterns for lowering libm calls to VCVT{A,N,P,M} are also included. Phabricator Revision: http://reviews.llvm.org/D5033 llvm-svn: 216388
2014-08-26 00:56:33 +08:00
Requires<[HasFPARMv8, HasDPVFP]> {
Add MC assembly/disassembly support for VCVT{A, N, P, M} to V8FP. llvm-svn: 185922
2013-07-09 17:59:04 +08:00
bits<5> Dm;
let Inst{17-16} = rm;
// Encode instruction operands
let Inst{3-0} = Dm{3-0};
let Inst{5} = Dm{4};
let Inst{8} = 1;
}
def UD : ASuInp<0b11101, 0b11, 0b1100, 0b01, 0,
(outs SPR:$Sd), (ins DPR:$Dm),
NoItinerary, !strconcat("vcvt", opc, ".u32.f64\t$Sd, $Dm"),
[ARM] Remove target-specific ITOFP/FPTOI nodes Anton tried this 5 years ago but it was reverted due to extra VMOVs being emitted. This can be easily fixed with a liberal application of patterns - matching loads/stores and extractelts. llvm-svn: 232958
2015-03-24 00:15:16 +08:00
[]>,
[AArch32] Add patterns for VCVT{A,N,P,M}. Patterns for lowering libm calls to VCVT{A,N,P,M} are also included. Phabricator Revision: http://reviews.llvm.org/D5033 llvm-svn: 216388
2014-08-26 00:56:33 +08:00
Requires<[HasFPARMv8, HasDPVFP]> {
Add MC assembly/disassembly support for VCVT{A, N, P, M} to V8FP. llvm-svn: 185922
2013-07-09 17:59:04 +08:00
bits<5> Dm;
let Inst{17-16} = rm;
// Encode instruction operands
let Inst{3-0} = Dm{3-0};
let Inst{5} = Dm{4};
let Inst{8} = 1;
}
}
[ARM] Remove target-specific ITOFP/FPTOI nodes Anton tried this 5 years ago but it was reverted due to extra VMOVs being emitted. This can be easily fixed with a liberal application of patterns - matching loads/stores and extractelts. llvm-svn: 232958
2015-03-24 00:15:16 +08:00
let Predicates = [HasFPARMv8] in {
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
let Predicates = [HasFullFP16] in {
def : Pat<(i32 (fp_to_sint (node HPR:$a))),
(COPY_TO_REGCLASS
(!cast<Instruction>(NAME#"SH") HPR:$a),
GPR)>;
def : Pat<(i32 (fp_to_uint (node HPR:$a))),
(COPY_TO_REGCLASS
(!cast<Instruction>(NAME#"UH") HPR:$a),
GPR)>;
}
[ARM] Remove target-specific ITOFP/FPTOI nodes Anton tried this 5 years ago but it was reverted due to extra VMOVs being emitted. This can be easily fixed with a liberal application of patterns - matching loads/stores and extractelts. llvm-svn: 232958
2015-03-24 00:15:16 +08:00
def : Pat<(i32 (fp_to_sint (node SPR:$a))),
(COPY_TO_REGCLASS
(!cast<Instruction>(NAME#"SS") SPR:$a),
GPR)>;
def : Pat<(i32 (fp_to_uint (node SPR:$a))),
(COPY_TO_REGCLASS
(!cast<Instruction>(NAME#"US") SPR:$a),
GPR)>;
}
let Predicates = [HasFPARMv8, HasDPVFP] in {
def : Pat<(i32 (fp_to_sint (node (f64 DPR:$a)))),
(COPY_TO_REGCLASS
(!cast<Instruction>(NAME#"SD") DPR:$a),
GPR)>;
def : Pat<(i32 (fp_to_uint (node (f64 DPR:$a)))),
(COPY_TO_REGCLASS
(!cast<Instruction>(NAME#"UD") DPR:$a),
GPR)>;
}
Add MC assembly/disassembly support for VCVT{A, N, P, M} to V8FP. llvm-svn: 185922
2013-07-09 17:59:04 +08:00
}
[SelectionDAG] Rename fextend -> fpextend, fround -> fpround, frnd -> fround The names of the tablegen defs now match the names of the ISD nodes. This makes the world a slightly saner place, as previously "fround" matched ISD::FP_ROUND and not ISD::FROUND. Differential Revision: https://reviews.llvm.org/D23597 llvm-svn: 279129
2016-08-19 04:08:15 +08:00
defm VCVTA : vcvt_inst<"a", 0b00, fround>;
Add MC assembly/disassembly support for VCVT{A, N, P, M} to V8FP. llvm-svn: 185922
2013-07-09 17:59:04 +08:00
defm VCVTN : vcvt_inst<"n", 0b01>;
[AArch32] Add patterns for VCVT{A,N,P,M}. Patterns for lowering libm calls to VCVT{A,N,P,M} are also included. Phabricator Revision: http://reviews.llvm.org/D5033 llvm-svn: 216388
2014-08-26 00:56:33 +08:00
defm VCVTP : vcvt_inst<"p", 0b10, fceil>;
defm VCVTM : vcvt_inst<"m", 0b11, ffloor>;
Add MC assembly/disassembly support for VCVT{A, N, P, M} to V8FP. llvm-svn: 185922
2013-07-09 17:59:04 +08:00
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VNEGD : ADuI<0b11101, 0b11, 0b0001, 0b01, 0,
(outs DPR:$Dd), (ins DPR:$Dm),
IIC_fpUNA64, "vneg", ".f64\t$Dd, $Dm",
[(set DPR:$Dd, (fneg (f64 DPR:$Dm)))]>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VNEGS : ASuIn<0b11101, 0b11, 0b0001, 0b01, 0,
(outs SPR:$Sd), (ins SPR:$Sm),
IIC_fpUNA32, "vneg", ".f32\t$Sd, $Sm",
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
[(set SPR:$Sd, (fneg SPR:$Sm))]> {
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
}
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VNEGH : AHuI<0b11101, 0b11, 0b0001, 0b01, 0,
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
(outs HPR:$Sd), (ins HPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpUNA16, "vneg", ".f16\t$Sd, $Sm",
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
[(set HPR:$Sd, (fneg HPR:$Sm))]>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
[AArch32] Add support for FP rounding operations for ARMv8/AArch32. Phabricator Revision: http://reviews.llvm.org/D4935 llvm-svn: 215772
2014-08-16 05:38:16 +08:00
multiclass vrint_inst_zrx<string opc, bit op, bit op2, SDPatternOperator node> {
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def H : AHuI<0b11101, 0b11, 0b0110, 0b11, 0,
(outs SPR:$Sd), (ins SPR:$Sm),
NoItinerary, !strconcat("vrint", opc), ".f16\t$Sd, $Sm",
[]>,
Requires<[HasFullFP16]> {
let Inst{7} = op2;
let Inst{16} = op;
}
Add MC assembly/disassembly support for VRINT{Z, X, R} to V8FP. llvm-svn: 185926
2013-07-09 19:03:21 +08:00
def S : ASuI<0b11101, 0b11, 0b0110, 0b11, 0,
(outs SPR:$Sd), (ins SPR:$Sm),
NoItinerary, !strconcat("vrint", opc), ".f32\t$Sd, $Sm",
[AArch32] Add support for FP rounding operations for ARMv8/AArch32. Phabricator Revision: http://reviews.llvm.org/D4935 llvm-svn: 215772
2014-08-16 05:38:16 +08:00
[(set (f32 SPR:$Sd), (node (f32 SPR:$Sm)))]>,
Requires<[HasFPARMv8]> {
Add MC assembly/disassembly support for VRINT{Z, X, R} to V8FP. llvm-svn: 185926
2013-07-09 19:03:21 +08:00
let Inst{7} = op2;
let Inst{16} = op;
}
def D : ADuI<0b11101, 0b11, 0b0110, 0b11, 0,
(outs DPR:$Dd), (ins DPR:$Dm),
NoItinerary, !strconcat("vrint", opc), ".f64\t$Dd, $Dm",
[AArch32] Add support for FP rounding operations for ARMv8/AArch32. Phabricator Revision: http://reviews.llvm.org/D4935 llvm-svn: 215772
2014-08-16 05:38:16 +08:00
[(set (f64 DPR:$Dd), (node (f64 DPR:$Dm)))]>,
Requires<[HasFPARMv8, HasDPVFP]> {
Add MC assembly/disassembly support for VRINT{Z, X, R} to V8FP. llvm-svn: 185926
2013-07-09 19:03:21 +08:00
let Inst{7} = op2;
let Inst{16} = op;
}
[ARMv8] Add some negative tests for the recent VFP/NEON instructions. Fix two issues I found while writing these tests. llvm-svn: 189341
2013-08-27 19:24:16 +08:00
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def : InstAlias<!strconcat("vrint", opc, "$p.f16.f16\t$Sd, $Sm"),
ARM target does not use printAliasInstr machinery which forces having special checks in ArmInstPrinter::printInstruction. This patch addresses this issue. Not all special checks could be removed: either they involve elaborated conditions under which the alias is emitted (e.g. ldm/stm on sp may be pop/push but only if the number of registers is >= 2) or the number of registers is multivalued (like happens again with ldm/stm) and they do not match the InstAlias pattern which assumes single-valued operands in the pattern. Patch by: Roger Ferrer Ibanez Differential Revision: http://reviews.llvm.org/D20237 llvm-svn: 271667
2016-06-03 21:19:43 +08:00
(!cast<Instruction>(NAME#"H") SPR:$Sd, SPR:$Sm, pred:$p), 0>,
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
Requires<[HasFullFP16]>;
[ARMv8] Add some negative tests for the recent VFP/NEON instructions. Fix two issues I found while writing these tests. llvm-svn: 189341
2013-08-27 19:24:16 +08:00
def : InstAlias<!strconcat("vrint", opc, "$p.f32.f32\t$Sd, $Sm"),
ARM target does not use printAliasInstr machinery which forces having special checks in ArmInstPrinter::printInstruction. This patch addresses this issue. Not all special checks could be removed: either they involve elaborated conditions under which the alias is emitted (e.g. ldm/stm on sp may be pop/push but only if the number of registers is >= 2) or the number of registers is multivalued (like happens again with ldm/stm) and they do not match the InstAlias pattern which assumes single-valued operands in the pattern. Patch by: Roger Ferrer Ibanez Differential Revision: http://reviews.llvm.org/D20237 llvm-svn: 271667
2016-06-03 21:19:43 +08:00
(!cast<Instruction>(NAME#"S") SPR:$Sd, SPR:$Sm, pred:$p), 0>,
ARM: mark various aliases with their architecture requirements. If an alias inherits directly from InstAlias then it doesn't get any default "Requires" values, so llvm-mc will allow it even on architectures that don't support the underlying instruction. This tidies up the obvious VFP and NEON cases I found. llvm-svn: 193340
2013-10-24 20:22:58 +08:00
Requires<[HasFPARMv8]>;
[ARMv8] Add some negative tests for the recent VFP/NEON instructions. Fix two issues I found while writing these tests. llvm-svn: 189341
2013-08-27 19:24:16 +08:00
def : InstAlias<!strconcat("vrint", opc, "$p.f64.f64\t$Dd, $Dm"),
ARM target does not use printAliasInstr machinery which forces having special checks in ArmInstPrinter::printInstruction. This patch addresses this issue. Not all special checks could be removed: either they involve elaborated conditions under which the alias is emitted (e.g. ldm/stm on sp may be pop/push but only if the number of registers is >= 2) or the number of registers is multivalued (like happens again with ldm/stm) and they do not match the InstAlias pattern which assumes single-valued operands in the pattern. Patch by: Roger Ferrer Ibanez Differential Revision: http://reviews.llvm.org/D20237 llvm-svn: 271667
2016-06-03 21:19:43 +08:00
(!cast<Instruction>(NAME#"D") DPR:$Dd, DPR:$Dm, pred:$p), 0>,
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
Requires<[HasFPARMv8,HasDPVFP]>;
Add MC assembly/disassembly support for VRINT{Z, X, R} to V8FP. llvm-svn: 185926
2013-07-09 19:03:21 +08:00
}
[AArch32] Add support for FP rounding operations for ARMv8/AArch32. Phabricator Revision: http://reviews.llvm.org/D4935 llvm-svn: 215772
2014-08-16 05:38:16 +08:00
defm VRINTZ : vrint_inst_zrx<"z", 0, 1, ftrunc>;
defm VRINTR : vrint_inst_zrx<"r", 0, 0, fnearbyint>;
defm VRINTX : vrint_inst_zrx<"x", 1, 0, frint>;
Add MC assembly/disassembly support for VRINT{Z, X, R} to V8FP. llvm-svn: 185926
2013-07-09 19:03:21 +08:00
[AArch32] Add support for FP rounding operations for ARMv8/AArch32. Phabricator Revision: http://reviews.llvm.org/D4935 llvm-svn: 215772
2014-08-16 05:38:16 +08:00
multiclass vrint_inst_anpm<string opc, bits<2> rm,
SDPatternOperator node = null_frag> {
Add Thumb tests for the ARMv8 FP instructions that I recently added. Also, fix the namespace for two instructions that I missed previously. llvm-svn: 186572
2013-07-18 18:20:25 +08:00
let PostEncoderMethod = "", DecoderNamespace = "VFPV8" in {
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def H : AHuInp<0b11101, 0b11, 0b1000, 0b01, 0,
(outs SPR:$Sd), (ins SPR:$Sm),
NoItinerary, !strconcat("vrint", opc, ".f16\t$Sd, $Sm"),
[]>,
Requires<[HasFullFP16]> {
let Inst{17-16} = rm;
}
Add MC assembly/disassembly support for VRINT{A, N, P, M} to V8FP. llvm-svn: 185929
2013-07-09 19:26:18 +08:00
def S : ASuInp<0b11101, 0b11, 0b1000, 0b01, 0,
(outs SPR:$Sd), (ins SPR:$Sm),
NoItinerary, !strconcat("vrint", opc, ".f32\t$Sd, $Sm"),
[AArch32] Add support for FP rounding operations for ARMv8/AArch32. Phabricator Revision: http://reviews.llvm.org/D4935 llvm-svn: 215772
2014-08-16 05:38:16 +08:00
[(set (f32 SPR:$Sd), (node (f32 SPR:$Sm)))]>,
Requires<[HasFPARMv8]> {
Add MC assembly/disassembly support for VRINT{A, N, P, M} to V8FP. llvm-svn: 185929
2013-07-09 19:26:18 +08:00
let Inst{17-16} = rm;
}
def D : ADuInp<0b11101, 0b11, 0b1000, 0b01, 0,
(outs DPR:$Dd), (ins DPR:$Dm),
NoItinerary, !strconcat("vrint", opc, ".f64\t$Dd, $Dm"),
[AArch32] Add support for FP rounding operations for ARMv8/AArch32. Phabricator Revision: http://reviews.llvm.org/D4935 llvm-svn: 215772
2014-08-16 05:38:16 +08:00
[(set (f64 DPR:$Dd), (node (f64 DPR:$Dm)))]>,
Requires<[HasFPARMv8, HasDPVFP]> {
Add MC assembly/disassembly support for VRINT{A, N, P, M} to V8FP. llvm-svn: 185929
2013-07-09 19:26:18 +08:00
let Inst{17-16} = rm;
}
}
def : InstAlias<!strconcat("vrint", opc, ".f32.f32\t$Sd, $Sm"),
ARM target does not use printAliasInstr machinery which forces having special checks in ArmInstPrinter::printInstruction. This patch addresses this issue. Not all special checks could be removed: either they involve elaborated conditions under which the alias is emitted (e.g. ldm/stm on sp may be pop/push but only if the number of registers is >= 2) or the number of registers is multivalued (like happens again with ldm/stm) and they do not match the InstAlias pattern which assumes single-valued operands in the pattern. Patch by: Roger Ferrer Ibanez Differential Revision: http://reviews.llvm.org/D20237 llvm-svn: 271667
2016-06-03 21:19:43 +08:00
(!cast<Instruction>(NAME#"S") SPR:$Sd, SPR:$Sm), 0>,
ARM: mark various aliases with their architecture requirements. If an alias inherits directly from InstAlias then it doesn't get any default "Requires" values, so llvm-mc will allow it even on architectures that don't support the underlying instruction. This tidies up the obvious VFP and NEON cases I found. llvm-svn: 193340
2013-10-24 20:22:58 +08:00
Requires<[HasFPARMv8]>;
Add MC assembly/disassembly support for VRINT{A, N, P, M} to V8FP. llvm-svn: 185929
2013-07-09 19:26:18 +08:00
def : InstAlias<!strconcat("vrint", opc, ".f64.f64\t$Dd, $Dm"),
ARM target does not use printAliasInstr machinery which forces having special checks in ArmInstPrinter::printInstruction. This patch addresses this issue. Not all special checks could be removed: either they involve elaborated conditions under which the alias is emitted (e.g. ldm/stm on sp may be pop/push but only if the number of registers is >= 2) or the number of registers is multivalued (like happens again with ldm/stm) and they do not match the InstAlias pattern which assumes single-valued operands in the pattern. Patch by: Roger Ferrer Ibanez Differential Revision: http://reviews.llvm.org/D20237 llvm-svn: 271667
2016-06-03 21:19:43 +08:00
(!cast<Instruction>(NAME#"D") DPR:$Dd, DPR:$Dm), 0>,
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
Requires<[HasFPARMv8,HasDPVFP]>;
Add MC assembly/disassembly support for VRINT{A, N, P, M} to V8FP. llvm-svn: 185929
2013-07-09 19:26:18 +08:00
}
[SelectionDAG] Rename fextend -> fpextend, fround -> fpround, frnd -> fround The names of the tablegen defs now match the names of the ISD nodes. This makes the world a slightly saner place, as previously "fround" matched ISD::FP_ROUND and not ISD::FROUND. Differential Revision: https://reviews.llvm.org/D23597 llvm-svn: 279129
2016-08-19 04:08:15 +08:00
defm VRINTA : vrint_inst_anpm<"a", 0b00, fround>;
Add MC assembly/disassembly support for VRINT{A, N, P, M} to V8FP. llvm-svn: 185929
2013-07-09 19:26:18 +08:00
defm VRINTN : vrint_inst_anpm<"n", 0b01>;
[AArch32] Add support for FP rounding operations for ARMv8/AArch32. Phabricator Revision: http://reviews.llvm.org/D4935 llvm-svn: 215772
2014-08-16 05:38:16 +08:00
defm VRINTP : vrint_inst_anpm<"p", 0b10, fceil>;
defm VRINTM : vrint_inst_anpm<"m", 0b11, ffloor>;
Add MC assembly/disassembly support for VRINT{A, N, P, M} to V8FP. llvm-svn: 185929
2013-07-09 19:26:18 +08:00
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VSQRTD : ADuI<0b11101, 0b11, 0b0001, 0b11, 0,
(outs DPR:$Dd), (ins DPR:$Dm),
IIC_fpSQRT64, "vsqrt", ".f64\t$Dd, $Dm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[(set DPR:$Dd, (fsqrt (f64 DPR:$Dm)))]>,
Sched<[WriteFPSQRT64]>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VSQRTS : ASuI<0b11101, 0b11, 0b0001, 0b11, 0,
(outs SPR:$Sd), (ins SPR:$Sm),
IIC_fpSQRT32, "vsqrt", ".f32\t$Sd, $Sm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[(set SPR:$Sd, (fsqrt SPR:$Sm))]>,
Sched<[WriteFPSQRT32]>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VSQRTH : AHuI<0b11101, 0b11, 0b0001, 0b11, 0,
(outs SPR:$Sd), (ins SPR:$Sm),
IIC_fpSQRT16, "vsqrt", ".f16\t$Sd, $Sm",
[]>;
Replace neverHasSideEffects=1 with hasSideEffects=0 in all .td files. llvm-svn: 222801
2014-11-26 08:46:26 +08:00
let hasSideEffects = 0 in {
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VMOVD : ADuI<0b11101, 0b11, 0b0000, 0b01, 0,
(outs DPR:$Dd), (ins DPR:$Dm),
IIC_fpUNA64, "vmov", ".f64\t$Dd, $Dm", []>;
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VMOVS : ASuI<0b11101, 0b11, 0b0000, 0b01, 0,
(outs SPR:$Sd), (ins SPR:$Sm),
IIC_fpUNA32, "vmov", ".f32\t$Sd, $Sm", []>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
let PostEncoderMethod = "", DecoderNamespace = "VFPV8" in {
def VMOVH : ASuInp<0b11101, 0b11, 0b0000, 0b01, 0,
(outs SPR:$Sd), (ins SPR:$Sm),
IIC_fpUNA16, "vmovx.f16\t$Sd, $Sm", []>,
Requires<[HasFullFP16]>;
def VINSH : ASuInp<0b11101, 0b11, 0b0000, 0b11, 0,
(outs SPR:$Sd), (ins SPR:$Sm),
IIC_fpUNA16, "vins.f16\t$Sd, $Sm", []>,
Requires<[HasFullFP16]>;
} // PostEncoderMethod
Replace neverHasSideEffects=1 with hasSideEffects=0 in all .td files. llvm-svn: 222801
2014-11-26 08:46:26 +08:00
} // hasSideEffects
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
//===----------------------------------------------------------------------===//
// FP <-> GPR Copies. Int <-> FP Conversions.
//
Add encodings for movement between ARM core registers and single-precision registers. llvm-svn: 116961
2010-10-21 06:44:54 +08:00
def VMOVRS : AVConv2I<0b11100001, 0b1010,
(outs GPR:$Rt), (ins SPR:$Sn),
IIC_fpMOVSI, "vmov", "\t$Rt, $Sn",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[(set GPR:$Rt, (bitconvert SPR:$Sn))]>,
Sched<[WriteFPMOV]> {
Add encodings for movement between ARM core registers and single-precision registers. llvm-svn: 116961
2010-10-21 06:44:54 +08:00
// Instruction operands.
bits<4> Rt;
bits<5> Sn;
// Encode instruction operands.
let Inst{19-16} = Sn{4-1};
let Inst{7} = Sn{0};
let Inst{15-12} = Rt;
let Inst{6-5} = 0b00;
let Inst{3-0} = 0b0000;
Some single-precision VFP instructions can execute in either the VPF or Neon pipelines, at least on Cortex-A9. llvm-svn: 129771
2011-04-20 02:11:38 +08:00
// Some single precision VFP instructions may be executed on both NEON and VFP
// pipelines.
let D = VFPNeonDomain;
Add encodings for movement between ARM core registers and single-precision registers. llvm-svn: 116961
2010-10-21 06:44:54 +08:00
}
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
Add LLVM support for Swift. llvm-svn: 164899
2012-09-30 05:43:49 +08:00
// Bitcast i32 -> f32. NEON prefers to use VMOVDRR.
Add encodings for movement between ARM core registers and single-precision registers. llvm-svn: 116961
2010-10-21 06:44:54 +08:00
def VMOVSR : AVConv4I<0b11100000, 0b1010,
(outs SPR:$Sn), (ins GPR:$Rt),
IIC_fpMOVIS, "vmov", "\t$Sn, $Rt",
Add LLVM support for Swift. llvm-svn: 164899
2012-09-30 05:43:49 +08:00
[(set SPR:$Sn, (bitconvert GPR:$Rt))]>,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasVFP2, UseVMOVSR]>,
Sched<[WriteFPMOV]> {
Add encodings for movement between ARM core registers and single-precision registers. llvm-svn: 116961
2010-10-21 06:44:54 +08:00
// Instruction operands.
bits<5> Sn;
bits<4> Rt;
// Encode instruction operands.
let Inst{19-16} = Sn{4-1};
let Inst{7} = Sn{0};
let Inst{15-12} = Rt;
let Inst{6-5} = 0b00;
let Inst{3-0} = 0b0000;
Some single-precision VFP instructions can execute in either the VPF or Neon pipelines, at least on Cortex-A9. llvm-svn: 129771
2011-04-20 02:11:38 +08:00
// Some single precision VFP instructions may be executed on both NEON and VFP
// pipelines.
let D = VFPNeonDomain;
Add encodings for movement between ARM core registers and single-precision registers. llvm-svn: 116961
2010-10-21 06:44:54 +08:00
}
[ARM] Support float literals under XO Follow up patch of r328313 to support the UseVMOVSR constraint. Removed some unneeded instructions from the test and removed some stray comments. Differential Revision: https://reviews.llvm.org/D44941 llvm-svn: 328691
2018-03-28 18:02:26 +08:00
def : Pat<(arm_vmovsr GPR:$Rt), (VMOVSR GPR:$Rt)>, Requires<[HasVFP2, UseVMOVSR]>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
Replace neverHasSideEffects=1 with hasSideEffects=0 in all .td files. llvm-svn: 222801
2014-11-26 08:46:26 +08:00
let hasSideEffects = 0 in {
Use Unified Assembly Syntax for the ARM backend. llvm-svn: 86494
2009-11-09 08:11:35 +08:00
def VMOVRRD : AVConv3I<0b11000101, 0b1011,
Add encoding for moving a value between two ARM core registers and a doublework extension register. llvm-svn: 116970
2010-10-21 07:37:40 +08:00
(outs GPR:$Rt, GPR:$Rt2), (ins DPR:$Dm),
IIC_fpMOVDI, "vmov", "\t$Rt, $Rt2, $Dm",
[ARM] Replace some C++ selection code with TableGen patterns. NFC. Differential Revision: https://reviews.llvm.org/D30794 llvm-svn: 297768
2017-03-15 02:43:37 +08:00
[(set GPR:$Rt, GPR:$Rt2, (arm_fmrrd DPR:$Dm))]>,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Sched<[WriteFPMOV]> {
Add encoding for moving a value between two ARM core registers and a doublework extension register. llvm-svn: 116970
2010-10-21 07:37:40 +08:00
// Instruction operands.
bits<5> Dm;
bits<4> Rt;
bits<4> Rt2;
// Encode instruction operands.
let Inst{3-0} = Dm{3-0};
let Inst{5} = Dm{4};
let Inst{15-12} = Rt;
let Inst{19-16} = Rt2;
VMOVRRD and VMOVDRR both have Inst{7-6} = 0b00. llvm-svn: 95397
2010-02-06 02:04:58 +08:00
let Inst{7-6} = 0b00;
Some single-precision VFP instructions can execute in either the VPF or Neon pipelines, at least on Cortex-A9. llvm-svn: 129771
2011-04-20 02:11:38 +08:00
// Some single precision VFP instructions may be executed on both NEON and VFP
// pipelines.
let D = VFPNeonDomain;
[ARM] Mark VMOVRRD with the ExtractSubreg property and implement the related target hook. This patch teaches the compiler that: rX, rY = VMOVRRD dZ is the same as: rX = EXTRACT_SUBREG dZ, ssub_0 rY = EXTRACT_SUBREG dZ, ssub_1 <rdar://problem/12702965> llvm-svn: 216132
2014-08-21 06:16:19 +08:00
// This instruction is equivalent to
// $Rt = EXTRACT_SUBREG $Dm, ssub_0
// $Rt2 = EXTRACT_SUBREG $Dm, ssub_1
let isExtractSubreg = 1;
VMOVRRD and VMOVDRR both have Inst{7-6} = 0b00. llvm-svn: 95397
2010-02-06 02:04:58 +08:00
}
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
Added VMOVRRS/VMOVSRR to ARMInstrVFP.td for disassembly purpose. A8.6.331 VMOV (between two ARM core registers and two single-precision registers) llvm-svn: 95548
2010-02-09 01:26:09 +08:00
def VMOVRRS : AVConv3I<0b11000101, 0b1010,
Add missing encoding information for some of the GPR<->FP register moves. llvm-svn: 138780
2011-08-30 07:15:25 +08:00
(outs GPR:$Rt, GPR:$Rt2), (ins SPR:$src1, SPR:$src2),
IIC_fpMOVDI, "vmov", "\t$Rt, $Rt2, $src1, $src2",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[/* For disassembly only; pattern left blank */]>,
Sched<[WriteFPMOV]> {
Add missing encoding information for some of the GPR<->FP register moves. llvm-svn: 138780
2011-08-30 07:15:25 +08:00
bits<5> src1;
bits<4> Rt;
bits<4> Rt2;
// Encode instruction operands.
Fix instruction description of VMOV (between two ARM core registers and two single-precision resiters) (and do it properly this time! llvm-svn: 159989
2012-07-10 20:51:09 +08:00
let Inst{3-0} = src1{4-1};
let Inst{5} = src1{0};
Add missing encoding information for some of the GPR<->FP register moves. llvm-svn: 138780
2011-08-30 07:15:25 +08:00
let Inst{15-12} = Rt;
let Inst{19-16} = Rt2;
Added VMOVRRS/VMOVSRR to ARMInstrVFP.td for disassembly purpose. A8.6.331 VMOV (between two ARM core registers and two single-precision registers) llvm-svn: 95548
2010-02-09 01:26:09 +08:00
let Inst{7-6} = 0b00;
Some single-precision VFP instructions can execute in either the VPF or Neon pipelines, at least on Cortex-A9. llvm-svn: 129771
2011-04-20 02:11:38 +08:00
// Some single precision VFP instructions may be executed on both NEON and VFP
// pipelines.
let D = VFPNeonDomain;
Fix decoding of VMOVSRR and VMOVRRS, which account for the overwhelming majority of decoder crashes detected by randomized testing. llvm-svn: 138269
2011-08-23 04:27:12 +08:00
let DecoderMethod = "DecodeVMOVRRS";
Added VMOVRRS/VMOVSRR to ARMInstrVFP.td for disassembly purpose. A8.6.331 VMOV (between two ARM core registers and two single-precision registers) llvm-svn: 95548
2010-02-09 01:26:09 +08:00
}
Replace neverHasSideEffects=1 with hasSideEffects=0 in all .td files. llvm-svn: 222801
2014-11-26 08:46:26 +08:00
} // hasSideEffects
Added VMOVRRS/VMOVSRR to ARMInstrVFP.td for disassembly purpose. A8.6.331 VMOV (between two ARM core registers and two single-precision registers) llvm-svn: 95548
2010-02-09 01:26:09 +08:00
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
// FMDHR: GPR -> SPR
// FMDLR: GPR -> SPR
Use Unified Assembly Syntax for the ARM backend. llvm-svn: 86494
2009-11-09 08:11:35 +08:00
def VMOVDRR : AVConv5I<0b11000100, 0b1011,
Add encoding for moving a value between two ARM core registers and a doublework extension register. llvm-svn: 116970
2010-10-21 07:37:40 +08:00
(outs DPR:$Dm), (ins GPR:$Rt, GPR:$Rt2),
IIC_fpMOVID, "vmov", "\t$Dm, $Rt, $Rt2",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[(set DPR:$Dm, (arm_fmdrr GPR:$Rt, GPR:$Rt2))]>,
Sched<[WriteFPMOV]> {
Add encoding for moving a value between two ARM core registers and a doublework extension register. llvm-svn: 116970
2010-10-21 07:37:40 +08:00
// Instruction operands.
bits<5> Dm;
bits<4> Rt;
bits<4> Rt2;
// Encode instruction operands.
let Inst{3-0} = Dm{3-0};
let Inst{5} = Dm{4};
let Inst{15-12} = Rt;
let Inst{19-16} = Rt2;
let Inst{7-6} = 0b00;
Some single-precision VFP instructions can execute in either the VPF or Neon pipelines, at least on Cortex-A9. llvm-svn: 129771
2011-04-20 02:11:38 +08:00
// Some single precision VFP instructions may be executed on both NEON and VFP
// pipelines.
let D = VFPNeonDomain;
[ARM] Mark VMOVDRR with the RegSequence property and implement the related target hook. This patch teaches the compiler that: dX = VMOVDRR rY, rZ is the same as: dX = REG_SEQUENCE rY, ssub_0, rZ, ssub_1 <rdar://problem/12702965> llvm-svn: 215404
2014-08-12 06:56:22 +08:00
// This instruction is equivalent to
// $Dm = REG_SEQUENCE $Rt, ssub_0, $Rt2, ssub_1
let isRegSequence = 1;
VMOVRRD and VMOVDRR both have Inst{7-6} = 0b00. llvm-svn: 95397
2010-02-06 02:04:58 +08:00
}
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
[ARM] Hoist fabs/fneg above a conversion to float. This is especially visible in softfp mode, for example in the implementation of libm fabs/fneg functions. If we have: %1 = vmovdrr r0, r1 %2 = fabs %1 then move the fabs before the vmovdrr: %1 = and r1, #0x7FFFFFFF %2 = vmovdrr r0, r1 This is never a lose, and could be a serious win because the vmovdrr may be followed by a vmovrrd, which would enable us to remove the conversion into FPRs completely. We already do this for f32, but not for f64. Tests are added for both. llvm-svn: 246360
2015-08-29 18:49:11 +08:00
// Hoist an fabs or a fneg of a value coming from integer registers
// and do the fabs/fneg on the integer value. This is never a lose
// and could enable the conversion to float to be removed completely.
def : Pat<(fabs (arm_fmdrr GPR:$Rl, GPR:$Rh)),
(VMOVDRR GPR:$Rl, (BFC GPR:$Rh, (i32 0x7FFFFFFF)))>,
Guard fabs to bfc convert with V6T2 flag Summary: BFC instructions are available in ARMv6T2 and above. Reviewers: t.p.northover Subscribers: aemerson Differential Revision: http://reviews.llvm.org/D16076 llvm-svn: 257546
2016-01-13 08:03:35 +08:00
Requires<[IsARM, HasV6T2]>;
[ARM] Hoist fabs/fneg above a conversion to float. This is especially visible in softfp mode, for example in the implementation of libm fabs/fneg functions. If we have: %1 = vmovdrr r0, r1 %2 = fabs %1 then move the fabs before the vmovdrr: %1 = and r1, #0x7FFFFFFF %2 = vmovdrr r0, r1 This is never a lose, and could be a serious win because the vmovdrr may be followed by a vmovrrd, which would enable us to remove the conversion into FPRs completely. We already do this for f32, but not for f64. Tests are added for both. llvm-svn: 246360
2015-08-29 18:49:11 +08:00
def : Pat<(fabs (arm_fmdrr GPR:$Rl, GPR:$Rh)),
(VMOVDRR GPR:$Rl, (t2BFC GPR:$Rh, (i32 0x7FFFFFFF)))>,
Guard fabs to bfc convert with V6T2 flag Summary: BFC instructions are available in ARMv6T2 and above. Reviewers: t.p.northover Subscribers: aemerson Differential Revision: http://reviews.llvm.org/D16076 llvm-svn: 257546
2016-01-13 08:03:35 +08:00
Requires<[IsThumb2, HasV6T2]>;
[ARM] Hoist fabs/fneg above a conversion to float. This is especially visible in softfp mode, for example in the implementation of libm fabs/fneg functions. If we have: %1 = vmovdrr r0, r1 %2 = fabs %1 then move the fabs before the vmovdrr: %1 = and r1, #0x7FFFFFFF %2 = vmovdrr r0, r1 This is never a lose, and could be a serious win because the vmovdrr may be followed by a vmovrrd, which would enable us to remove the conversion into FPRs completely. We already do this for f32, but not for f64. Tests are added for both. llvm-svn: 246360
2015-08-29 18:49:11 +08:00
def : Pat<(fneg (arm_fmdrr GPR:$Rl, GPR:$Rh)),
(VMOVDRR GPR:$Rl, (EORri GPR:$Rh, (i32 0x80000000)))>,
Requires<[IsARM]>;
def : Pat<(fneg (arm_fmdrr GPR:$Rl, GPR:$Rh)),
(VMOVDRR GPR:$Rl, (t2EORri GPR:$Rh, (i32 0x80000000)))>,
Requires<[IsThumb2]>;
Replace neverHasSideEffects=1 with hasSideEffects=0 in all .td files. llvm-svn: 222801
2014-11-26 08:46:26 +08:00
let hasSideEffects = 0 in
Added VMOVRRS/VMOVSRR to ARMInstrVFP.td for disassembly purpose. A8.6.331 VMOV (between two ARM core registers and two single-precision registers) llvm-svn: 95548
2010-02-09 01:26:09 +08:00
def VMOVSRR : AVConv5I<0b11000100, 0b1010,
(outs SPR:$dst1, SPR:$dst2), (ins GPR:$src1, GPR:$src2),
Define new itin classes for ARM <-> VFP reg moves to distinguish from NEON ops. Define proper scheduling itinerary for them on A9. A8 TRM does not specify latency for them at all :( llvm-svn: 100650
2010-04-08 02:20:02 +08:00
IIC_fpMOVID, "vmov", "\t$dst1, $dst2, $src1, $src2",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[/* For disassembly only; pattern left blank */]>,
Sched<[WriteFPMOV]> {
Add missing encoding information for some of the GPR<->FP register moves. llvm-svn: 138780
2011-08-30 07:15:25 +08:00
// Instruction operands.
bits<5> dst1;
bits<4> src1;
bits<4> src2;
// Encode instruction operands.
Fix instruction description of VMOV (between two ARM core registers and two single-precision resiters) (and do it properly this time! llvm-svn: 159989
2012-07-10 20:51:09 +08:00
let Inst{3-0} = dst1{4-1};
let Inst{5} = dst1{0};
Add missing encoding information for some of the GPR<->FP register moves. llvm-svn: 138780
2011-08-30 07:15:25 +08:00
let Inst{15-12} = src1;
let Inst{19-16} = src2;
Added VMOVRRS/VMOVSRR to ARMInstrVFP.td for disassembly purpose. A8.6.331 VMOV (between two ARM core registers and two single-precision registers) llvm-svn: 95548
2010-02-09 01:26:09 +08:00
let Inst{7-6} = 0b00;
Some single-precision VFP instructions can execute in either the VPF or Neon pipelines, at least on Cortex-A9. llvm-svn: 129771
2011-04-20 02:11:38 +08:00
// Some single precision VFP instructions may be executed on both NEON and VFP
// pipelines.
let D = VFPNeonDomain;
Fix decoding of VMOVSRR and VMOVRRS, which account for the overwhelming majority of decoder crashes detected by randomized testing. llvm-svn: 138269
2011-08-23 04:27:12 +08:00
let DecoderMethod = "DecodeVMOVSRR";
Added VMOVRRS/VMOVSRR to ARMInstrVFP.td for disassembly purpose. A8.6.331 VMOV (between two ARM core registers and two single-precision registers) llvm-svn: 95548
2010-02-09 01:26:09 +08:00
}
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
// Move H->R, clearing top 16 bits
def VMOVRH : AVConv2I<0b11100001, 0b1001,
[ARM] Armv8.2-A FP16 code generation (part 2/3) Half-precision arguments and return values are passed as if it were an int or float for ARM. This results in truncates and bitcasts to/from i16 and f16 values, which are legalized very early to stack stores/loads. When FullFP16 is enabled, we want to avoid codegen for these bitcasts as it is unnecessary and inefficient. Differential Revision: https://reviews.llvm.org/D42580 llvm-svn: 323861
2018-01-31 18:18:29 +08:00
(outs GPR:$Rt), (ins HPR:$Sn),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpMOVSI, "vmov", ".f16\t$Rt, $Sn",
[ARM] Armv8.2-A FP16 code generation (part 2/3) Half-precision arguments and return values are passed as if it were an int or float for ARM. This results in truncates and bitcasts to/from i16 and f16 values, which are legalized very early to stack stores/loads. When FullFP16 is enabled, we want to avoid codegen for these bitcasts as it is unnecessary and inefficient. Differential Revision: https://reviews.llvm.org/D42580 llvm-svn: 323861
2018-01-31 18:18:29 +08:00
[(set GPR:$Rt, (arm_vmovrh HPR:$Sn))]>,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasFullFP16]>,
Sched<[WriteFPMOV]> {
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
// Instruction operands.
bits<4> Rt;
bits<5> Sn;
// Encode instruction operands.
let Inst{19-16} = Sn{4-1};
let Inst{7} = Sn{0};
let Inst{15-12} = Rt;
let Inst{6-5} = 0b00;
let Inst{3-0} = 0b0000;
}
// Move R->H, clearing top 16 bits
def VMOVHR : AVConv4I<0b11100000, 0b1001,
[ARM] Armv8.2-A FP16 code generation (part 2/3) Half-precision arguments and return values are passed as if it were an int or float for ARM. This results in truncates and bitcasts to/from i16 and f16 values, which are legalized very early to stack stores/loads. When FullFP16 is enabled, we want to avoid codegen for these bitcasts as it is unnecessary and inefficient. Differential Revision: https://reviews.llvm.org/D42580 llvm-svn: 323861
2018-01-31 18:18:29 +08:00
(outs HPR:$Sn), (ins GPR:$Rt),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpMOVIS, "vmov", ".f16\t$Sn, $Rt",
[ARM] Armv8.2-A FP16 code generation (part 2/3) Half-precision arguments and return values are passed as if it were an int or float for ARM. This results in truncates and bitcasts to/from i16 and f16 values, which are legalized very early to stack stores/loads. When FullFP16 is enabled, we want to avoid codegen for these bitcasts as it is unnecessary and inefficient. Differential Revision: https://reviews.llvm.org/D42580 llvm-svn: 323861
2018-01-31 18:18:29 +08:00
[(set HPR:$Sn, (arm_vmovhr GPR:$Rt))]>,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasFullFP16]>,
Sched<[WriteFPMOV]> {
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
// Instruction operands.
bits<5> Sn;
bits<4> Rt;
// Encode instruction operands.
let Inst{19-16} = Sn{4-1};
let Inst{7} = Sn{0};
let Inst{15-12} = Rt;
let Inst{6-5} = 0b00;
let Inst{3-0} = 0b0000;
}
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
// FMRDH: SPR -> GPR
// FMRDL: SPR -> GPR
// FMRRS: SPR -> GPR
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
// FMRX: SPR system reg -> GPR
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
// FMSRR: GPR -> SPR
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
// FMXR: GPR -> VFP system reg
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
// Int -> FP:
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
class AVConv1IDs_Encode<bits<5> opcod1, bits<2> opcod2, bits<4> opcod3,
bits<4> opcod4, dag oops, dag iops,
InstrItinClass itin, string opc, string asm,
list<dag> pattern>
: AVConv1I<opcod1, opcod2, opcod3, opcod4, oops, iops, itin, opc, asm,
pattern> {
// Instruction operands.
bits<5> Dd;
bits<5> Sm;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
// Encode instruction operands.
let Inst{3-0} = Sm{4-1};
let Inst{5} = Sm{0};
let Inst{15-12} = Dd{3-0};
let Inst{22} = Dd{4};
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
let Predicates = [HasVFP2, HasDPVFP];
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
}
class AVConv1InSs_Encode<bits<5> opcod1, bits<2> opcod2, bits<4> opcod3,
bits<4> opcod4, dag oops, dag iops,InstrItinClass itin,
string opc, string asm, list<dag> pattern>
: AVConv1In<opcod1, opcod2, opcod3, opcod4, oops, iops, itin, opc, asm,
pattern> {
// Instruction operands.
bits<5> Sd;
bits<5> Sm;
// Encode instruction operands.
let Inst{3-0} = Sm{4-1};
let Inst{5} = Sm{0};
let Inst{15-12} = Sd{4-1};
let Inst{22} = Sd{0};
}
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
class AVConv1IHs_Encode<bits<5> opcod1, bits<2> opcod2, bits<4> opcod3,
bits<4> opcod4, dag oops, dag iops,
InstrItinClass itin, string opc, string asm,
list<dag> pattern>
: AVConv1I<opcod1, opcod2, opcod3, opcod4, oops, iops, itin, opc, asm,
pattern> {
// Instruction operands.
bits<5> Sd;
bits<5> Sm;
// Encode instruction operands.
let Inst{3-0} = Sm{4-1};
let Inst{5} = Sm{0};
let Inst{15-12} = Sd{4-1};
let Inst{22} = Sd{0};
let Predicates = [HasFullFP16];
}
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
def VSITOD : AVConv1IDs_Encode<0b11101, 0b11, 0b1000, 0b1011,
(outs DPR:$Dd), (ins SPR:$Sm),
IIC_fpCVTID, "vcvt", ".f64.s32\t$Dd, $Sm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[]>,
Sched<[WriteFPCVT]> {
Modified encoding bits specification for VFP instructions. In particular, the D bit (Inst{22}) and the M bit (Inst{5}) should be left unspecified. For binary format instructions, Inst{6} and Inst{4} need to specified for proper decodings. llvm-svn: 94855
2010-01-30 07:21:10 +08:00
let Inst{7} = 1; // s32
Encode VFP conversion instructions. llvm-svn: 59074
2008-11-12 03:40:26 +08:00
}
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
[ARM] Remove target-specific ITOFP/FPTOI nodes Anton tried this 5 years ago but it was reverted due to extra VMOVs being emitted. This can be easily fixed with a liberal application of patterns - matching loads/stores and extractelts. llvm-svn: 232958
2015-03-24 00:15:16 +08:00
let Predicates=[HasVFP2, HasDPVFP] in {
def : VFPPat<(f64 (sint_to_fp GPR:$a)),
(VSITOD (COPY_TO_REGCLASS GPR:$a, SPR))>;
ARM: make sure VFP loads and stores are properly aligned. Both VLDRS and VLDRD fault if the memory is not 4 byte aligned, which wasn't really being checked before, leading to faults at runtime. llvm-svn: 251352
2015-10-27 05:32:53 +08:00
def : VFPPat<(f64 (sint_to_fp (i32 (alignedload32 addrmode5:$a)))),
[ARM] Remove target-specific ITOFP/FPTOI nodes Anton tried this 5 years ago but it was reverted due to extra VMOVs being emitted. This can be easily fixed with a liberal application of patterns - matching loads/stores and extractelts. llvm-svn: 232958
2015-03-24 00:15:16 +08:00
(VSITOD (VLDRS addrmode5:$a))>;
}
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
def VSITOS : AVConv1InSs_Encode<0b11101, 0b11, 0b1000, 0b1010,
(outs SPR:$Sd),(ins SPR:$Sm),
IIC_fpCVTIS, "vcvt", ".f32.s32\t$Sd, $Sm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[]>,
Sched<[WriteFPCVT]> {
Modified encoding bits specification for VFP instructions. In particular, the D bit (Inst{22}) and the M bit (Inst{5}) should be left unspecified. For binary format instructions, Inst{6} and Inst{4} need to specified for proper decodings. llvm-svn: 94855
2010-01-30 07:21:10 +08:00
let Inst{7} = 1; // s32
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Encode VFP conversion instructions. llvm-svn: 59074
2008-11-12 03:40:26 +08:00
}
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
[ARM] Remove target-specific ITOFP/FPTOI nodes Anton tried this 5 years ago but it was reverted due to extra VMOVs being emitted. This can be easily fixed with a liberal application of patterns - matching loads/stores and extractelts. llvm-svn: 232958
2015-03-24 00:15:16 +08:00
def : VFPNoNEONPat<(f32 (sint_to_fp GPR:$a)),
(VSITOS (COPY_TO_REGCLASS GPR:$a, SPR))>;
ARM: make sure VFP loads and stores are properly aligned. Both VLDRS and VLDRD fault if the memory is not 4 byte aligned, which wasn't really being checked before, leading to faults at runtime. llvm-svn: 251352
2015-10-27 05:32:53 +08:00
def : VFPNoNEONPat<(f32 (sint_to_fp (i32 (alignedload32 addrmode5:$a)))),
[ARM] Remove target-specific ITOFP/FPTOI nodes Anton tried this 5 years ago but it was reverted due to extra VMOVs being emitted. This can be easily fixed with a liberal application of patterns - matching loads/stores and extractelts. llvm-svn: 232958
2015-03-24 00:15:16 +08:00
(VSITOS (VLDRS addrmode5:$a))>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VSITOH : AVConv1IHs_Encode<0b11101, 0b11, 0b1000, 0b1001,
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
(outs HPR:$Sd), (ins SPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpCVTIH, "vcvt", ".f16.s32\t$Sd, $Sm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[]>,
Sched<[WriteFPCVT]> {
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
let Inst{7} = 1; // s32
}
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
def : VFPNoNEONPat<(f16 (sint_to_fp GPR:$a)),
(VSITOH (COPY_TO_REGCLASS GPR:$a, SPR))>;
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
def VUITOD : AVConv1IDs_Encode<0b11101, 0b11, 0b1000, 0b1011,
(outs DPR:$Dd), (ins SPR:$Sm),
IIC_fpCVTID, "vcvt", ".f64.u32\t$Dd, $Sm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[]>,
Sched<[WriteFPCVT]> {
Modified encoding bits specification for VFP instructions. In particular, the D bit (Inst{22}) and the M bit (Inst{5}) should be left unspecified. For binary format instructions, Inst{6} and Inst{4} need to specified for proper decodings. llvm-svn: 94855
2010-01-30 07:21:10 +08:00
let Inst{7} = 0; // u32
}
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
[ARM] Remove target-specific ITOFP/FPTOI nodes Anton tried this 5 years ago but it was reverted due to extra VMOVs being emitted. This can be easily fixed with a liberal application of patterns - matching loads/stores and extractelts. llvm-svn: 232958
2015-03-24 00:15:16 +08:00
let Predicates=[HasVFP2, HasDPVFP] in {
def : VFPPat<(f64 (uint_to_fp GPR:$a)),
(VUITOD (COPY_TO_REGCLASS GPR:$a, SPR))>;
ARM: make sure VFP loads and stores are properly aligned. Both VLDRS and VLDRD fault if the memory is not 4 byte aligned, which wasn't really being checked before, leading to faults at runtime. llvm-svn: 251352
2015-10-27 05:32:53 +08:00
def : VFPPat<(f64 (uint_to_fp (i32 (alignedload32 addrmode5:$a)))),
[ARM] Remove target-specific ITOFP/FPTOI nodes Anton tried this 5 years ago but it was reverted due to extra VMOVs being emitted. This can be easily fixed with a liberal application of patterns - matching loads/stores and extractelts. llvm-svn: 232958
2015-03-24 00:15:16 +08:00
(VUITOD (VLDRS addrmode5:$a))>;
}
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
def VUITOS : AVConv1InSs_Encode<0b11101, 0b11, 0b1000, 0b1010,
(outs SPR:$Sd), (ins SPR:$Sm),
IIC_fpCVTIS, "vcvt", ".f32.u32\t$Sd, $Sm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[]>,
Sched<[WriteFPCVT]> {
Modified encoding bits specification for VFP instructions. In particular, the D bit (Inst{22}) and the M bit (Inst{5}) should be left unspecified. For binary format instructions, Inst{6} and Inst{4} need to specified for proper decodings. llvm-svn: 94855
2010-01-30 07:21:10 +08:00
let Inst{7} = 0; // u32
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Modified encoding bits specification for VFP instructions. In particular, the D bit (Inst{22}) and the M bit (Inst{5}) should be left unspecified. For binary format instructions, Inst{6} and Inst{4} need to specified for proper decodings. llvm-svn: 94855
2010-01-30 07:21:10 +08:00
}
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
[ARM] Remove target-specific ITOFP/FPTOI nodes Anton tried this 5 years ago but it was reverted due to extra VMOVs being emitted. This can be easily fixed with a liberal application of patterns - matching loads/stores and extractelts. llvm-svn: 232958
2015-03-24 00:15:16 +08:00
def : VFPNoNEONPat<(f32 (uint_to_fp GPR:$a)),
(VUITOS (COPY_TO_REGCLASS GPR:$a, SPR))>;
ARM: make sure VFP loads and stores are properly aligned. Both VLDRS and VLDRD fault if the memory is not 4 byte aligned, which wasn't really being checked before, leading to faults at runtime. llvm-svn: 251352
2015-10-27 05:32:53 +08:00
def : VFPNoNEONPat<(f32 (uint_to_fp (i32 (alignedload32 addrmode5:$a)))),
[ARM] Remove target-specific ITOFP/FPTOI nodes Anton tried this 5 years ago but it was reverted due to extra VMOVs being emitted. This can be easily fixed with a liberal application of patterns - matching loads/stores and extractelts. llvm-svn: 232958
2015-03-24 00:15:16 +08:00
(VUITOS (VLDRS addrmode5:$a))>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VUITOH : AVConv1IHs_Encode<0b11101, 0b11, 0b1000, 0b1001,
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
(outs HPR:$Sd), (ins SPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpCVTIH, "vcvt", ".f16.u32\t$Sd, $Sm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[]>,
Sched<[WriteFPCVT]> {
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
let Inst{7} = 0; // u32
}
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
def : VFPNoNEONPat<(f16 (uint_to_fp GPR:$a)),
(VUITOH (COPY_TO_REGCLASS GPR:$a, SPR))>;
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
// FP -> Int:
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
class AVConv1IsD_Encode<bits<5> opcod1, bits<2> opcod2, bits<4> opcod3,
bits<4> opcod4, dag oops, dag iops,
InstrItinClass itin, string opc, string asm,
list<dag> pattern>
: AVConv1I<opcod1, opcod2, opcod3, opcod4, oops, iops, itin, opc, asm,
pattern> {
// Instruction operands.
bits<5> Sd;
bits<5> Dm;
// Encode instruction operands.
let Inst{3-0} = Dm{3-0};
let Inst{5} = Dm{4};
let Inst{15-12} = Sd{4-1};
let Inst{22} = Sd{0};
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
let Predicates = [HasVFP2, HasDPVFP];
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
}
class AVConv1InsS_Encode<bits<5> opcod1, bits<2> opcod2, bits<4> opcod3,
bits<4> opcod4, dag oops, dag iops,
InstrItinClass itin, string opc, string asm,
list<dag> pattern>
: AVConv1In<opcod1, opcod2, opcod3, opcod4, oops, iops, itin, opc, asm,
pattern> {
// Instruction operands.
bits<5> Sd;
bits<5> Sm;
// Encode instruction operands.
let Inst{3-0} = Sm{4-1};
let Inst{5} = Sm{0};
let Inst{15-12} = Sd{4-1};
let Inst{22} = Sd{0};
}
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
class AVConv1IsH_Encode<bits<5> opcod1, bits<2> opcod2, bits<4> opcod3,
bits<4> opcod4, dag oops, dag iops,
InstrItinClass itin, string opc, string asm,
list<dag> pattern>
: AVConv1I<opcod1, opcod2, opcod3, opcod4, oops, iops, itin, opc, asm,
pattern> {
// Instruction operands.
bits<5> Sd;
bits<5> Sm;
// Encode instruction operands.
let Inst{3-0} = Sm{4-1};
let Inst{5} = Sm{0};
let Inst{15-12} = Sd{4-1};
let Inst{22} = Sd{0};
let Predicates = [HasFullFP16];
}
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
// Always set Z bit in the instruction, i.e. "round towards zero" variants.
def VTOSIZD : AVConv1IsD_Encode<0b11101, 0b11, 0b1101, 0b1011,
(outs SPR:$Sd), (ins DPR:$Dm),
IIC_fpCVTDI, "vcvt", ".s32.f64\t$Sd, $Dm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[]>,
Sched<[WriteFPCVT]> {
Encode VFP conversion instructions. llvm-svn: 59074
2008-11-12 03:40:26 +08:00
let Inst{7} = 1; // Z bit
}
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
[ARM] Remove target-specific ITOFP/FPTOI nodes Anton tried this 5 years ago but it was reverted due to extra VMOVs being emitted. This can be easily fixed with a liberal application of patterns - matching loads/stores and extractelts. llvm-svn: 232958
2015-03-24 00:15:16 +08:00
let Predicates=[HasVFP2, HasDPVFP] in {
def : VFPPat<(i32 (fp_to_sint (f64 DPR:$a))),
(COPY_TO_REGCLASS (VTOSIZD DPR:$a), GPR)>;
Revert r312724 ("[ARM] Remove redundant vcvt patterns."). It leads to some improvements, but also a regression for the simple case, so it's not clearly a good idea. test/CodeGen/ARM/vcvt.ll now has test coverage to show the difference. Ultimately, the right solution is probably to custom-lower fp-to-int conversions, to something like ARMISD::VCVT_F32_S32 plus a bitcast. It's hard to do the right thing when the implicit bitcast isn't visible to DAG transforms. llvm-svn: 314169
2017-09-26 06:07:33 +08:00
def : VFPPat<(alignedstore32 (i32 (fp_to_sint (f64 DPR:$a))), addrmode5:$ptr),
(VSTRS (VTOSIZD DPR:$a), addrmode5:$ptr)>;
[ARM] Remove target-specific ITOFP/FPTOI nodes Anton tried this 5 years ago but it was reverted due to extra VMOVs being emitted. This can be easily fixed with a liberal application of patterns - matching loads/stores and extractelts. llvm-svn: 232958
2015-03-24 00:15:16 +08:00
}
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
def VTOSIZS : AVConv1InsS_Encode<0b11101, 0b11, 0b1101, 0b1010,
(outs SPR:$Sd), (ins SPR:$Sm),
IIC_fpCVTSI, "vcvt", ".s32.f32\t$Sd, $Sm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[]>,
Sched<[WriteFPCVT]> {
Encode VFP conversion instructions. llvm-svn: 59074
2008-11-12 03:40:26 +08:00
let Inst{7} = 1; // Z bit
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Encode VFP conversion instructions. llvm-svn: 59074
2008-11-12 03:40:26 +08:00
}
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
[ARM] Remove target-specific ITOFP/FPTOI nodes Anton tried this 5 years ago but it was reverted due to extra VMOVs being emitted. This can be easily fixed with a liberal application of patterns - matching loads/stores and extractelts. llvm-svn: 232958
2015-03-24 00:15:16 +08:00
def : VFPNoNEONPat<(i32 (fp_to_sint SPR:$a)),
(COPY_TO_REGCLASS (VTOSIZS SPR:$a), GPR)>;
Revert r312724 ("[ARM] Remove redundant vcvt patterns."). It leads to some improvements, but also a regression for the simple case, so it's not clearly a good idea. test/CodeGen/ARM/vcvt.ll now has test coverage to show the difference. Ultimately, the right solution is probably to custom-lower fp-to-int conversions, to something like ARMISD::VCVT_F32_S32 plus a bitcast. It's hard to do the right thing when the implicit bitcast isn't visible to DAG transforms. llvm-svn: 314169
2017-09-26 06:07:33 +08:00
def : VFPNoNEONPat<(alignedstore32 (i32 (fp_to_sint (f32 SPR:$a))),
addrmode5:$ptr),
(VSTRS (VTOSIZS SPR:$a), addrmode5:$ptr)>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VTOSIZH : AVConv1IsH_Encode<0b11101, 0b11, 0b1101, 0b1001,
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
(outs SPR:$Sd), (ins HPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpCVTHI, "vcvt", ".s32.f16\t$Sd, $Sm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[]>,
Sched<[WriteFPCVT]> {
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
let Inst{7} = 1; // Z bit
}
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
def : VFPNoNEONPat<(i32 (fp_to_sint HPR:$a)),
(COPY_TO_REGCLASS (VTOSIZH HPR:$a), GPR)>;
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
def VTOUIZD : AVConv1IsD_Encode<0b11101, 0b11, 0b1100, 0b1011,
(outs SPR:$Sd), (ins DPR:$Dm),
IIC_fpCVTDI, "vcvt", ".u32.f64\t$Sd, $Dm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[]>,
Sched<[WriteFPCVT]> {
Encode VFP conversion instructions. llvm-svn: 59074
2008-11-12 03:40:26 +08:00
let Inst{7} = 1; // Z bit
}
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
[ARM] Remove target-specific ITOFP/FPTOI nodes Anton tried this 5 years ago but it was reverted due to extra VMOVs being emitted. This can be easily fixed with a liberal application of patterns - matching loads/stores and extractelts. llvm-svn: 232958
2015-03-24 00:15:16 +08:00
let Predicates=[HasVFP2, HasDPVFP] in {
def : VFPPat<(i32 (fp_to_uint (f64 DPR:$a))),
(COPY_TO_REGCLASS (VTOUIZD DPR:$a), GPR)>;
Revert r312724 ("[ARM] Remove redundant vcvt patterns."). It leads to some improvements, but also a regression for the simple case, so it's not clearly a good idea. test/CodeGen/ARM/vcvt.ll now has test coverage to show the difference. Ultimately, the right solution is probably to custom-lower fp-to-int conversions, to something like ARMISD::VCVT_F32_S32 plus a bitcast. It's hard to do the right thing when the implicit bitcast isn't visible to DAG transforms. llvm-svn: 314169
2017-09-26 06:07:33 +08:00
def : VFPPat<(alignedstore32 (i32 (fp_to_uint (f64 DPR:$a))), addrmode5:$ptr),
(VSTRS (VTOUIZD DPR:$a), addrmode5:$ptr)>;
[ARM] Remove target-specific ITOFP/FPTOI nodes Anton tried this 5 years ago but it was reverted due to extra VMOVs being emitted. This can be easily fixed with a liberal application of patterns - matching loads/stores and extractelts. llvm-svn: 232958
2015-03-24 00:15:16 +08:00
}
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
def VTOUIZS : AVConv1InsS_Encode<0b11101, 0b11, 0b1100, 0b1010,
(outs SPR:$Sd), (ins SPR:$Sm),
IIC_fpCVTSI, "vcvt", ".u32.f32\t$Sd, $Sm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[]>,
Sched<[WriteFPCVT]> {
Encode VFP conversion instructions. llvm-svn: 59074
2008-11-12 03:40:26 +08:00
let Inst{7} = 1; // Z bit
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Encode VFP conversion instructions. llvm-svn: 59074
2008-11-12 03:40:26 +08:00
}
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
[ARM] Remove target-specific ITOFP/FPTOI nodes Anton tried this 5 years ago but it was reverted due to extra VMOVs being emitted. This can be easily fixed with a liberal application of patterns - matching loads/stores and extractelts. llvm-svn: 232958
2015-03-24 00:15:16 +08:00
def : VFPNoNEONPat<(i32 (fp_to_uint SPR:$a)),
(COPY_TO_REGCLASS (VTOUIZS SPR:$a), GPR)>;
Revert r312724 ("[ARM] Remove redundant vcvt patterns."). It leads to some improvements, but also a regression for the simple case, so it's not clearly a good idea. test/CodeGen/ARM/vcvt.ll now has test coverage to show the difference. Ultimately, the right solution is probably to custom-lower fp-to-int conversions, to something like ARMISD::VCVT_F32_S32 plus a bitcast. It's hard to do the right thing when the implicit bitcast isn't visible to DAG transforms. llvm-svn: 314169
2017-09-26 06:07:33 +08:00
def : VFPNoNEONPat<(alignedstore32 (i32 (fp_to_uint (f32 SPR:$a))),
addrmode5:$ptr),
(VSTRS (VTOUIZS SPR:$a), addrmode5:$ptr)>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VTOUIZH : AVConv1IsH_Encode<0b11101, 0b11, 0b1100, 0b1001,
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
(outs SPR:$Sd), (ins HPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpCVTHI, "vcvt", ".u32.f16\t$Sd, $Sm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[]>,
Sched<[WriteFPCVT]> {
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
let Inst{7} = 1; // Z bit
}
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
def : VFPNoNEONPat<(i32 (fp_to_uint HPR:$a)),
(COPY_TO_REGCLASS (VTOUIZH HPR:$a), GPR)>;
Add VCVTR (between floating-point and integer, VFP) for disassembly purpose. The 'R' suffix means the to-integer operations use the rounding mode specified by the FPSCR, encoded as Inst{7} = 0. A8.6.295 llvm-svn: 95584
2010-02-09 06:02:41 +08:00
// And the Z bit '0' variants, i.e. use the rounding mode specified by FPSCR.
Add support for getting & setting the FPSCR application register on ARM when VFP is enabled. Add support for using the FPSCR in conjunction with the vcvtr instruction, for controlling fp to int rounding. Add support for the FLT_ROUNDS_ node now that the FPSCR is exposed. llvm-svn: 110152
2010-08-04 05:31:55 +08:00
let Uses = [FPSCR] in {
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
def VTOSIRD : AVConv1IsD_Encode<0b11101, 0b11, 0b1101, 0b1011,
(outs SPR:$Sd), (ins DPR:$Dm),
IIC_fpCVTDI, "vcvtr", ".s32.f64\t$Sd, $Dm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[(set SPR:$Sd, (int_arm_vcvtr (f64 DPR:$Dm)))]>,
Sched<[WriteFPCVT]> {
Add VCVTR (between floating-point and integer, VFP) for disassembly purpose. The 'R' suffix means the to-integer operations use the rounding mode specified by the FPSCR, encoded as Inst{7} = 0. A8.6.295 llvm-svn: 95584
2010-02-09 06:02:41 +08:00
let Inst{7} = 0; // Z bit
}
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
def VTOSIRS : AVConv1InsS_Encode<0b11101, 0b11, 0b1101, 0b1010,
(outs SPR:$Sd), (ins SPR:$Sm),
IIC_fpCVTSI, "vcvtr", ".s32.f32\t$Sd, $Sm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[(set SPR:$Sd, (int_arm_vcvtr SPR:$Sm))]>,
Sched<[WriteFPCVT]> {
Add VCVTR (between floating-point and integer, VFP) for disassembly purpose. The 'R' suffix means the to-integer operations use the rounding mode specified by the FPSCR, encoded as Inst{7} = 0. A8.6.295 llvm-svn: 95584
2010-02-09 06:02:41 +08:00
let Inst{7} = 0; // Z bit
}
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VTOSIRH : AVConv1IsH_Encode<0b11101, 0b11, 0b1101, 0b1001,
(outs SPR:$Sd), (ins SPR:$Sm),
IIC_fpCVTHI, "vcvtr", ".s32.f16\t$Sd, $Sm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[]>,
Sched<[WriteFPCVT]> {
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
let Inst{7} = 0; // Z bit
}
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
def VTOUIRD : AVConv1IsD_Encode<0b11101, 0b11, 0b1100, 0b1011,
(outs SPR:$Sd), (ins DPR:$Dm),
IIC_fpCVTDI, "vcvtr", ".u32.f64\t$Sd, $Dm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[(set SPR:$Sd, (int_arm_vcvtru(f64 DPR:$Dm)))]>,
Sched<[WriteFPCVT]> {
Add VCVTR (between floating-point and integer, VFP) for disassembly purpose. The 'R' suffix means the to-integer operations use the rounding mode specified by the FPSCR, encoded as Inst{7} = 0. A8.6.295 llvm-svn: 95584
2010-02-09 06:02:41 +08:00
let Inst{7} = 0; // Z bit
}
Add MC encodings for VCVT* instrunctions. llvm-svn: 116431
2010-10-14 04:58:46 +08:00
def VTOUIRS : AVConv1InsS_Encode<0b11101, 0b11, 0b1100, 0b1010,
(outs SPR:$Sd), (ins SPR:$Sm),
IIC_fpCVTSI, "vcvtr", ".u32.f32\t$Sd, $Sm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[(set SPR:$Sd, (int_arm_vcvtru SPR:$Sm))]>,
Sched<[WriteFPCVT]> {
Add VCVTR (between floating-point and integer, VFP) for disassembly purpose. The 'R' suffix means the to-integer operations use the rounding mode specified by the FPSCR, encoded as Inst{7} = 0. A8.6.295 llvm-svn: 95584
2010-02-09 06:02:41 +08:00
let Inst{7} = 0; // Z bit
}
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VTOUIRH : AVConv1IsH_Encode<0b11101, 0b11, 0b1100, 0b1001,
(outs SPR:$Sd), (ins SPR:$Sm),
IIC_fpCVTHI, "vcvtr", ".u32.f16\t$Sd, $Sm",
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
[]>,
Sched<[WriteFPCVT]> {
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
let Inst{7} = 0; // Z bit
}
Add support for getting & setting the FPSCR application register on ARM when VFP is enabled. Add support for using the FPSCR in conjunction with the vcvtr instruction, for controlling fp to int rounding. Add support for the FLT_ROUNDS_ node now that the FPSCR is exposed. llvm-svn: 110152
2010-08-04 05:31:55 +08:00
}
Add VCVTR (between floating-point and integer, VFP) for disassembly purpose. The 'R' suffix means the to-integer operations use the rounding mode specified by the FPSCR, encoded as Inst{7} = 0. A8.6.295 llvm-svn: 95584
2010-02-09 06:02:41 +08:00
[ARM][AArch64] v8.3-A Javascript Conversion Armv8.3-A adds instructions that convert a double-precision floating point number to a signed 32-bit integer with round towards zero, designed for improving Javascript performance. Differential Revision: https://reviews.llvm.org/D36785 llvm-svn: 311448
2017-08-22 19:08:21 +08:00
// v8.3-a Javascript Convert to Signed fixed-point
def VJCVT : AVConv1IsD_Encode<0b11101, 0b11, 0b1001, 0b1011,
(outs SPR:$Sd), (ins DPR:$Dm),
IIC_fpCVTDI, "vjcvt", ".s32.f64\t$Sd, $Dm",
[]>,
Requires<[HasFPARMv8, HasV8_3a]> {
let Inst{7} = 1; // Z bit
}
Added VCVT (between floating-point and fixed-point, VFP) for disassembly. A8.6.297 llvm-svn: 95885
2010-02-12 02:17:16 +08:00
// Convert between floating-point and fixed-point
// Data type for fixed-point naming convention:
// S16 (U=0, sx=0) -> SH
// U16 (U=1, sx=0) -> UH
// S32 (U=0, sx=1) -> SL
// U32 (U=1, sx=1) -> UL
Remove some bogus comments. llvm-svn: 147169
2011-12-23 03:45:01 +08:00
let Constraints = "$a = $dst" in {
Added VCVT (between floating-point and fixed-point, VFP) for disassembly. A8.6.297 llvm-svn: 95885
2010-02-12 02:17:16 +08:00
// FP to Fixed-Point:
Fix VCVT decoding (between floating-point and fixed-point, Floating-point). Patch by Richard Barton. llvm-svn: 152814
2012-03-16 01:50:29 +08:00
// Single Precision register
Tidy up. 80 columns, whitespace, et. al. llvm-svn: 155399
2012-04-24 06:04:10 +08:00
class AVConv1XInsS_Encode<bits<5> op1, bits<2> op2, bits<4> op3, bits<4> op4,
bit op5, dag oops, dag iops, InstrItinClass itin,
string opc, string asm, list<dag> pattern>
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
: AVConv1XI<op1, op2, op3, op4, op5, oops, iops, itin, opc, asm, pattern> {
Fix VCVT decoding (between floating-point and fixed-point, Floating-point). Patch by Richard Barton. llvm-svn: 152814
2012-03-16 01:50:29 +08:00
bits<5> dst;
// if dp_operation then UInt(D:Vd) else UInt(Vd:D);
let Inst{22} = dst{0};
let Inst{15-12} = dst{4-1};
}
// Double Precision register
Tidy up. 80 columns, whitespace, et. al. llvm-svn: 155399
2012-04-24 06:04:10 +08:00
class AVConv1XInsD_Encode<bits<5> op1, bits<2> op2, bits<4> op3, bits<4> op4,
bit op5, dag oops, dag iops, InstrItinClass itin,
string opc, string asm, list<dag> pattern>
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
: AVConv1XI<op1, op2, op3, op4, op5, oops, iops, itin, opc, asm, pattern> {
Fix VCVT decoding (between floating-point and fixed-point, Floating-point). Patch by Richard Barton. llvm-svn: 152814
2012-03-16 01:50:29 +08:00
bits<5> dst;
// if dp_operation then UInt(D:Vd) else UInt(Vd:D);
let Inst{22} = dst{4};
let Inst{15-12} = dst{3-0};
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
let Predicates = [HasVFP2, HasDPVFP];
Fix VCVT decoding (between floating-point and fixed-point, Floating-point). Patch by Richard Barton. llvm-svn: 152814
2012-03-16 01:50:29 +08:00
}
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VTOSHH : AVConv1XInsS_Encode<0b11101, 0b11, 0b1110, 0b1001, 0,
(outs SPR:$dst), (ins SPR:$a, fbits16:$fbits),
IIC_fpCVTHI, "vcvt", ".s16.f16\t$dst, $a, $fbits", []>,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasFullFP16]>,
Sched<[WriteFPCVT]>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VTOUHH : AVConv1XInsS_Encode<0b11101, 0b11, 0b1111, 0b1001, 0,
(outs SPR:$dst), (ins SPR:$a, fbits16:$fbits),
IIC_fpCVTHI, "vcvt", ".u16.f16\t$dst, $a, $fbits", []>,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasFullFP16]>,
Sched<[WriteFPCVT]>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VTOSLH : AVConv1XInsS_Encode<0b11101, 0b11, 0b1110, 0b1001, 1,
(outs SPR:$dst), (ins SPR:$a, fbits32:$fbits),
IIC_fpCVTHI, "vcvt", ".s32.f16\t$dst, $a, $fbits", []>,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasFullFP16]>,
Sched<[WriteFPCVT]>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VTOULH : AVConv1XInsS_Encode<0b11101, 0b11, 0b1111, 0b1001, 1,
(outs SPR:$dst), (ins SPR:$a, fbits32:$fbits),
IIC_fpCVTHI, "vcvt", ".u32.f16\t$dst, $a, $fbits", []>,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasFullFP16]>,
Sched<[WriteFPCVT]>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
Fix VCVT decoding (between floating-point and fixed-point, Floating-point). Patch by Richard Barton. llvm-svn: 152814
2012-03-16 01:50:29 +08:00
def VTOSHS : AVConv1XInsS_Encode<0b11101, 0b11, 0b1110, 0b1010, 0,
ARM VFP assembly parsing and encoding for VCVT(float <--> fixed point). rdar://10558523 llvm-svn: 147189
2011-12-23 06:19:05 +08:00
(outs SPR:$dst), (ins SPR:$a, fbits16:$fbits),
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
IIC_fpCVTSI, "vcvt", ".s16.f32\t$dst, $a, $fbits", []>,
Sched<[WriteFPCVT]> {
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
}
Added VCVT (between floating-point and fixed-point, VFP) for disassembly. A8.6.297 llvm-svn: 95885
2010-02-12 02:17:16 +08:00
Fix VCVT decoding (between floating-point and fixed-point, Floating-point). Patch by Richard Barton. llvm-svn: 152814
2012-03-16 01:50:29 +08:00
def VTOUHS : AVConv1XInsS_Encode<0b11101, 0b11, 0b1111, 0b1010, 0,
ARM VFP assembly parsing and encoding for VCVT(float <--> fixed point). rdar://10558523 llvm-svn: 147189
2011-12-23 06:19:05 +08:00
(outs SPR:$dst), (ins SPR:$a, fbits16:$fbits),
Remove some bogus comments. llvm-svn: 147169
2011-12-23 03:45:01 +08:00
IIC_fpCVTSI, "vcvt", ".u16.f32\t$dst, $a, $fbits", []> {
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
}
Added VCVT (between floating-point and fixed-point, VFP) for disassembly. A8.6.297 llvm-svn: 95885
2010-02-12 02:17:16 +08:00
Fix VCVT decoding (between floating-point and fixed-point, Floating-point). Patch by Richard Barton. llvm-svn: 152814
2012-03-16 01:50:29 +08:00
def VTOSLS : AVConv1XInsS_Encode<0b11101, 0b11, 0b1110, 0b1010, 1,
ARM VFP assembly parsing and encoding for VCVT(float <--> fixed point). rdar://10558523 llvm-svn: 147189
2011-12-23 06:19:05 +08:00
(outs SPR:$dst), (ins SPR:$a, fbits32:$fbits),
Remove some bogus comments. llvm-svn: 147169
2011-12-23 03:45:01 +08:00
IIC_fpCVTSI, "vcvt", ".s32.f32\t$dst, $a, $fbits", []> {
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
}
Added VCVT (between floating-point and fixed-point, VFP) for disassembly. A8.6.297 llvm-svn: 95885
2010-02-12 02:17:16 +08:00
Fix VCVT decoding (between floating-point and fixed-point, Floating-point). Patch by Richard Barton. llvm-svn: 152814
2012-03-16 01:50:29 +08:00
def VTOULS : AVConv1XInsS_Encode<0b11101, 0b11, 0b1111, 0b1010, 1,
ARM VFP assembly parsing and encoding for VCVT(float <--> fixed point). rdar://10558523 llvm-svn: 147189
2011-12-23 06:19:05 +08:00
(outs SPR:$dst), (ins SPR:$a, fbits32:$fbits),
Remove some bogus comments. llvm-svn: 147169
2011-12-23 03:45:01 +08:00
IIC_fpCVTSI, "vcvt", ".u32.f32\t$dst, $a, $fbits", []> {
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
}
Added VCVT (between floating-point and fixed-point, VFP) for disassembly. A8.6.297 llvm-svn: 95885
2010-02-12 02:17:16 +08:00
Fix VCVT decoding (between floating-point and fixed-point, Floating-point). Patch by Richard Barton. llvm-svn: 152814
2012-03-16 01:50:29 +08:00
def VTOSHD : AVConv1XInsD_Encode<0b11101, 0b11, 0b1110, 0b1011, 0,
ARM VFP assembly parsing and encoding for VCVT(float <--> fixed point). rdar://10558523 llvm-svn: 147189
2011-12-23 06:19:05 +08:00
(outs DPR:$dst), (ins DPR:$a, fbits16:$fbits),
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
IIC_fpCVTDI, "vcvt", ".s16.f64\t$dst, $a, $fbits", []>,
Sched<[WriteFPCVT]>;
Added VCVT (between floating-point and fixed-point, VFP) for disassembly. A8.6.297 llvm-svn: 95885
2010-02-12 02:17:16 +08:00
Fix VCVT decoding (between floating-point and fixed-point, Floating-point). Patch by Richard Barton. llvm-svn: 152814
2012-03-16 01:50:29 +08:00
def VTOUHD : AVConv1XInsD_Encode<0b11101, 0b11, 0b1111, 0b1011, 0,
ARM VFP assembly parsing and encoding for VCVT(float <--> fixed point). rdar://10558523 llvm-svn: 147189
2011-12-23 06:19:05 +08:00
(outs DPR:$dst), (ins DPR:$a, fbits16:$fbits),
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
IIC_fpCVTDI, "vcvt", ".u16.f64\t$dst, $a, $fbits", []>,
Sched<[WriteFPCVT]>;
Added VCVT (between floating-point and fixed-point, VFP) for disassembly. A8.6.297 llvm-svn: 95885
2010-02-12 02:17:16 +08:00
Fix VCVT decoding (between floating-point and fixed-point, Floating-point). Patch by Richard Barton. llvm-svn: 152814
2012-03-16 01:50:29 +08:00
def VTOSLD : AVConv1XInsD_Encode<0b11101, 0b11, 0b1110, 0b1011, 1,
ARM VFP assembly parsing and encoding for VCVT(float <--> fixed point). rdar://10558523 llvm-svn: 147189
2011-12-23 06:19:05 +08:00
(outs DPR:$dst), (ins DPR:$a, fbits32:$fbits),
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
IIC_fpCVTDI, "vcvt", ".s32.f64\t$dst, $a, $fbits", []>,
Sched<[WriteFPCVT]>;
Added VCVT (between floating-point and fixed-point, VFP) for disassembly. A8.6.297 llvm-svn: 95885
2010-02-12 02:17:16 +08:00
Fix VCVT decoding (between floating-point and fixed-point, Floating-point). Patch by Richard Barton. llvm-svn: 152814
2012-03-16 01:50:29 +08:00
def VTOULD : AVConv1XInsD_Encode<0b11101, 0b11, 0b1111, 0b1011, 1,
ARM VFP assembly parsing and encoding for VCVT(float <--> fixed point). rdar://10558523 llvm-svn: 147189
2011-12-23 06:19:05 +08:00
(outs DPR:$dst), (ins DPR:$a, fbits32:$fbits),
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
IIC_fpCVTDI, "vcvt", ".u32.f64\t$dst, $a, $fbits", []>,
Sched<[WriteFPCVT]>;
Added VCVT (between floating-point and fixed-point, VFP) for disassembly. A8.6.297 llvm-svn: 95885
2010-02-12 02:17:16 +08:00
// Fixed-Point to FP:
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VSHTOH : AVConv1XInsS_Encode<0b11101, 0b11, 0b1010, 0b1001, 0,
(outs SPR:$dst), (ins SPR:$a, fbits16:$fbits),
IIC_fpCVTIH, "vcvt", ".f16.s16\t$dst, $a, $fbits", []>,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasFullFP16]>,
Sched<[WriteFPCVT]>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VUHTOH : AVConv1XInsS_Encode<0b11101, 0b11, 0b1011, 0b1001, 0,
(outs SPR:$dst), (ins SPR:$a, fbits16:$fbits),
IIC_fpCVTIH, "vcvt", ".f16.u16\t$dst, $a, $fbits", []>,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasFullFP16]>,
Sched<[WriteFPCVT]>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VSLTOH : AVConv1XInsS_Encode<0b11101, 0b11, 0b1010, 0b1001, 1,
(outs SPR:$dst), (ins SPR:$a, fbits32:$fbits),
IIC_fpCVTIH, "vcvt", ".f16.s32\t$dst, $a, $fbits", []>,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasFullFP16]>,
Sched<[WriteFPCVT]>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VULTOH : AVConv1XInsS_Encode<0b11101, 0b11, 0b1011, 0b1001, 1,
(outs SPR:$dst), (ins SPR:$a, fbits32:$fbits),
IIC_fpCVTIH, "vcvt", ".f16.u32\t$dst, $a, $fbits", []>,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasFullFP16]>,
Sched<[WriteFPCVT]>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
Fix VCVT decoding (between floating-point and fixed-point, Floating-point). Patch by Richard Barton. llvm-svn: 152814
2012-03-16 01:50:29 +08:00
def VSHTOS : AVConv1XInsS_Encode<0b11101, 0b11, 0b1010, 0b1010, 0,
ARM VFP assembly parsing and encoding for VCVT(float <--> fixed point). rdar://10558523 llvm-svn: 147189
2011-12-23 06:19:05 +08:00
(outs SPR:$dst), (ins SPR:$a, fbits16:$fbits),
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
IIC_fpCVTIS, "vcvt", ".f32.s16\t$dst, $a, $fbits", []>,
Sched<[WriteFPCVT]> {
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
}
Added VCVT (between floating-point and fixed-point, VFP) for disassembly. A8.6.297 llvm-svn: 95885
2010-02-12 02:17:16 +08:00
Fix VCVT decoding (between floating-point and fixed-point, Floating-point). Patch by Richard Barton. llvm-svn: 152814
2012-03-16 01:50:29 +08:00
def VUHTOS : AVConv1XInsS_Encode<0b11101, 0b11, 0b1011, 0b1010, 0,
ARM VFP assembly parsing and encoding for VCVT(float <--> fixed point). rdar://10558523 llvm-svn: 147189
2011-12-23 06:19:05 +08:00
(outs SPR:$dst), (ins SPR:$a, fbits16:$fbits),
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
IIC_fpCVTIS, "vcvt", ".f32.u16\t$dst, $a, $fbits", []>,
Sched<[WriteFPCVT]> {
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
}
Added VCVT (between floating-point and fixed-point, VFP) for disassembly. A8.6.297 llvm-svn: 95885
2010-02-12 02:17:16 +08:00
Fix VCVT decoding (between floating-point and fixed-point, Floating-point). Patch by Richard Barton. llvm-svn: 152814
2012-03-16 01:50:29 +08:00
def VSLTOS : AVConv1XInsS_Encode<0b11101, 0b11, 0b1010, 0b1010, 1,
ARM VFP assembly parsing and encoding for VCVT(float <--> fixed point). rdar://10558523 llvm-svn: 147189
2011-12-23 06:19:05 +08:00
(outs SPR:$dst), (ins SPR:$a, fbits32:$fbits),
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
IIC_fpCVTIS, "vcvt", ".f32.s32\t$dst, $a, $fbits", []>,
Sched<[WriteFPCVT]> {
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
}
Added VCVT (between floating-point and fixed-point, VFP) for disassembly. A8.6.297 llvm-svn: 95885
2010-02-12 02:17:16 +08:00
Fix VCVT decoding (between floating-point and fixed-point, Floating-point). Patch by Richard Barton. llvm-svn: 152814
2012-03-16 01:50:29 +08:00
def VULTOS : AVConv1XInsS_Encode<0b11101, 0b11, 0b1011, 0b1010, 1,
ARM VFP assembly parsing and encoding for VCVT(float <--> fixed point). rdar://10558523 llvm-svn: 147189
2011-12-23 06:19:05 +08:00
(outs SPR:$dst), (ins SPR:$a, fbits32:$fbits),
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
IIC_fpCVTIS, "vcvt", ".f32.u32\t$dst, $a, $fbits", []>,
Sched<[WriteFPCVT]> {
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
}
Added VCVT (between floating-point and fixed-point, VFP) for disassembly. A8.6.297 llvm-svn: 95885
2010-02-12 02:17:16 +08:00
Fix VCVT decoding (between floating-point and fixed-point, Floating-point). Patch by Richard Barton. llvm-svn: 152814
2012-03-16 01:50:29 +08:00
def VSHTOD : AVConv1XInsD_Encode<0b11101, 0b11, 0b1010, 0b1011, 0,
ARM VFP assembly parsing and encoding for VCVT(float <--> fixed point). rdar://10558523 llvm-svn: 147189
2011-12-23 06:19:05 +08:00
(outs DPR:$dst), (ins DPR:$a, fbits16:$fbits),
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
IIC_fpCVTID, "vcvt", ".f64.s16\t$dst, $a, $fbits", []>,
Sched<[WriteFPCVT]>;
Added VCVT (between floating-point and fixed-point, VFP) for disassembly. A8.6.297 llvm-svn: 95885
2010-02-12 02:17:16 +08:00
Fix VCVT decoding (between floating-point and fixed-point, Floating-point). Patch by Richard Barton. llvm-svn: 152814
2012-03-16 01:50:29 +08:00
def VUHTOD : AVConv1XInsD_Encode<0b11101, 0b11, 0b1011, 0b1011, 0,
ARM VFP assembly parsing and encoding for VCVT(float <--> fixed point). rdar://10558523 llvm-svn: 147189
2011-12-23 06:19:05 +08:00
(outs DPR:$dst), (ins DPR:$a, fbits16:$fbits),
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
IIC_fpCVTID, "vcvt", ".f64.u16\t$dst, $a, $fbits", []>,
Sched<[WriteFPCVT]>;
Added VCVT (between floating-point and fixed-point, VFP) for disassembly. A8.6.297 llvm-svn: 95885
2010-02-12 02:17:16 +08:00
Fix VCVT decoding (between floating-point and fixed-point, Floating-point). Patch by Richard Barton. llvm-svn: 152814
2012-03-16 01:50:29 +08:00
def VSLTOD : AVConv1XInsD_Encode<0b11101, 0b11, 0b1010, 0b1011, 1,
ARM VFP assembly parsing and encoding for VCVT(float <--> fixed point). rdar://10558523 llvm-svn: 147189
2011-12-23 06:19:05 +08:00
(outs DPR:$dst), (ins DPR:$a, fbits32:$fbits),
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
IIC_fpCVTID, "vcvt", ".f64.s32\t$dst, $a, $fbits", []>,
Sched<[WriteFPCVT]>;
Added VCVT (between floating-point and fixed-point, VFP) for disassembly. A8.6.297 llvm-svn: 95885
2010-02-12 02:17:16 +08:00
Fix VCVT decoding (between floating-point and fixed-point, Floating-point). Patch by Richard Barton. llvm-svn: 152814
2012-03-16 01:50:29 +08:00
def VULTOD : AVConv1XInsD_Encode<0b11101, 0b11, 0b1011, 0b1011, 1,
ARM VFP assembly parsing and encoding for VCVT(float <--> fixed point). rdar://10558523 llvm-svn: 147189
2011-12-23 06:19:05 +08:00
(outs DPR:$dst), (ins DPR:$a, fbits32:$fbits),
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
IIC_fpCVTID, "vcvt", ".f64.u32\t$dst, $a, $fbits", []>,
Sched<[WriteFPCVT]>;
Added VCVT (between floating-point and fixed-point, VFP) for disassembly. A8.6.297 llvm-svn: 95885
2010-02-12 02:17:16 +08:00
Remove some bogus comments. llvm-svn: 147169
2011-12-23 03:45:01 +08:00
} // End of 'let Constraints = "$a = $dst" in'
Added VCVT (between floating-point and fixed-point, VFP) for disassembly. A8.6.297 llvm-svn: 95885
2010-02-12 02:17:16 +08:00
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
//===----------------------------------------------------------------------===//
The VMLA instruction and its friends are not actually fused; they're plain old multiply-accumulate instructions with separate rounding steps. llvm-svn: 134609
2011-07-07 16:28:52 +08:00
// FP Multiply-Accumulate Operations.
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
//
Add some missing isel predicates on def : pat patterns to avoid generating VFP vmla / vmls (they cause stalls). Disabling them in isel is properly not a right solution, I'll look into a proper solution next. llvm-svn: 118922
2010-11-13 04:32:20 +08:00
def VMLAD : ADbI<0b11100, 0b00, 0, 0,
(outs DPR:$Dd), (ins DPR:$Ddin, DPR:$Dn, DPR:$Dm),
IIC_fpMAC64, "vmla", ".f64\t$Dd, $Dn, $Dm",
Making use of VFP / NEON floating point multiply-accumulate / subtraction is difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Work in progress, only A+B are enabled. llvm-svn: 120960
2010-12-06 06:04:16 +08:00
[(set DPR:$Dd, (fadd_mlx (fmul_su DPR:$Dn, DPR:$Dm),
(f64 DPR:$Ddin)))]>,
Add some missing isel predicates on def : pat patterns to avoid generating VFP vmla / vmls (they cause stalls). Disabling them in isel is properly not a right solution, I'll look into a proper solution next. llvm-svn: 118922
2010-11-13 04:32:20 +08:00
RegConstraint<"$Ddin = $Dd">,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasVFP2,HasDPVFP,UseFPVMLx,DontUseFusedMAC]>,
Sched<[WriteFPMAC64, ReadFPMAC, ReadFPMUL, ReadFPMUL]>;
- Add encodings for multiply add/subtract instructions in all their glory. - Add missing patterns for some multiply add/subtract instructions. - Add encodings for VMRS and VMSR. llvm-svn: 116464
2010-10-14 09:02:08 +08:00
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VMLAS : ASbIn<0b11100, 0b00, 0, 0,
(outs SPR:$Sd), (ins SPR:$Sdin, SPR:$Sn, SPR:$Sm),
IIC_fpMAC32, "vmla", ".f32\t$Sd, $Sn, $Sm",
Making use of VFP / NEON floating point multiply-accumulate / subtraction is difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Work in progress, only A+B are enabled. llvm-svn: 120960
2010-12-06 06:04:16 +08:00
[(set SPR:$Sd, (fadd_mlx (fmul_su SPR:$Sn, SPR:$Sm),
SPR:$Sdin))]>,
Add some missing isel predicates on def : pat patterns to avoid generating VFP vmla / vmls (they cause stalls). Disabling them in isel is properly not a right solution, I'll look into a proper solution next. llvm-svn: 118922
2010-11-13 04:32:20 +08:00
RegConstraint<"$Sdin = $Sd">,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasVFP2,DontUseNEONForFP,UseFPVMLx,DontUseFusedMAC]>,
Sched<[WriteFPMAC32, ReadFPMAC, ReadFPMUL, ReadFPMUL]> {
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
}
- Add encodings for multiply add/subtract instructions in all their glory. - Add missing patterns for some multiply add/subtract instructions. - Add encodings for VMRS and VMSR. llvm-svn: 116464
2010-10-14 09:02:08 +08:00
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VMLAH : AHbI<0b11100, 0b00, 0, 0,
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
(outs HPR:$Sd), (ins HPR:$Sdin, HPR:$Sn, HPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpMAC16, "vmla", ".f16\t$Sd, $Sn, $Sm",
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
[(set HPR:$Sd, (fadd_mlx (fmul_su HPR:$Sn, HPR:$Sm),
HPR:$Sdin))]>,
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
RegConstraint<"$Sdin = $Sd">,
Requires<[HasFullFP16,UseFPVMLx,DontUseFusedMAC]>;
Making use of VFP / NEON floating point multiply-accumulate / subtraction is difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Work in progress, only A+B are enabled. llvm-svn: 120960
2010-12-06 06:04:16 +08:00
def : Pat<(fadd_mlx DPR:$dstin, (fmul_su DPR:$a, (f64 DPR:$b))),
Add some missing isel predicates on def : pat patterns to avoid generating VFP vmla / vmls (they cause stalls). Disabling them in isel is properly not a right solution, I'll look into a proper solution next. llvm-svn: 118922
2010-11-13 04:32:20 +08:00
(VMLAD DPR:$dstin, DPR:$a, DPR:$b)>,
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
Requires<[HasVFP2,HasDPVFP,UseFPVMLx,DontUseFusedMAC]>;
Making use of VFP / NEON floating point multiply-accumulate / subtraction is difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Work in progress, only A+B are enabled. llvm-svn: 120960
2010-12-06 06:04:16 +08:00
def : Pat<(fadd_mlx SPR:$dstin, (fmul_su SPR:$a, SPR:$b)),
Add some missing isel predicates on def : pat patterns to avoid generating VFP vmla / vmls (they cause stalls). Disabling them in isel is properly not a right solution, I'll look into a proper solution next. llvm-svn: 118922
2010-11-13 04:32:20 +08:00
(VMLAS SPR:$dstin, SPR:$a, SPR:$b)>,
Clean up ARM fused multiply + add/sub support some more: rename some isel predicates. Also remove NEON2 since it's not really useful and it is confusing. If NEON + VFP4 implies NEON2 but NEON2 doesn't imply NEON + VFP4, what does it really mean? rdar://10139676 llvm-svn: 154480
2012-04-11 13:33:07 +08:00
Requires<[HasVFP2,DontUseNEONForFP, UseFPVMLx,DontUseFusedMAC]>;
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
def : Pat<(fadd_mlx HPR:$dstin, (fmul_su HPR:$a, HPR:$b)),
(VMLAH HPR:$dstin, HPR:$a, HPR:$b)>,
Requires<[HasFullFP16,DontUseNEONForFP, UseFPVMLx,DontUseFusedMAC]>;
- Add encodings for multiply add/subtract instructions in all their glory. - Add missing patterns for some multiply add/subtract instructions. - Add encodings for VMRS and VMSR. llvm-svn: 116464
2010-10-14 09:02:08 +08:00
Add some missing isel predicates on def : pat patterns to avoid generating VFP vmla / vmls (they cause stalls). Disabling them in isel is properly not a right solution, I'll look into a proper solution next. llvm-svn: 118922
2010-11-13 04:32:20 +08:00
def VMLSD : ADbI<0b11100, 0b00, 1, 0,
(outs DPR:$Dd), (ins DPR:$Ddin, DPR:$Dn, DPR:$Dm),
IIC_fpMAC64, "vmls", ".f64\t$Dd, $Dn, $Dm",
Making use of VFP / NEON floating point multiply-accumulate / subtraction is difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Work in progress, only A+B are enabled. llvm-svn: 120960
2010-12-06 06:04:16 +08:00
[(set DPR:$Dd, (fadd_mlx (fneg (fmul_su DPR:$Dn,DPR:$Dm)),
(f64 DPR:$Ddin)))]>,
Add some missing isel predicates on def : pat patterns to avoid generating VFP vmla / vmls (they cause stalls). Disabling them in isel is properly not a right solution, I'll look into a proper solution next. llvm-svn: 118922
2010-11-13 04:32:20 +08:00
RegConstraint<"$Ddin = $Dd">,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasVFP2,HasDPVFP,UseFPVMLx,DontUseFusedMAC]>,
Sched<[WriteFPMAC64, ReadFPMAC, ReadFPMUL, ReadFPMUL]>;
- Add encodings for multiply add/subtract instructions in all their glory. - Add missing patterns for some multiply add/subtract instructions. - Add encodings for VMRS and VMSR. llvm-svn: 116464
2010-10-14 09:02:08 +08:00
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VMLSS : ASbIn<0b11100, 0b00, 1, 0,
(outs SPR:$Sd), (ins SPR:$Sdin, SPR:$Sn, SPR:$Sm),
IIC_fpMAC32, "vmls", ".f32\t$Sd, $Sn, $Sm",
Making use of VFP / NEON floating point multiply-accumulate / subtraction is difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Work in progress, only A+B are enabled. llvm-svn: 120960
2010-12-06 06:04:16 +08:00
[(set SPR:$Sd, (fadd_mlx (fneg (fmul_su SPR:$Sn, SPR:$Sm)),
SPR:$Sdin))]>,
Add some missing isel predicates on def : pat patterns to avoid generating VFP vmla / vmls (they cause stalls). Disabling them in isel is properly not a right solution, I'll look into a proper solution next. llvm-svn: 118922
2010-11-13 04:32:20 +08:00
RegConstraint<"$Sdin = $Sd">,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasVFP2,DontUseNEONForFP,UseFPVMLx,DontUseFusedMAC]>,
Sched<[WriteFPMAC32, ReadFPMAC, ReadFPMUL, ReadFPMUL]> {
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
}
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VMLSH : AHbI<0b11100, 0b00, 1, 0,
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
(outs HPR:$Sd), (ins HPR:$Sdin, HPR:$Sn, HPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpMAC16, "vmls", ".f16\t$Sd, $Sn, $Sm",
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
[(set HPR:$Sd, (fadd_mlx (fneg (fmul_su HPR:$Sn, HPR:$Sm)),
HPR:$Sdin))]>,
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
RegConstraint<"$Sdin = $Sd">,
Requires<[HasFullFP16,UseFPVMLx,DontUseFusedMAC]>;
Making use of VFP / NEON floating point multiply-accumulate / subtraction is difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Work in progress, only A+B are enabled. llvm-svn: 120960
2010-12-06 06:04:16 +08:00
def : Pat<(fsub_mlx DPR:$dstin, (fmul_su DPR:$a, (f64 DPR:$b))),
Add some missing isel predicates on def : pat patterns to avoid generating VFP vmla / vmls (they cause stalls). Disabling them in isel is properly not a right solution, I'll look into a proper solution next. llvm-svn: 118922
2010-11-13 04:32:20 +08:00
(VMLSD DPR:$dstin, DPR:$a, DPR:$b)>,
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
Requires<[HasVFP2,HasDPVFP,UseFPVMLx,DontUseFusedMAC]>;
Making use of VFP / NEON floating point multiply-accumulate / subtraction is difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Work in progress, only A+B are enabled. llvm-svn: 120960
2010-12-06 06:04:16 +08:00
def : Pat<(fsub_mlx SPR:$dstin, (fmul_su SPR:$a, SPR:$b)),
Add some missing isel predicates on def : pat patterns to avoid generating VFP vmla / vmls (they cause stalls). Disabling them in isel is properly not a right solution, I'll look into a proper solution next. llvm-svn: 118922
2010-11-13 04:32:20 +08:00
(VMLSS SPR:$dstin, SPR:$a, SPR:$b)>,
Clean up ARM fused multiply + add/sub support some more: rename some isel predicates. Also remove NEON2 since it's not really useful and it is confusing. If NEON + VFP4 implies NEON2 but NEON2 doesn't imply NEON + VFP4, what does it really mean? rdar://10139676 llvm-svn: 154480
2012-04-11 13:33:07 +08:00
Requires<[HasVFP2,DontUseNEONForFP,UseFPVMLx,DontUseFusedMAC]>;
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
def : Pat<(fsub_mlx HPR:$dstin, (fmul_su HPR:$a, HPR:$b)),
(VMLSH HPR:$dstin, HPR:$a, HPR:$b)>,
Requires<[HasFullFP16,DontUseNEONForFP,UseFPVMLx,DontUseFusedMAC]>;
Match common pattern for FNMAC. Add NEON SP support. llvm-svn: 78085
2009-08-05 02:44:29 +08:00
Add some missing isel predicates on def : pat patterns to avoid generating VFP vmla / vmls (they cause stalls). Disabling them in isel is properly not a right solution, I'll look into a proper solution next. llvm-svn: 118922
2010-11-13 04:32:20 +08:00
def VNMLAD : ADbI<0b11100, 0b01, 1, 0,
(outs DPR:$Dd), (ins DPR:$Ddin, DPR:$Dn, DPR:$Dm),
IIC_fpMAC64, "vnmla", ".f64\t$Dd, $Dn, $Dm",
Making use of VFP / NEON floating point multiply-accumulate / subtraction is difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Work in progress, only A+B are enabled. llvm-svn: 120960
2010-12-06 06:04:16 +08:00
[(set DPR:$Dd,(fsub_mlx (fneg (fmul_su DPR:$Dn,DPR:$Dm)),
(f64 DPR:$Ddin)))]>,
Add some missing isel predicates on def : pat patterns to avoid generating VFP vmla / vmls (they cause stalls). Disabling them in isel is properly not a right solution, I'll look into a proper solution next. llvm-svn: 118922
2010-11-13 04:32:20 +08:00
RegConstraint<"$Ddin = $Dd">,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasVFP2,HasDPVFP,UseFPVMLx,DontUseFusedMAC]>,
Sched<[WriteFPMAC64, ReadFPMAC, ReadFPMUL, ReadFPMUL]>;
- Add encodings for multiply add/subtract instructions in all their glory. - Add missing patterns for some multiply add/subtract instructions. - Add encodings for VMRS and VMSR. llvm-svn: 116464
2010-10-14 09:02:08 +08:00
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VNMLAS : ASbI<0b11100, 0b01, 1, 0,
(outs SPR:$Sd), (ins SPR:$Sdin, SPR:$Sn, SPR:$Sm),
IIC_fpMAC32, "vnmla", ".f32\t$Sd, $Sn, $Sm",
Making use of VFP / NEON floating point multiply-accumulate / subtraction is difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Work in progress, only A+B are enabled. llvm-svn: 120960
2010-12-06 06:04:16 +08:00
[(set SPR:$Sd, (fsub_mlx (fneg (fmul_su SPR:$Sn, SPR:$Sm)),
SPR:$Sdin))]>,
Add some missing isel predicates on def : pat patterns to avoid generating VFP vmla / vmls (they cause stalls). Disabling them in isel is properly not a right solution, I'll look into a proper solution next. llvm-svn: 118922
2010-11-13 04:32:20 +08:00
RegConstraint<"$Sdin = $Sd">,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasVFP2,DontUseNEONForFP,UseFPVMLx,DontUseFusedMAC]>,
Sched<[WriteFPMAC32, ReadFPMAC, ReadFPMUL, ReadFPMUL]> {
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
}
- Add encodings for multiply add/subtract instructions in all their glory. - Add missing patterns for some multiply add/subtract instructions. - Add encodings for VMRS and VMSR. llvm-svn: 116464
2010-10-14 09:02:08 +08:00
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VNMLAH : AHbI<0b11100, 0b01, 1, 0,
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
(outs HPR:$Sd), (ins HPR:$Sdin, HPR:$Sn, HPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpMAC16, "vnmla", ".f16\t$Sd, $Sn, $Sm",
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
[(set HPR:$Sd, (fsub_mlx (fneg (fmul_su HPR:$Sn, HPR:$Sm)),
HPR:$Sdin))]>,
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
RegConstraint<"$Sdin = $Sd">,
Requires<[HasFullFP16,UseFPVMLx,DontUseFusedMAC]>;
[ARM] Add missing selection patterns for vnmla For the following function: double fn1(double d0, double d1, double d2) { double a = -d0 - d1 * d2; return a; } on ARM, LLVM generates code along the lines of vneg.f64 d0, d0 vmls.f64 d0, d1, d2 i.e., a negate and a multiply-subtract. The attached patch adds instruction selection patterns to allow it to generate the single instruction vnmla.f64 d0, d1, d2 (multiply-add with negation) instead, like GCC does. Committed on behalf of @gergo- (Gergö Barany) Differential Revision: https://reviews.llvm.org/D35911 llvm-svn: 313972
2017-09-22 17:50:52 +08:00
// (-(a * b) - dst) -> -(dst + (a * b))
Making use of VFP / NEON floating point multiply-accumulate / subtraction is difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Work in progress, only A+B are enabled. llvm-svn: 120960
2010-12-06 06:04:16 +08:00
def : Pat<(fsub_mlx (fneg (fmul_su DPR:$a, (f64 DPR:$b))), DPR:$dstin),
Add some missing isel predicates on def : pat patterns to avoid generating VFP vmla / vmls (they cause stalls). Disabling them in isel is properly not a right solution, I'll look into a proper solution next. llvm-svn: 118922
2010-11-13 04:32:20 +08:00
(VNMLAD DPR:$dstin, DPR:$a, DPR:$b)>,
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
Requires<[HasVFP2,HasDPVFP,UseFPVMLx,DontUseFusedMAC]>;
Making use of VFP / NEON floating point multiply-accumulate / subtraction is difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Work in progress, only A+B are enabled. llvm-svn: 120960
2010-12-06 06:04:16 +08:00
def : Pat<(fsub_mlx (fneg (fmul_su SPR:$a, SPR:$b)), SPR:$dstin),
Add some missing isel predicates on def : pat patterns to avoid generating VFP vmla / vmls (they cause stalls). Disabling them in isel is properly not a right solution, I'll look into a proper solution next. llvm-svn: 118922
2010-11-13 04:32:20 +08:00
(VNMLAS SPR:$dstin, SPR:$a, SPR:$b)>,
Clean up ARM fused multiply + add/sub support some more: rename some isel predicates. Also remove NEON2 since it's not really useful and it is confusing. If NEON + VFP4 implies NEON2 but NEON2 doesn't imply NEON + VFP4, what does it really mean? rdar://10139676 llvm-svn: 154480
2012-04-11 13:33:07 +08:00
Requires<[HasVFP2,DontUseNEONForFP,UseFPVMLx,DontUseFusedMAC]>;
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
def : Pat<(fsub_mlx (fneg (fmul_su HPR:$a, HPR:$b)), HPR:$dstin),
(VNMLAH HPR:$dstin, HPR:$a, HPR:$b)>,
Requires<[HasFullFP16,DontUseNEONForFP,UseFPVMLx,DontUseFusedMAC]>;
- Add encodings for multiply add/subtract instructions in all their glory. - Add missing patterns for some multiply add/subtract instructions. - Add encodings for VMRS and VMSR. llvm-svn: 116464
2010-10-14 09:02:08 +08:00
[ARM] Add missing selection patterns for vnmla For the following function: double fn1(double d0, double d1, double d2) { double a = -d0 - d1 * d2; return a; } on ARM, LLVM generates code along the lines of vneg.f64 d0, d0 vmls.f64 d0, d1, d2 i.e., a negate and a multiply-subtract. The attached patch adds instruction selection patterns to allow it to generate the single instruction vnmla.f64 d0, d1, d2 (multiply-add with negation) instead, like GCC does. Committed on behalf of @gergo- (Gergö Barany) Differential Revision: https://reviews.llvm.org/D35911 llvm-svn: 313972
2017-09-22 17:50:52 +08:00
// (-dst - (a * b)) -> -(dst + (a * b))
def : Pat<(fsub_mlx (fneg DPR:$dstin), (fmul_su DPR:$a, (f64 DPR:$b))),
(VNMLAD DPR:$dstin, DPR:$a, DPR:$b)>,
Requires<[HasVFP2,HasDPVFP,UseFPVMLx,DontUseFusedMAC]>;
def : Pat<(fsub_mlx (fneg SPR:$dstin), (fmul_su SPR:$a, SPR:$b)),
(VNMLAS SPR:$dstin, SPR:$a, SPR:$b)>,
Requires<[HasVFP2,DontUseNEONForFP,UseFPVMLx,DontUseFusedMAC]>;
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
def : Pat<(fsub_mlx (fneg HPR:$dstin), (fmul_su HPR:$a, HPR:$b)),
(VNMLAH HPR:$dstin, HPR:$a, HPR:$b)>,
Requires<[HasFullFP16,DontUseNEONForFP,UseFPVMLx,DontUseFusedMAC]>;
[ARM] Add missing selection patterns for vnmla For the following function: double fn1(double d0, double d1, double d2) { double a = -d0 - d1 * d2; return a; } on ARM, LLVM generates code along the lines of vneg.f64 d0, d0 vmls.f64 d0, d1, d2 i.e., a negate and a multiply-subtract. The attached patch adds instruction selection patterns to allow it to generate the single instruction vnmla.f64 d0, d1, d2 (multiply-add with negation) instead, like GCC does. Committed on behalf of @gergo- (Gergö Barany) Differential Revision: https://reviews.llvm.org/D35911 llvm-svn: 313972
2017-09-22 17:50:52 +08:00
Add some missing isel predicates on def : pat patterns to avoid generating VFP vmla / vmls (they cause stalls). Disabling them in isel is properly not a right solution, I'll look into a proper solution next. llvm-svn: 118922
2010-11-13 04:32:20 +08:00
def VNMLSD : ADbI<0b11100, 0b01, 0, 0,
(outs DPR:$Dd), (ins DPR:$Ddin, DPR:$Dn, DPR:$Dm),
IIC_fpMAC64, "vnmls", ".f64\t$Dd, $Dn, $Dm",
Making use of VFP / NEON floating point multiply-accumulate / subtraction is difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Work in progress, only A+B are enabled. llvm-svn: 120960
2010-12-06 06:04:16 +08:00
[(set DPR:$Dd, (fsub_mlx (fmul_su DPR:$Dn, DPR:$Dm),
(f64 DPR:$Ddin)))]>,
Add some missing isel predicates on def : pat patterns to avoid generating VFP vmla / vmls (they cause stalls). Disabling them in isel is properly not a right solution, I'll look into a proper solution next. llvm-svn: 118922
2010-11-13 04:32:20 +08:00
RegConstraint<"$Ddin = $Dd">,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasVFP2,HasDPVFP,UseFPVMLx,DontUseFusedMAC]>,
Sched<[WriteFPMAC64, ReadFPMAC, ReadFPMUL, ReadFPMUL]>;
- Add encodings for multiply add/subtract instructions in all their glory. - Add missing patterns for some multiply add/subtract instructions. - Add encodings for VMRS and VMSR. llvm-svn: 116464
2010-10-14 09:02:08 +08:00
Move instruction encoding bits into the parent class and remove the temporary *_Encode classes. These instructions are the only ones which use those classes, so a subclass isn't necessary. llvm-svn: 117906
2010-11-01 14:00:39 +08:00
def VNMLSS : ASbI<0b11100, 0b01, 0, 0,
(outs SPR:$Sd), (ins SPR:$Sdin, SPR:$Sn, SPR:$Sm),
IIC_fpMAC32, "vnmls", ".f32\t$Sd, $Sn, $Sm",
Making use of VFP / NEON floating point multiply-accumulate / subtraction is difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Work in progress, only A+B are enabled. llvm-svn: 120960
2010-12-06 06:04:16 +08:00
[(set SPR:$Sd, (fsub_mlx (fmul_su SPR:$Sn, SPR:$Sm), SPR:$Sdin))]>,
Add some missing isel predicates on def : pat patterns to avoid generating VFP vmla / vmls (they cause stalls). Disabling them in isel is properly not a right solution, I'll look into a proper solution next. llvm-svn: 118922
2010-11-13 04:32:20 +08:00
RegConstraint<"$Sdin = $Sd">,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasVFP2,DontUseNEONForFP,UseFPVMLx,DontUseFusedMAC]>,
Sched<[WriteFPMAC32, ReadFPMAC, ReadFPMUL, ReadFPMUL]> {
VFP single precision arith instructions can go down to NEON pipeline, but on Cortex-A8 only. llvm-svn: 126238
2011-02-23 03:53:14 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines on A8.
let D = VFPNeonA8Domain;
Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones. llvm-svn: 125624
2011-02-16 08:35:02 +08:00
}
- Add encodings for multiply add/subtract instructions in all their glory. - Add missing patterns for some multiply add/subtract instructions. - Add encodings for VMRS and VMSR. llvm-svn: 116464
2010-10-14 09:02:08 +08:00
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VNMLSH : AHbI<0b11100, 0b01, 0, 0,
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
(outs HPR:$Sd), (ins HPR:$Sdin, HPR:$Sn, HPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpMAC16, "vnmls", ".f16\t$Sd, $Sn, $Sm",
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
[(set HPR:$Sd, (fsub_mlx (fmul_su HPR:$Sn, HPR:$Sm), HPR:$Sdin))]>,
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
RegConstraint<"$Sdin = $Sd">,
Requires<[HasFullFP16,UseFPVMLx,DontUseFusedMAC]>;
Making use of VFP / NEON floating point multiply-accumulate / subtraction is difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Work in progress, only A+B are enabled. llvm-svn: 120960
2010-12-06 06:04:16 +08:00
def : Pat<(fsub_mlx (fmul_su DPR:$a, (f64 DPR:$b)), DPR:$dstin),
Add some missing isel predicates on def : pat patterns to avoid generating VFP vmla / vmls (they cause stalls). Disabling them in isel is properly not a right solution, I'll look into a proper solution next. llvm-svn: 118922
2010-11-13 04:32:20 +08:00
(VNMLSD DPR:$dstin, DPR:$a, DPR:$b)>,
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
Requires<[HasVFP2,HasDPVFP,UseFPVMLx,DontUseFusedMAC]>;
Making use of VFP / NEON floating point multiply-accumulate / subtraction is difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Work in progress, only A+B are enabled. llvm-svn: 120960
2010-12-06 06:04:16 +08:00
def : Pat<(fsub_mlx (fmul_su SPR:$a, SPR:$b), SPR:$dstin),
Add some missing isel predicates on def : pat patterns to avoid generating VFP vmla / vmls (they cause stalls). Disabling them in isel is properly not a right solution, I'll look into a proper solution next. llvm-svn: 118922
2010-11-13 04:32:20 +08:00
(VNMLSS SPR:$dstin, SPR:$a, SPR:$b)>,
Clean up ARM fused multiply + add/sub support some more: rename some isel predicates. Also remove NEON2 since it's not really useful and it is confusing. If NEON + VFP4 implies NEON2 but NEON2 doesn't imply NEON + VFP4, what does it really mean? rdar://10139676 llvm-svn: 154480
2012-04-11 13:33:07 +08:00
Requires<[HasVFP2,DontUseNEONForFP,UseFPVMLx,DontUseFusedMAC]>;
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
def : Pat<(fsub_mlx (fmul_su HPR:$a, HPR:$b), HPR:$dstin),
(VNMLSH HPR:$dstin, HPR:$a, HPR:$b)>,
Requires<[HasFullFP16,DontUseNEONForFP,UseFPVMLx,DontUseFusedMAC]>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
//===----------------------------------------------------------------------===//
// Fused FP Multiply-Accumulate Operations.
//
def VFMAD : ADbI<0b11101, 0b10, 0, 0,
(outs DPR:$Dd), (ins DPR:$Ddin, DPR:$Dn, DPR:$Dm),
IIC_fpFMAC64, "vfma", ".f64\t$Dd, $Dn, $Dm",
[(set DPR:$Dd, (fadd_mlx (fmul_su DPR:$Dn, DPR:$Dm),
(f64 DPR:$Ddin)))]>,
RegConstraint<"$Ddin = $Dd">,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasVFP4,HasDPVFP,UseFusedMAC]>,
Sched<[WriteFPMAC64, ReadFPMAC, ReadFPMUL, ReadFPMUL]>;
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
def VFMAS : ASbIn<0b11101, 0b10, 0, 0,
(outs SPR:$Sd), (ins SPR:$Sdin, SPR:$Sn, SPR:$Sm),
IIC_fpFMAC32, "vfma", ".f32\t$Sd, $Sn, $Sm",
[(set SPR:$Sd, (fadd_mlx (fmul_su SPR:$Sn, SPR:$Sm),
SPR:$Sdin))]>,
RegConstraint<"$Sdin = $Sd">,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasVFP4,DontUseNEONForFP,UseFusedMAC]>,
Sched<[WriteFPMAC32, ReadFPMAC, ReadFPMUL, ReadFPMUL]> {
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines.
}
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VFMAH : AHbI<0b11101, 0b10, 0, 0,
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
(outs HPR:$Sd), (ins HPR:$Sdin, HPR:$Sn, HPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpFMAC16, "vfma", ".f16\t$Sd, $Sn, $Sm",
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
[(set HPR:$Sd, (fadd_mlx (fmul_su HPR:$Sn, HPR:$Sm),
HPR:$Sdin))]>,
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
RegConstraint<"$Sdin = $Sd">,
[ARM] Classification Improvements to ARM Sched-Models. NFCI. This is a series of patches to enable adding of machine sched models for ARM processors easier and compact. They define new sched-readwrites for groups of ARM instructions. This has been missing so far, and as a consequence, machine scheduler models for individual sub-targets have tended to be larger than they needed to be. The current patch focuses on floating-point instructions. Reviewers: Diana Picus (rovka), Renato Golin (rengolin) Differential Revision: https://reviews.llvm.org/D28194 llvm-svn: 292825
2017-01-24 04:20:39 +08:00
Requires<[HasFullFP16,UseFusedMAC]>,
Sched<[WriteFPMAC32, ReadFPMAC, ReadFPMUL, ReadFPMUL]>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
def : Pat<(fadd_mlx DPR:$dstin, (fmul_su DPR:$a, (f64 DPR:$b))),
(VFMAD DPR:$dstin, DPR:$a, DPR:$b)>,
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
Requires<[HasVFP4,HasDPVFP,UseFusedMAC]>;
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
def : Pat<(fadd_mlx SPR:$dstin, (fmul_su SPR:$a, SPR:$b)),
(VFMAS SPR:$dstin, SPR:$a, SPR:$b)>,
Clean up ARM fused multiply + add/sub support some more: rename some isel predicates. Also remove NEON2 since it's not really useful and it is confusing. If NEON + VFP4 implies NEON2 but NEON2 doesn't imply NEON + VFP4, what does it really mean? rdar://10139676 llvm-svn: 154480
2012-04-11 13:33:07 +08:00
Requires<[HasVFP4,DontUseNEONForFP,UseFusedMAC]>;
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
def : Pat<(fadd_mlx HPR:$dstin, (fmul_su HPR:$a, HPR:$b)),
(VFMAH HPR:$dstin, HPR:$a, HPR:$b)>,
Requires<[HasFullFP16,DontUseNEONForFP,UseFusedMAC]>;
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
Handle llvm.fma.* intrinsics. rdar://10914096 llvm-svn: 154439
2012-04-11 05:40:28 +08:00
// Match @llvm.fma.* intrinsics
Fix the order of the operands in the llvm.fma intrinsic patterns for ARM, <rdar://problem/11325085>. llvm-svn: 155724
2012-04-28 02:51:24 +08:00
// (fma x, y, z) -> (vfms z, x, y)
def : Pat<(f64 (fma DPR:$Dn, DPR:$Dm, DPR:$Ddin)),
Handle llvm.fma.* intrinsics. rdar://10914096 llvm-svn: 154439
2012-04-11 05:40:28 +08:00
(VFMAD DPR:$Ddin, DPR:$Dn, DPR:$Dm)>,
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
Requires<[HasVFP4,HasDPVFP]>;
Fix the order of the operands in the llvm.fma intrinsic patterns for ARM, <rdar://problem/11325085>. llvm-svn: 155724
2012-04-28 02:51:24 +08:00
def : Pat<(f32 (fma SPR:$Sn, SPR:$Sm, SPR:$Sdin)),
Handle llvm.fma.* intrinsics. rdar://10914096 llvm-svn: 154439
2012-04-11 05:40:28 +08:00
(VFMAS SPR:$Sdin, SPR:$Sn, SPR:$Sm)>,
Requires<[HasVFP4]>;
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
def VFMSD : ADbI<0b11101, 0b10, 1, 0,
(outs DPR:$Dd), (ins DPR:$Ddin, DPR:$Dn, DPR:$Dm),
IIC_fpFMAC64, "vfms", ".f64\t$Dd, $Dn, $Dm",
[(set DPR:$Dd, (fadd_mlx (fneg (fmul_su DPR:$Dn,DPR:$Dm)),
(f64 DPR:$Ddin)))]>,
RegConstraint<"$Ddin = $Dd">,
[ARM] Add scheduling info for VFMS The scalar VFMS instructions did not have scheduling information attached (but VFMA did), which was causing assertion failures with the Cortex-A57 scheduling model and -fp-contract=fast. Differential Revision: https://reviews.llvm.org/D34040 llvm-svn: 305064
2017-06-09 17:19:09 +08:00
Requires<[HasVFP4,HasDPVFP,UseFusedMAC]>,
Sched<[WriteFPMAC64, ReadFPMAC, ReadFPMUL, ReadFPMUL]>;
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
def VFMSS : ASbIn<0b11101, 0b10, 1, 0,
(outs SPR:$Sd), (ins SPR:$Sdin, SPR:$Sn, SPR:$Sm),
IIC_fpFMAC32, "vfms", ".f32\t$Sd, $Sn, $Sm",
[(set SPR:$Sd, (fadd_mlx (fneg (fmul_su SPR:$Sn, SPR:$Sm)),
SPR:$Sdin))]>,
RegConstraint<"$Sdin = $Sd">,
[ARM] Add scheduling info for VFMS The scalar VFMS instructions did not have scheduling information attached (but VFMA did), which was causing assertion failures with the Cortex-A57 scheduling model and -fp-contract=fast. Differential Revision: https://reviews.llvm.org/D34040 llvm-svn: 305064
2017-06-09 17:19:09 +08:00
Requires<[HasVFP4,DontUseNEONForFP,UseFusedMAC]>,
Sched<[WriteFPMAC32, ReadFPMAC, ReadFPMUL, ReadFPMUL]> {
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines.
}
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VFMSH : AHbI<0b11101, 0b10, 1, 0,
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
(outs HPR:$Sd), (ins HPR:$Sdin, HPR:$Sn, HPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpFMAC16, "vfms", ".f16\t$Sd, $Sn, $Sm",
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
[(set HPR:$Sd, (fadd_mlx (fneg (fmul_su HPR:$Sn, HPR:$Sm)),
HPR:$Sdin))]>,
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
RegConstraint<"$Sdin = $Sd">,
[ARM] Add scheduling info for VFMS The scalar VFMS instructions did not have scheduling information attached (but VFMA did), which was causing assertion failures with the Cortex-A57 scheduling model and -fp-contract=fast. Differential Revision: https://reviews.llvm.org/D34040 llvm-svn: 305064
2017-06-09 17:19:09 +08:00
Requires<[HasFullFP16,UseFusedMAC]>,
Sched<[WriteFPMAC32, ReadFPMAC, ReadFPMUL, ReadFPMUL]>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
def : Pat<(fsub_mlx DPR:$dstin, (fmul_su DPR:$a, (f64 DPR:$b))),
(VFMSD DPR:$dstin, DPR:$a, DPR:$b)>,
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
Requires<[HasVFP4,HasDPVFP,UseFusedMAC]>;
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
def : Pat<(fsub_mlx SPR:$dstin, (fmul_su SPR:$a, SPR:$b)),
(VFMSS SPR:$dstin, SPR:$a, SPR:$b)>,
Clean up ARM fused multiply + add/sub support some more: rename some isel predicates. Also remove NEON2 since it's not really useful and it is confusing. If NEON + VFP4 implies NEON2 but NEON2 doesn't imply NEON + VFP4, what does it really mean? rdar://10139676 llvm-svn: 154480
2012-04-11 13:33:07 +08:00
Requires<[HasVFP4,DontUseNEONForFP,UseFusedMAC]>;
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
def : Pat<(fsub_mlx HPR:$dstin, (fmul_su HPR:$a, HPR:$b)),
(VFMSH HPR:$dstin, HPR:$a, HPR:$b)>,
Requires<[HasFullFP16,DontUseNEONForFP,UseFusedMAC]>;
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
Add more fused mul+add/sub patterns. rdar://10139676 llvm-svn: 154484
2012-04-11 14:59:47 +08:00
// Match @llvm.fma.* intrinsics
Fix the order of the operands in the llvm.fma intrinsic patterns for ARM, <rdar://problem/11325085>. llvm-svn: 155724
2012-04-28 02:51:24 +08:00
// (fma (fneg x), y, z) -> (vfms z, x, y)
def : Pat<(f64 (fma (fneg DPR:$Dn), DPR:$Dm, DPR:$Ddin)),
Add more fused mul+add/sub patterns. rdar://10139676 llvm-svn: 154484
2012-04-11 14:59:47 +08:00
(VFMSD DPR:$Ddin, DPR:$Dn, DPR:$Dm)>,
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
Requires<[HasVFP4,HasDPVFP]>;
Fix the order of the operands in the llvm.fma intrinsic patterns for ARM, <rdar://problem/11325085>. llvm-svn: 155724
2012-04-28 02:51:24 +08:00
def : Pat<(f32 (fma (fneg SPR:$Sn), SPR:$Sm, SPR:$Sdin)),
Add more fused mul+add/sub patterns. rdar://10139676 llvm-svn: 154484
2012-04-11 14:59:47 +08:00
(VFMSS SPR:$Sdin, SPR:$Sn, SPR:$Sm)>,
Requires<[HasVFP4]>;
Fix the order of the operands in the llvm.fma intrinsic patterns for ARM, <rdar://problem/11325085>. llvm-svn: 155724
2012-04-28 02:51:24 +08:00
// (fma x, (fneg y), z) -> (vfms z, x, y)
def : Pat<(f64 (fma DPR:$Dn, (fneg DPR:$Dm), DPR:$Ddin)),
Add more fused mul+add/sub patterns. rdar://10139676 llvm-svn: 154484
2012-04-11 14:59:47 +08:00
(VFMSD DPR:$Ddin, DPR:$Dn, DPR:$Dm)>,
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
Requires<[HasVFP4,HasDPVFP]>;
Fix the order of the operands in the llvm.fma intrinsic patterns for ARM, <rdar://problem/11325085>. llvm-svn: 155724
2012-04-28 02:51:24 +08:00
def : Pat<(f32 (fma SPR:$Sn, (fneg SPR:$Sm), SPR:$Sdin)),
Add more fused mul+add/sub patterns. rdar://10139676 llvm-svn: 154484
2012-04-11 14:59:47 +08:00
(VFMSS SPR:$Sdin, SPR:$Sn, SPR:$Sm)>,
Requires<[HasVFP4]>;
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
def VFNMAD : ADbI<0b11101, 0b01, 1, 0,
(outs DPR:$Dd), (ins DPR:$Ddin, DPR:$Dn, DPR:$Dm),
IIC_fpFMAC64, "vfnma", ".f64\t$Dd, $Dn, $Dm",
[(set DPR:$Dd,(fsub_mlx (fneg (fmul_su DPR:$Dn,DPR:$Dm)),
(f64 DPR:$Ddin)))]>,
RegConstraint<"$Ddin = $Dd">,
[ARM] Add scheduling classes for VFNM[AS] The VFNM[AS] instructions did not have scheduling information attached, which was causing assertion failures with the Cortex-A57 scheduling model and -fp-contract=fast, because the Cortex-A57 sched model claims to be complete. Differential Revision: https://reviews.llvm.org/D34139 llvm-svn: 305288
2017-06-13 21:04:32 +08:00
Requires<[HasVFP4,HasDPVFP,UseFusedMAC]>,
Sched<[WriteFPMAC64, ReadFPMAC, ReadFPMUL, ReadFPMUL]>;
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
def VFNMAS : ASbI<0b11101, 0b01, 1, 0,
(outs SPR:$Sd), (ins SPR:$Sdin, SPR:$Sn, SPR:$Sm),
IIC_fpFMAC32, "vfnma", ".f32\t$Sd, $Sn, $Sm",
[(set SPR:$Sd, (fsub_mlx (fneg (fmul_su SPR:$Sn, SPR:$Sm)),
SPR:$Sdin))]>,
RegConstraint<"$Sdin = $Sd">,
[ARM] Add scheduling classes for VFNM[AS] The VFNM[AS] instructions did not have scheduling information attached, which was causing assertion failures with the Cortex-A57 scheduling model and -fp-contract=fast, because the Cortex-A57 sched model claims to be complete. Differential Revision: https://reviews.llvm.org/D34139 llvm-svn: 305288
2017-06-13 21:04:32 +08:00
Requires<[HasVFP4,DontUseNEONForFP,UseFusedMAC]>,
Sched<[WriteFPMAC32, ReadFPMAC, ReadFPMUL, ReadFPMUL]> {
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines.
}
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VFNMAH : AHbI<0b11101, 0b01, 1, 0,
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
(outs HPR:$Sd), (ins HPR:$Sdin, HPR:$Sn, HPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpFMAC16, "vfnma", ".f16\t$Sd, $Sn, $Sm",
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
[(set HPR:$Sd, (fsub_mlx (fneg (fmul_su HPR:$Sn, HPR:$Sm)),
HPR:$Sdin))]>,
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
RegConstraint<"$Sdin = $Sd">,
[ARM] Add scheduling classes for VFNM[AS] The VFNM[AS] instructions did not have scheduling information attached, which was causing assertion failures with the Cortex-A57 scheduling model and -fp-contract=fast, because the Cortex-A57 sched model claims to be complete. Differential Revision: https://reviews.llvm.org/D34139 llvm-svn: 305288
2017-06-13 21:04:32 +08:00
Requires<[HasFullFP16,UseFusedMAC]>,
Sched<[WriteFPMAC32, ReadFPMAC, ReadFPMUL, ReadFPMUL]>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
def : Pat<(fsub_mlx (fneg (fmul_su DPR:$a, (f64 DPR:$b))), DPR:$dstin),
(VFNMAD DPR:$dstin, DPR:$a, DPR:$b)>,
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
Requires<[HasVFP4,HasDPVFP,UseFusedMAC]>;
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
def : Pat<(fsub_mlx (fneg (fmul_su SPR:$a, SPR:$b)), SPR:$dstin),
(VFNMAS SPR:$dstin, SPR:$a, SPR:$b)>,
Clean up ARM fused multiply + add/sub support some more: rename some isel predicates. Also remove NEON2 since it's not really useful and it is confusing. If NEON + VFP4 implies NEON2 but NEON2 doesn't imply NEON + VFP4, what does it really mean? rdar://10139676 llvm-svn: 154480
2012-04-11 13:33:07 +08:00
Requires<[HasVFP4,DontUseNEONForFP,UseFusedMAC]>;
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
Match (fneg (fma) to vfnma. rdar://10139676 llvm-svn: 154469
2012-04-11 09:21:25 +08:00
// Match @llvm.fma.* intrinsics
Fix the order of the operands in the llvm.fma intrinsic patterns for ARM, <rdar://problem/11325085>. llvm-svn: 155724
2012-04-28 02:51:24 +08:00
// (fneg (fma x, y, z)) -> (vfnma z, x, y)
def : Pat<(fneg (fma (f64 DPR:$Dn), (f64 DPR:$Dm), (f64 DPR:$Ddin))),
Match (fneg (fma) to vfnma. rdar://10139676 llvm-svn: 154469
2012-04-11 09:21:25 +08:00
(VFNMAD DPR:$Ddin, DPR:$Dn, DPR:$Dm)>,
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
Requires<[HasVFP4,HasDPVFP]>;
Fix the order of the operands in the llvm.fma intrinsic patterns for ARM, <rdar://problem/11325085>. llvm-svn: 155724
2012-04-28 02:51:24 +08:00
def : Pat<(fneg (fma (f32 SPR:$Sn), (f32 SPR:$Sm), (f32 SPR:$Sdin))),
Match (fneg (fma) to vfnma. rdar://10139676 llvm-svn: 154469
2012-04-11 09:21:25 +08:00
(VFNMAS SPR:$Sdin, SPR:$Sn, SPR:$Sm)>,
Requires<[HasVFP4]>;
Fix the order of the operands in the llvm.fma intrinsic patterns for ARM, <rdar://problem/11325085>. llvm-svn: 155724
2012-04-28 02:51:24 +08:00
// (fma (fneg x), y, (fneg z)) -> (vfnma z, x, y)
def : Pat<(f64 (fma (fneg DPR:$Dn), DPR:$Dm, (fneg DPR:$Ddin))),
Add more fused mul+add/sub patterns. rdar://10139676 llvm-svn: 154484
2012-04-11 14:59:47 +08:00
(VFNMAD DPR:$Ddin, DPR:$Dn, DPR:$Dm)>,
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
Requires<[HasVFP4,HasDPVFP]>;
Fix the order of the operands in the llvm.fma intrinsic patterns for ARM, <rdar://problem/11325085>. llvm-svn: 155724
2012-04-28 02:51:24 +08:00
def : Pat<(f32 (fma (fneg SPR:$Sn), SPR:$Sm, (fneg SPR:$Sdin))),
Add more fused mul+add/sub patterns. rdar://10139676 llvm-svn: 154484
2012-04-11 14:59:47 +08:00
(VFNMAS SPR:$Sdin, SPR:$Sn, SPR:$Sm)>,
Requires<[HasVFP4]>;
Match (fneg (fma) to vfnma. rdar://10139676 llvm-svn: 154469
2012-04-11 09:21:25 +08:00
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
def VFNMSD : ADbI<0b11101, 0b01, 0, 0,
(outs DPR:$Dd), (ins DPR:$Ddin, DPR:$Dn, DPR:$Dm),
IIC_fpFMAC64, "vfnms", ".f64\t$Dd, $Dn, $Dm",
[(set DPR:$Dd, (fsub_mlx (fmul_su DPR:$Dn, DPR:$Dm),
(f64 DPR:$Ddin)))]>,
RegConstraint<"$Ddin = $Dd">,
[ARM] Add scheduling classes for VFNM[AS] The VFNM[AS] instructions did not have scheduling information attached, which was causing assertion failures with the Cortex-A57 scheduling model and -fp-contract=fast, because the Cortex-A57 sched model claims to be complete. Differential Revision: https://reviews.llvm.org/D34139 llvm-svn: 305288
2017-06-13 21:04:32 +08:00
Requires<[HasVFP4,HasDPVFP,UseFusedMAC]>,
Sched<[WriteFPMAC64, ReadFPMAC, ReadFPMUL, ReadFPMUL]>;
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
def VFNMSS : ASbI<0b11101, 0b01, 0, 0,
(outs SPR:$Sd), (ins SPR:$Sdin, SPR:$Sn, SPR:$Sm),
IIC_fpFMAC32, "vfnms", ".f32\t$Sd, $Sn, $Sm",
[(set SPR:$Sd, (fsub_mlx (fmul_su SPR:$Sn, SPR:$Sm), SPR:$Sdin))]>,
RegConstraint<"$Sdin = $Sd">,
[ARM] Add scheduling classes for VFNM[AS] The VFNM[AS] instructions did not have scheduling information attached, which was causing assertion failures with the Cortex-A57 scheduling model and -fp-contract=fast, because the Cortex-A57 sched model claims to be complete. Differential Revision: https://reviews.llvm.org/D34139 llvm-svn: 305288
2017-06-13 21:04:32 +08:00
Requires<[HasVFP4,DontUseNEONForFP,UseFusedMAC]>,
Sched<[WriteFPMAC32, ReadFPMAC, ReadFPMUL, ReadFPMUL]> {
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
// Some single precision VFP instructions may be executed on both NEON and
// VFP pipelines.
}
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
def VFNMSH : AHbI<0b11101, 0b01, 0, 0,
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
(outs HPR:$Sd), (ins HPR:$Sdin, HPR:$Sn, HPR:$Sm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
IIC_fpFMAC16, "vfnms", ".f16\t$Sd, $Sn, $Sm",
[ARM] Armv8.2-A FP16 code generation (part 3/3) This adds most of the FP16 codegen support, but these areas need further work: - FP16 literals and immediates are not properly supported yet (e.g. literal pool needs work), - Instructions that are generated from intrinsics (e.g. vabs) haven't been added. This will be addressed in follow-up patches. Differential Revision: https://reviews.llvm.org/D42849 llvm-svn: 324321
2018-02-06 16:43:56 +08:00
[(set HPR:$Sd, (fsub_mlx (fmul_su HPR:$Sn, HPR:$Sm), HPR:$Sdin))]>,
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
RegConstraint<"$Sdin = $Sd">,
[ARM] Add scheduling classes for VFNM[AS] The VFNM[AS] instructions did not have scheduling information attached, which was causing assertion failures with the Cortex-A57 scheduling model and -fp-contract=fast, because the Cortex-A57 sched model claims to be complete. Differential Revision: https://reviews.llvm.org/D34139 llvm-svn: 305288
2017-06-13 21:04:32 +08:00
Requires<[HasFullFP16,UseFusedMAC]>,
Sched<[WriteFPMAC32, ReadFPMAC, ReadFPMUL, ReadFPMUL]>;
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
def : Pat<(fsub_mlx (fmul_su DPR:$a, (f64 DPR:$b)), DPR:$dstin),
(VFNMSD DPR:$dstin, DPR:$a, DPR:$b)>,
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
Requires<[HasVFP4,HasDPVFP,UseFusedMAC]>;
Add fused multiple+add instructions from VFPv4. Patch by Ana Pazos! llvm-svn: 148658
2012-01-22 20:07:33 +08:00
def : Pat<(fsub_mlx (fmul_su SPR:$a, SPR:$b), SPR:$dstin),
(VFNMSS SPR:$dstin, SPR:$a, SPR:$b)>,
Clean up ARM fused multiply + add/sub support some more: rename some isel predicates. Also remove NEON2 since it's not really useful and it is confusing. If NEON + VFP4 implies NEON2 but NEON2 doesn't imply NEON + VFP4, what does it really mean? rdar://10139676 llvm-svn: 154480
2012-04-11 13:33:07 +08:00
Requires<[HasVFP4,DontUseNEONForFP,UseFusedMAC]>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
Add more fused mul+add/sub patterns. rdar://10139676 llvm-svn: 154484
2012-04-11 14:59:47 +08:00
// Match @llvm.fma.* intrinsics
Add a missing llvm.fma -> VFNMS pattern to the ARM backend. llvm-svn: 158902
2012-06-21 14:10:00 +08:00
// (fma x, y, (fneg z)) -> (vfnms z, x, y))
def : Pat<(f64 (fma DPR:$Dn, DPR:$Dm, (fneg DPR:$Ddin))),
(VFNMSD DPR:$Ddin, DPR:$Dn, DPR:$Dm)>,
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
Requires<[HasVFP4,HasDPVFP]>;
Add a missing llvm.fma -> VFNMS pattern to the ARM backend. llvm-svn: 158902
2012-06-21 14:10:00 +08:00
def : Pat<(f32 (fma SPR:$Sn, SPR:$Sm, (fneg SPR:$Sdin))),
(VFNMSS SPR:$Sdin, SPR:$Sn, SPR:$Sm)>,
Requires<[HasVFP4]>;
Fix the order of the operands in the llvm.fma intrinsic patterns for ARM, <rdar://problem/11325085>. llvm-svn: 155724
2012-04-28 02:51:24 +08:00
// (fneg (fma (fneg x), y, z)) -> (vfnms z, x, y)
def : Pat<(fneg (f64 (fma (fneg DPR:$Dn), DPR:$Dm, DPR:$Ddin))),
Add more fused mul+add/sub patterns. rdar://10139676 llvm-svn: 154484
2012-04-11 14:59:47 +08:00
(VFNMSD DPR:$Ddin, DPR:$Dn, DPR:$Dm)>,
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
Requires<[HasVFP4,HasDPVFP]>;
Fix the order of the operands in the llvm.fma intrinsic patterns for ARM, <rdar://problem/11325085>. llvm-svn: 155724
2012-04-28 02:51:24 +08:00
def : Pat<(fneg (f32 (fma (fneg SPR:$Sn), SPR:$Sm, SPR:$Sdin))),
Add more fused mul+add/sub patterns. rdar://10139676 llvm-svn: 154484
2012-04-11 14:59:47 +08:00
(VFNMSS SPR:$Sdin, SPR:$Sn, SPR:$Sm)>,
Requires<[HasVFP4]>;
Fix the order of the operands in the llvm.fma intrinsic patterns for ARM, <rdar://problem/11325085>. llvm-svn: 155724
2012-04-28 02:51:24 +08:00
// (fneg (fma x, (fneg y), z) -> (vfnms z, x, y)
def : Pat<(fneg (f64 (fma DPR:$Dn, (fneg DPR:$Dm), DPR:$Ddin))),
Add more fused mul+add/sub patterns. rdar://10139676 llvm-svn: 154484
2012-04-11 14:59:47 +08:00
(VFNMSD DPR:$Ddin, DPR:$Dn, DPR:$Dm)>,
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
Requires<[HasVFP4,HasDPVFP]>;
Fix the order of the operands in the llvm.fma intrinsic patterns for ARM, <rdar://problem/11325085>. llvm-svn: 155724
2012-04-28 02:51:24 +08:00
def : Pat<(fneg (f32 (fma SPR:$Sn, (fneg SPR:$Sm), SPR:$Sdin))),
Add more fused mul+add/sub patterns. rdar://10139676 llvm-svn: 154484
2012-04-11 14:59:47 +08:00
(VFNMSS SPR:$Sdin, SPR:$Sn, SPR:$Sm)>,
Requires<[HasVFP4]>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
//===----------------------------------------------------------------------===//
// FP Conditional moves.
//
Replace neverHasSideEffects=1 with hasSideEffects=0 in all .td files. llvm-svn: 222801
2014-11-26 08:46:26 +08:00
let hasSideEffects = 0 in {
ARM: use TableGen patterns to select CMOV operations. Back in the mists of time (2008), it seems TableGen couldn't handle the patterns necessary to match ARM's CMOV node that we convert select operations to, so we wrote a lot of fairly hairy C++ to do it for us. TableGen can deal with it now: there were a few minor differences to CodeGen (see tests), but nothing obviously worse that I could see, so we should probably address anything that *does* come up in a localised manner. llvm-svn: 188995
2013-08-22 17:57:11 +08:00
def VMOVDcc : PseudoInst<(outs DPR:$Dd), (ins DPR:$Dn, DPR:$Dm, cmovpred:$p),
IIC_fpUNA64,
[(set (f64 DPR:$Dd),
(ARMcmov DPR:$Dn, DPR:$Dm, cmovpred:$p))]>,
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
RegConstraint<"$Dn = $Dd">, Requires<[HasVFP2,HasDPVFP]>;
ARM: use TableGen patterns to select CMOV operations. Back in the mists of time (2008), it seems TableGen couldn't handle the patterns necessary to match ARM's CMOV node that we convert select operations to, so we wrote a lot of fairly hairy C++ to do it for us. TableGen can deal with it now: there were a few minor differences to CodeGen (see tests), but nothing obviously worse that I could see, so we should probably address anything that *does* come up in a localised manner. llvm-svn: 188995
2013-08-22 17:57:11 +08:00
def VMOVScc : PseudoInst<(outs SPR:$Sd), (ins SPR:$Sn, SPR:$Sm, cmovpred:$p),
IIC_fpUNA32,
[(set (f32 SPR:$Sd),
(ARMcmov SPR:$Sn, SPR:$Sm, cmovpred:$p))]>,
RegConstraint<"$Sn = $Sd">, Requires<[HasVFP2]>;
Replace neverHasSideEffects=1 with hasSideEffects=0 in all .td files. llvm-svn: 222801
2014-11-26 08:46:26 +08:00
} // hasSideEffects
Encode VFP conversion instructions. llvm-svn: 59074
2008-11-12 03:40:26 +08:00
//===----------------------------------------------------------------------===//
Create two new generic classes to represent the following VMRS/VMSR variations: vmrs reg, fpexc vmrs reg, fpsid vmsr fpexc, reg vmsr fpsid, reg llvm-svn: 123783
2011-01-19 05:58:20 +08:00
// Move from VFP System Register to ARM core register.
Encode VFP conversion instructions. llvm-svn: 59074
2008-11-12 03:40:26 +08:00
//
Create two new generic classes to represent the following VMRS/VMSR variations: vmrs reg, fpexc vmrs reg, fpsid vmsr fpexc, reg vmsr fpsid, reg llvm-svn: 123783
2011-01-19 05:58:20 +08:00
class MovFromVFP<bits<4> opc19_16, dag oops, dag iops, string opc, string asm,
list<dag> pattern>:
VFPAI<oops, iops, VFPMiscFrm, IIC_fpSTAT, opc, asm, pattern> {
Use fconsts and fconstd to materialize small fp constants. llvm-svn: 85362
2009-10-28 09:44:26 +08:00
- Add encodings for multiply add/subtract instructions in all their glory. - Add missing patterns for some multiply add/subtract instructions. - Add encodings for VMRS and VMSR. llvm-svn: 116464
2010-10-14 09:02:08 +08:00
// Instruction operand.
bits<4> Rt;
Added VMRS/VMSR for disassembly only. A8.6.335 & A8.6.336 llvm-svn: 95703
2010-02-10 06:35:38 +08:00
let Inst{27-20} = 0b11101111;
Create two new generic classes to represent the following VMRS/VMSR variations: vmrs reg, fpexc vmrs reg, fpsid vmsr fpexc, reg vmsr fpsid, reg llvm-svn: 123783
2011-01-19 05:58:20 +08:00
let Inst{19-16} = opc19_16;
let Inst{15-12} = Rt;
Added VMRS/VMSR for disassembly only. A8.6.335 & A8.6.336 llvm-svn: 95703
2010-02-10 06:35:38 +08:00
let Inst{11-8} = 0b1010;
let Inst{7} = 0;
- Add encodings for multiply add/subtract instructions in all their glory. - Add missing patterns for some multiply add/subtract instructions. - Add encodings for VMRS and VMSR. llvm-svn: 116464
2010-10-14 09:02:08 +08:00
let Inst{6-5} = 0b00;
Added VMRS/VMSR for disassembly only. A8.6.335 & A8.6.336 llvm-svn: 95703
2010-02-10 06:35:38 +08:00
let Inst{4} = 1;
- Add encodings for multiply add/subtract instructions in all their glory. - Add missing patterns for some multiply add/subtract instructions. - Add encodings for VMRS and VMSR. llvm-svn: 116464
2010-10-14 09:02:08 +08:00
let Inst{3-0} = 0b0000;
Added VMRS/VMSR for disassembly only. A8.6.335 & A8.6.336 llvm-svn: 95703
2010-02-10 06:35:38 +08:00
}
Create two new generic classes to represent the following VMRS/VMSR variations: vmrs reg, fpexc vmrs reg, fpsid vmsr fpexc, reg vmsr fpsid, reg llvm-svn: 123783
2011-01-19 05:58:20 +08:00
// APSR is the application level alias of CPSR. This FPSCR N, Z, C, V flags
// to APSR.
Split fpscr into two registers: FPSCR and FPSCR_NZCV. The fpscr register contains both flags (set by FP operations/comparisons) and control bits. The control bits (FPSCR) should be reserved, since they're always available and needn't be defined before use. The flag bits (FPSCR_NZCV) should like to be unreserved so they can be hoisted by MachineCSE. This fixes PR12165. llvm-svn: 152076
2012-03-06 08:19:55 +08:00
let Defs = [CPSR], Uses = [FPSCR_NZCV], Rt = 0b1111 /* apsr_nzcv */ in
Create two new generic classes to represent the following VMRS/VMSR variations: vmrs reg, fpexc vmrs reg, fpsid vmsr fpexc, reg vmsr fpsid, reg llvm-svn: 123783
2011-01-19 05:58:20 +08:00
def FMSTAT : MovFromVFP<0b0001 /* fpscr */, (outs), (ins),
ARM case-insensitive checking for APSR_nzcv. rdar://11056591 llvm-svn: 152846
2012-03-16 05:34:14 +08:00
"vmrs", "\tAPSR_nzcv, fpscr", [(arm_fmstat)]>;
Create two new generic classes to represent the following VMRS/VMSR variations: vmrs reg, fpexc vmrs reg, fpsid vmsr fpexc, reg vmsr fpsid, reg llvm-svn: 123783
2011-01-19 05:58:20 +08:00
[ARM] Fix assembly and disassembly for VMRS/VMSR Reviewed by: t.p.northover Differential Revision: https://reviews.llvm.org/D36306 llvm-svn: 313979
2017-09-22 20:17:42 +08:00
let DecoderMethod = "DecodeForVMRSandVMSR" in {
// Application level FPSCR -> GPR
let hasSideEffects = 1, Uses = [FPSCR] in
def VMRS : MovFromVFP<0b0001 /* fpscr */, (outs GPRnopc:$Rt), (ins),
"vmrs", "\t$Rt, fpscr",
[(set GPRnopc:$Rt, (int_arm_get_fpscr))]>;
// System level FPEXC, FPSID -> GPR
let Uses = [FPSCR] in {
def VMRS_FPEXC : MovFromVFP<0b1000 /* fpexc */, (outs GPRnopc:$Rt), (ins),
"vmrs", "\t$Rt, fpexc", []>;
def VMRS_FPSID : MovFromVFP<0b0000 /* fpsid */, (outs GPRnopc:$Rt), (ins),
"vmrs", "\t$Rt, fpsid", []>;
def VMRS_MVFR0 : MovFromVFP<0b0111 /* mvfr0 */, (outs GPRnopc:$Rt), (ins),
Revert "[ARM] Fix assembly and disassembly for VMRS/VMSR" This reverts r310243. Only MVFR2 is actually restricted to v8 and it'll be a little while before we can get a proper fix together. Better that we allow incorrect code than reject correct in the meantime. llvm-svn: 310384
2017-08-09 01:16:46 +08:00
"vmrs", "\t$Rt, mvfr0", []>;
[ARM] Fix assembly and disassembly for VMRS/VMSR Reviewed by: t.p.northover Differential Revision: https://reviews.llvm.org/D36306 llvm-svn: 313979
2017-09-22 20:17:42 +08:00
def VMRS_MVFR1 : MovFromVFP<0b0110 /* mvfr1 */, (outs GPRnopc:$Rt), (ins),
"vmrs", "\t$Rt, mvfr1", []>;
let Predicates = [HasFPARMv8] in {
def VMRS_MVFR2 : MovFromVFP<0b0101 /* mvfr2 */, (outs GPRnopc:$Rt), (ins),
"vmrs", "\t$Rt, mvfr2", []>;
}
def VMRS_FPINST : MovFromVFP<0b1001 /* fpinst */, (outs GPRnopc:$Rt), (ins),
"vmrs", "\t$Rt, fpinst", []>;
def VMRS_FPINST2 : MovFromVFP<0b1010 /* fpinst2 */, (outs GPRnopc:$Rt),
(ins), "vmrs", "\t$Rt, fpinst2", []>;
}
Create two new generic classes to represent the following VMRS/VMSR variations: vmrs reg, fpexc vmrs reg, fpsid vmsr fpexc, reg vmsr fpsid, reg llvm-svn: 123783
2011-01-19 05:58:20 +08:00
}
//===----------------------------------------------------------------------===//
// Move from ARM core register to VFP System Register.
//
class MovToVFP<bits<4> opc19_16, dag oops, dag iops, string opc, string asm,
list<dag> pattern>:
VFPAI<oops, iops, VFPMiscFrm, IIC_fpSTAT, opc, asm, pattern> {
- Add encodings for multiply add/subtract instructions in all their glory. - Add missing patterns for some multiply add/subtract instructions. - Add encodings for VMRS and VMSR. llvm-svn: 116464
2010-10-14 09:02:08 +08:00
// Instruction operand.
bits<4> src;
// Encode instruction operand.
let Inst{15-12} = src;
Added VMRS/VMSR for disassembly only. A8.6.335 & A8.6.336 llvm-svn: 95703
2010-02-10 06:35:38 +08:00
let Inst{27-20} = 0b11101110;
Create two new generic classes to represent the following VMRS/VMSR variations: vmrs reg, fpexc vmrs reg, fpsid vmsr fpexc, reg vmsr fpsid, reg llvm-svn: 123783
2011-01-19 05:58:20 +08:00
let Inst{19-16} = opc19_16;
Added VMRS/VMSR for disassembly only. A8.6.335 & A8.6.336 llvm-svn: 95703
2010-02-10 06:35:38 +08:00
let Inst{11-8} = 0b1010;
let Inst{7} = 0;
let Inst{4} = 1;
}
Use fconsts and fconstd to materialize small fp constants. llvm-svn: 85362
2009-10-28 09:44:26 +08:00
[ARM] Fix assembly and disassembly for VMRS/VMSR Reviewed by: t.p.northover Differential Revision: https://reviews.llvm.org/D36306 llvm-svn: 313979
2017-09-22 20:17:42 +08:00
let DecoderMethod = "DecodeForVMRSandVMSR" in {
let Defs = [FPSCR] in {
// Application level GPR -> FPSCR
def VMSR : MovToVFP<0b0001 /* fpscr */, (outs), (ins GPRnopc:$src),
"vmsr", "\tfpscr, $src",
[(int_arm_set_fpscr GPRnopc:$src)]>;
// System level GPR -> FPEXC
def VMSR_FPEXC : MovToVFP<0b1000 /* fpexc */, (outs), (ins GPRnopc:$src),
"vmsr", "\tfpexc, $src", []>;
// System level GPR -> FPSID
def VMSR_FPSID : MovToVFP<0b0000 /* fpsid */, (outs), (ins GPRnopc:$src),
"vmsr", "\tfpsid, $src", []>;
def VMSR_FPINST : MovToVFP<0b1001 /* fpinst */, (outs), (ins GPRnopc:$src),
This patch adds support for FPINST/FPINST2 as operands to vmsr/vmrs. These are optional registers that may be supported some ARM implementations to aid with resolution of floating point exceptions. The manual pages for vmsr and vmrs do not detail their use. Encodings and other information can be found in ARM Architecture Reference Manual section F, chapter 6, paragraph 3. llvm-svn: 183733
2013-06-11 17:39:51 +08:00
"vmsr", "\tfpinst, $src", []>;
[ARM] Fix assembly and disassembly for VMRS/VMSR Reviewed by: t.p.northover Differential Revision: https://reviews.llvm.org/D36306 llvm-svn: 313979
2017-09-22 20:17:42 +08:00
def VMSR_FPINST2 : MovToVFP<0b1010 /* fpinst2 */, (outs), (ins GPRnopc:$src),
"vmsr", "\tfpinst2, $src", []>;
}
Create two new generic classes to represent the following VMRS/VMSR variations: vmrs reg, fpexc vmrs reg, fpsid vmsr fpexc, reg vmsr fpsid, reg llvm-svn: 123783
2011-01-19 05:58:20 +08:00
}
//===----------------------------------------------------------------------===//
// Misc.
//
Use fconsts and fconstd to materialize small fp constants. llvm-svn: 85362
2009-10-28 09:44:26 +08:00
// Materialize FP immediates. VFP3 only.
Use Unified Assembly Syntax for the ARM backend. llvm-svn: 86494
2009-11-09 08:11:35 +08:00
let isReMaterializable = 1 in {
Add support for vmov.f64/.f32 encoding. There's a bit of a hack going on here. The f32 in FCONSTS is handled as a double instead of a float in the code. So the encoding of the immediate into the instruction isn't exactly in line with the documentation in that regard. But given that we know it's handled as a double, it doesn't cause any harm. llvm-svn: 116471
2010-10-14 10:33:26 +08:00
def FCONSTD : VFPAI<(outs DPR:$Dd), (ins vfp_f64imm:$imm),
FCONST{S,D} behaves the same way as FP unary instructions. This is true for both A8 and A9. llvm-svn: 100649
2010-04-08 02:19:56 +08:00
VFPMiscFrm, IIC_fpUNA64,
Add support for vmov.f64/.f32 encoding. There's a bit of a hack going on here. The f32 in FCONSTS is handled as a double instead of a float in the code. So the encoding of the immediate into the instruction isn't exactly in line with the documentation in that regard. But given that we know it's handled as a double, it doesn't cause any harm. llvm-svn: 116471
2010-10-14 10:33:26 +08:00
"vmov", ".f64\t$Dd, $imm",
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
[(set DPR:$Dd, vfp_f64imm:$imm)]>,
Requires<[HasVFP3,HasDPVFP]> {
ARM fix encoding of VMOV.f32 and VMOV.f64 immediates. Encode the immediate into its 8-bit form as part of isel rather than later, which simplifies things for mapping the encoding bits, allows the removal of the custom disassembler decoding hook, makes the operand printer trivial, and prepares things more cleanly for handling these in the asm parser. rdar://10211428 llvm-svn: 140834
2011-09-30 08:50:06 +08:00
bits<5> Dd;
bits<8> imm;
Add support for vmov.f64/.f32 encoding. There's a bit of a hack going on here. The f32 in FCONSTS is handled as a double instead of a float in the code. So the encoding of the immediate into the instruction isn't exactly in line with the documentation in that regard. But given that we know it's handled as a double, it doesn't cause any harm. llvm-svn: 116471
2010-10-14 10:33:26 +08:00
Use fconsts and fconstd to materialize small fp constants. llvm-svn: 85362
2009-10-28 09:44:26 +08:00
let Inst{27-23} = 0b11101;
ARM fix encoding of VMOV.f32 and VMOV.f64 immediates. Encode the immediate into its 8-bit form as part of isel rather than later, which simplifies things for mapping the encoding bits, allows the removal of the custom disassembler decoding hook, makes the operand printer trivial, and prepares things more cleanly for handling these in the asm parser. rdar://10211428 llvm-svn: 140834
2011-09-30 08:50:06 +08:00
let Inst{22} = Dd{4};
Use fconsts and fconstd to materialize small fp constants. llvm-svn: 85362
2009-10-28 09:44:26 +08:00
let Inst{21-20} = 0b11;
ARM fix encoding of VMOV.f32 and VMOV.f64 immediates. Encode the immediate into its 8-bit form as part of isel rather than later, which simplifies things for mapping the encoding bits, allows the removal of the custom disassembler decoding hook, makes the operand printer trivial, and prepares things more cleanly for handling these in the asm parser. rdar://10211428 llvm-svn: 140834
2011-09-30 08:50:06 +08:00
let Inst{19-16} = imm{7-4};
let Inst{15-12} = Dd{3-0};
Use fconsts and fconstd to materialize small fp constants. llvm-svn: 85362
2009-10-28 09:44:26 +08:00
let Inst{11-9} = 0b101;
Add support for vmov.f64/.f32 encoding. There's a bit of a hack going on here. The f32 in FCONSTS is handled as a double instead of a float in the code. So the encoding of the immediate into the instruction isn't exactly in line with the documentation in that regard. But given that we know it's handled as a double, it doesn't cause any harm. llvm-svn: 116471
2010-10-14 10:33:26 +08:00
let Inst{8} = 1; // Double precision.
Use fconsts and fconstd to materialize small fp constants. llvm-svn: 85362
2009-10-28 09:44:26 +08:00
let Inst{7-4} = 0b0000;
ARM fix encoding of VMOV.f32 and VMOV.f64 immediates. Encode the immediate into its 8-bit form as part of isel rather than later, which simplifies things for mapping the encoding bits, allows the removal of the custom disassembler decoding hook, makes the operand printer trivial, and prepares things more cleanly for handling these in the asm parser. rdar://10211428 llvm-svn: 140834
2011-09-30 08:50:06 +08:00
let Inst{3-0} = imm{3-0};
Use fconsts and fconstd to materialize small fp constants. llvm-svn: 85362
2009-10-28 09:44:26 +08:00
}
Add support for vmov.f64/.f32 encoding. There's a bit of a hack going on here. The f32 in FCONSTS is handled as a double instead of a float in the code. So the encoding of the immediate into the instruction isn't exactly in line with the documentation in that regard. But given that we know it's handled as a double, it doesn't cause any harm. llvm-svn: 116471
2010-10-14 10:33:26 +08:00
def FCONSTS : VFPAI<(outs SPR:$Sd), (ins vfp_f32imm:$imm),
VFPMiscFrm, IIC_fpUNA32,
"vmov", ".f32\t$Sd, $imm",
[(set SPR:$Sd, vfp_f32imm:$imm)]>, Requires<[HasVFP3]> {
ARM fix encoding of VMOV.f32 and VMOV.f64 immediates. Encode the immediate into its 8-bit form as part of isel rather than later, which simplifies things for mapping the encoding bits, allows the removal of the custom disassembler decoding hook, makes the operand printer trivial, and prepares things more cleanly for handling these in the asm parser. rdar://10211428 llvm-svn: 140834
2011-09-30 08:50:06 +08:00
bits<5> Sd;
bits<8> imm;
Add support for vmov.f64/.f32 encoding. There's a bit of a hack going on here. The f32 in FCONSTS is handled as a double instead of a float in the code. So the encoding of the immediate into the instruction isn't exactly in line with the documentation in that regard. But given that we know it's handled as a double, it doesn't cause any harm. llvm-svn: 116471
2010-10-14 10:33:26 +08:00
Use fconsts and fconstd to materialize small fp constants. llvm-svn: 85362
2009-10-28 09:44:26 +08:00
let Inst{27-23} = 0b11101;
ARM fix encoding of VMOV.f32 and VMOV.f64 immediates. Encode the immediate into its 8-bit form as part of isel rather than later, which simplifies things for mapping the encoding bits, allows the removal of the custom disassembler decoding hook, makes the operand printer trivial, and prepares things more cleanly for handling these in the asm parser. rdar://10211428 llvm-svn: 140834
2011-09-30 08:50:06 +08:00
let Inst{22} = Sd{0};
Use fconsts and fconstd to materialize small fp constants. llvm-svn: 85362
2009-10-28 09:44:26 +08:00
let Inst{21-20} = 0b11;
ARM fix encoding of VMOV.f32 and VMOV.f64 immediates. Encode the immediate into its 8-bit form as part of isel rather than later, which simplifies things for mapping the encoding bits, allows the removal of the custom disassembler decoding hook, makes the operand printer trivial, and prepares things more cleanly for handling these in the asm parser. rdar://10211428 llvm-svn: 140834
2011-09-30 08:50:06 +08:00
let Inst{19-16} = imm{7-4};
let Inst{15-12} = Sd{4-1};
Use fconsts and fconstd to materialize small fp constants. llvm-svn: 85362
2009-10-28 09:44:26 +08:00
let Inst{11-9} = 0b101;
Add support for vmov.f64/.f32 encoding. There's a bit of a hack going on here. The f32 in FCONSTS is handled as a double instead of a float in the code. So the encoding of the immediate into the instruction isn't exactly in line with the documentation in that regard. But given that we know it's handled as a double, it doesn't cause any harm. llvm-svn: 116471
2010-10-14 10:33:26 +08:00
let Inst{8} = 0; // Single precision.
Use fconsts and fconstd to materialize small fp constants. llvm-svn: 85362
2009-10-28 09:44:26 +08:00
let Inst{7-4} = 0b0000;
ARM fix encoding of VMOV.f32 and VMOV.f64 immediates. Encode the immediate into its 8-bit form as part of isel rather than later, which simplifies things for mapping the encoding bits, allows the removal of the custom disassembler decoding hook, makes the operand printer trivial, and prepares things more cleanly for handling these in the asm parser. rdar://10211428 llvm-svn: 140834
2011-09-30 08:50:06 +08:00
let Inst{3-0} = imm{3-0};
Use fconsts and fconstd to materialize small fp constants. llvm-svn: 85362
2009-10-28 09:44:26 +08:00
}
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
[ARM] FP16 mov imm pattern This is a follow up of r324321, adding a match pattern for mov with a FP16 immediate (also fixing operand vfp_f16imm that wasn't even compiling). Differential Revision: https://reviews.llvm.org/D42973 llvm-svn: 324456
2018-02-07 16:37:17 +08:00
def FCONSTH : VFPAI<(outs HPR:$Sd), (ins vfp_f16imm:$imm),
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
VFPMiscFrm, IIC_fpUNA16,
"vmov", ".f16\t$Sd, $imm",
[ARM] FP16 mov imm pattern This is a follow up of r324321, adding a match pattern for mov with a FP16 immediate (also fixing operand vfp_f16imm that wasn't even compiling). Differential Revision: https://reviews.llvm.org/D42973 llvm-svn: 324456
2018-02-07 16:37:17 +08:00
[(set HPR:$Sd, vfp_f16imm:$imm)]>,
Requires<[HasFullFP16]> {
[ARM] Add ARMv8.2-A FP16 scalar instructions This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
2016-01-25 18:26:26 +08:00
bits<5> Sd;
bits<8> imm;
let Inst{27-23} = 0b11101;
let Inst{22} = Sd{0};
let Inst{21-20} = 0b11;
let Inst{19-16} = imm{7-4};
let Inst{15-12} = Sd{4-1};
let Inst{11-8} = 0b1001; // Half precision
let Inst{7-4} = 0b0000;
let Inst{3-0} = imm{3-0};
}
Use Unified Assembly Syntax for the ARM backend. llvm-svn: 86494
2009-11-09 08:11:35 +08:00
}
ARM assembly parsing and encoding for VMRS/FMSTAT. llvm-svn: 141025
2011-10-04 05:12:43 +08:00
//===----------------------------------------------------------------------===//
// Assembler aliases.
//
ARM: fix a few typos in comments llvm-svn: 198171
2013-12-30 01:58:31 +08:00
// A few mnemonic aliases for pre-unifixed syntax. We don't guarantee to
ARM VFP support 'flds/fldd' aliases for 'vldr' llvm-svn: 146115
2011-12-08 08:49:29 +08:00
// support them all, but supporting at least some of the basics is
// good to be friendly.
ARM add some pre-UAL VFP mnemonics for convenience when porting old code. llvm-svn: 146296
2011-12-10 07:34:09 +08:00
def : VFP2MnemonicAlias<"flds", "vldr">;
def : VFP2MnemonicAlias<"fldd", "vldr">;
def : VFP2MnemonicAlias<"fmrs", "vmov">;
def : VFP2MnemonicAlias<"fmsr", "vmov">;
def : VFP2MnemonicAlias<"fsqrts", "vsqrt">;
def : VFP2MnemonicAlias<"fsqrtd", "vsqrt">;
def : VFP2MnemonicAlias<"fadds", "vadd.f32">;
def : VFP2MnemonicAlias<"faddd", "vadd.f64">;
def : VFP2MnemonicAlias<"fmrdd", "vmov">;
def : VFP2MnemonicAlias<"fmrds", "vmov">;
def : VFP2MnemonicAlias<"fmrrd", "vmov">;
def : VFP2MnemonicAlias<"fmdrr", "vmov">;
ARM VFP pre-UAL mnemonic aliases for fmul[sd]. llvm-svn: 146892
2011-12-20 03:43:50 +08:00
def : VFP2MnemonicAlias<"fmuls", "vmul.f32">;
ARM add some pre-UAL VFP mnemonics for convenience when porting old code. llvm-svn: 146296
2011-12-10 07:34:09 +08:00
def : VFP2MnemonicAlias<"fmuld", "vmul.f64">;
def : VFP2MnemonicAlias<"fnegs", "vneg.f32">;
def : VFP2MnemonicAlias<"fnegd", "vneg.f64">;
ARM add some more pre-UAL VFP mnemonics for convenience when porting old code. llvm-svn: 146300
2011-12-10 08:01:02 +08:00
def : VFP2MnemonicAlias<"ftosizd", "vcvt.s32.f64">;
def : VFP2MnemonicAlias<"ftosid", "vcvtr.s32.f64">;
def : VFP2MnemonicAlias<"ftosizs", "vcvt.s32.f32">;
def : VFP2MnemonicAlias<"ftosis", "vcvtr.s32.f32">;
def : VFP2MnemonicAlias<"ftouizd", "vcvt.u32.f64">;
def : VFP2MnemonicAlias<"ftouid", "vcvtr.u32.f64">;
def : VFP2MnemonicAlias<"ftouizs", "vcvt.u32.f32">;
def : VFP2MnemonicAlias<"ftouis", "vcvtr.u32.f32">;
def : VFP2MnemonicAlias<"fsitod", "vcvt.f64.s32">;
def : VFP2MnemonicAlias<"fsitos", "vcvt.f32.s32">;
def : VFP2MnemonicAlias<"fuitod", "vcvt.f64.u32">;
def : VFP2MnemonicAlias<"fuitos", "vcvt.f32.u32">;
ARM add some more pre-UAL VFP mnemonics for convenience when porting old code. llvm-svn: 146508
2011-12-14 04:13:48 +08:00
def : VFP2MnemonicAlias<"fsts", "vstr">;
def : VFP2MnemonicAlias<"fstd", "vstr">;
ARM NEON two-operand aliases for VQDMULH. llvm-svn: 146514
2011-12-14 04:40:37 +08:00
def : VFP2MnemonicAlias<"fmacd", "vmla.f64">;
def : VFP2MnemonicAlias<"fmacs", "vmla.f32">;
ARM VFP pre-UAL mnemonic aliases for fcpy[sd] and fdiv[sd]. llvm-svn: 146887
2011-12-20 03:02:41 +08:00
def : VFP2MnemonicAlias<"fcpys", "vmov.f32">;
def : VFP2MnemonicAlias<"fcpyd", "vmov.f64">;
ARM pre-UAL aliases. fcmp[sd]. llvm-svn: 147158
2011-12-23 03:20:45 +08:00
def : VFP2MnemonicAlias<"fcmps", "vcmp.f32">;
def : VFP2MnemonicAlias<"fcmpd", "vcmp.f64">;
ARM VFP pre-UAL mnemonic aliases for fcpy[sd] and fdiv[sd]. llvm-svn: 146887
2011-12-20 03:02:41 +08:00
def : VFP2MnemonicAlias<"fdivs", "vdiv.f32">;
def : VFP2MnemonicAlias<"fdivd", "vdiv.f64">;
ARM divided syntax fmrx/fmxr mnemonics. llvm-svn: 152946
2012-03-17 05:06:13 +08:00
def : VFP2MnemonicAlias<"fmrx", "vmrs">;
def : VFP2MnemonicAlias<"fmxr", "vmsr">;
ARM VFP support 'flds/fldd' aliases for 'vldr' llvm-svn: 146115
2011-12-08 08:49:29 +08:00
ARM aliases for pre-unified syntax fcmpz[sd] mnemonics. rdar://11056647 llvm-svn: 152834
2012-03-16 04:48:18 +08:00
// Be friendly and accept the old form of zero-compare
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
def : VFP2DPInstAlias<"fcmpzd${p} $val", (VCMPZD DPR:$val, pred:$p)>;
ARM aliases for pre-unified syntax fcmpz[sd] mnemonics. rdar://11056647 llvm-svn: 152834
2012-03-16 04:48:18 +08:00
def : VFP2InstAlias<"fcmpzs${p} $val", (VCMPZS SPR:$val, pred:$p)>;
ARM assembly parsing and encoding for VMRS/FMSTAT. llvm-svn: 141025
2011-10-04 05:12:43 +08:00
def : VFP2InstAlias<"fmstat${p}", (FMSTAT pred:$p)>;
ARM add some more pre-UAL VFP mnemonics for convenience when porting old code. llvm-svn: 146300
2011-12-10 08:01:02 +08:00
def : VFP2InstAlias<"fadds${p} $Sd, $Sn, $Sm",
(VADDS SPR:$Sd, SPR:$Sn, SPR:$Sm, pred:$p)>;
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
def : VFP2DPInstAlias<"faddd${p} $Dd, $Dn, $Dm",
(VADDD DPR:$Dd, DPR:$Dn, DPR:$Dm, pred:$p)>;
ARM add some more pre-UAL VFP mnemonics for convenience when porting old code. llvm-svn: 146300
2011-12-10 08:01:02 +08:00
def : VFP2InstAlias<"fsubs${p} $Sd, $Sn, $Sm",
(VSUBS SPR:$Sd, SPR:$Sn, SPR:$Sm, pred:$p)>;
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
def : VFP2DPInstAlias<"fsubd${p} $Dd, $Dn, $Dm",
(VSUBD DPR:$Dd, DPR:$Dn, DPR:$Dm, pred:$p)>;
ARM assembly parsing and encoding for VMRS/FMSTAT. llvm-svn: 141025
2011-10-04 05:12:43 +08:00
ARM convenience aliases for VSQRT. llvm-svn: 146201
2011-12-09 06:51:25 +08:00
// No need for the size suffix on VSQRT. It's implied by the register classes.
def : VFP2InstAlias<"vsqrt${p} $Sd, $Sm", (VSQRTS SPR:$Sd, SPR:$Sm, pred:$p)>;
ARM: Mark double-precision instructions as such This prevents us from silently accepting invalid instructions on (for example) Cortex-M4 with just single-precision VFP support. No tests for the extra Pat Requires because they're essentially assertions: the affected code should have been lowered to libcalls before ISel. rdar://problem/15302004 llvm-svn: 193354
2013-10-24 23:49:39 +08:00
def : VFP2DPInstAlias<"vsqrt${p} $Dd, $Dm", (VSQRTD DPR:$Dd, DPR:$Dm, pred:$p)>;
ARM convenience aliases for VSQRT. llvm-svn: 146201
2011-12-09 06:51:25 +08:00
ARM VLDR/VSTR instructions don't need a size suffix. Canonicallize on the non-suffixed form, but continue to accept assembly that has any correctly sized type suffix. llvm-svn: 144583
2011-11-15 07:03:21 +08:00
// VLDR/VSTR accept an optional type suffix.
ARM tidy up and remove no longer needed InstAlias definitions. The TokenAlias handling of data type suffices renders these unnecessary. llvm-svn: 146010
2011-12-07 09:50:36 +08:00
def : VFP2InstAlias<"vldr${p}.32 $Sd, $addr",
(VLDRS SPR:$Sd, addrmode5:$addr, pred:$p)>;
def : VFP2InstAlias<"vstr${p}.32 $Sd, $addr",
(VSTRS SPR:$Sd, addrmode5:$addr, pred:$p)>;
def : VFP2InstAlias<"vldr${p}.64 $Dd, $addr",
(VLDRD DPR:$Dd, addrmode5:$addr, pred:$p)>;
def : VFP2InstAlias<"vstr${p}.64 $Dd, $addr",
(VSTRD DPR:$Dd, addrmode5:$addr, pred:$p)>;
ARM assembly parsing for two-operand form of 'mul' instruction. rdar://10449856. llvm-svn: 144689
2011-11-16 04:14:51 +08:00
ARM VFP optional data type on VMOV GPR<-->SPR. llvm-svn: 147104
2011-12-22 07:24:15 +08:00
// VMOV can accept optional 32-bit or less data type suffix suffix.
def : VFP2InstAlias<"vmov${p}.8 $Rt, $Sn",
ARM assembly parsing for optional datatype suffix on VFP VMOV GPR<->VFP insns. Yet more of rdar://10435076. llvm-svn: 144691
2011-11-16 04:29:42 +08:00
(VMOVRS GPR:$Rt, SPR:$Sn, pred:$p)>;
ARM VFP optional data type on VMOV GPR<-->SPR. llvm-svn: 147104
2011-12-22 07:24:15 +08:00
def : VFP2InstAlias<"vmov${p}.16 $Rt, $Sn",
(VMOVRS GPR:$Rt, SPR:$Sn, pred:$p)>;
def : VFP2InstAlias<"vmov${p}.32 $Rt, $Sn",
(VMOVRS GPR:$Rt, SPR:$Sn, pred:$p)>;
def : VFP2InstAlias<"vmov${p}.8 $Sn, $Rt",
(VMOVSR SPR:$Sn, GPR:$Rt, pred:$p)>;
def : VFP2InstAlias<"vmov${p}.16 $Sn, $Rt",
(VMOVSR SPR:$Sn, GPR:$Rt, pred:$p)>;
def : VFP2InstAlias<"vmov${p}.32 $Sn, $Rt",
ARM assembly parsing for optional datatype suffix on VFP VMOV GPR<->VFP insns. Yet more of rdar://10435076. llvm-svn: 144691
2011-11-16 04:29:42 +08:00
(VMOVSR SPR:$Sn, GPR:$Rt, pred:$p)>;
def : VFP2InstAlias<"vmov${p}.f64 $Rt, $Rt2, $Dn",
(VMOVRRD GPR:$Rt, GPR:$Rt2, DPR:$Dn, pred:$p)>;
def : VFP2InstAlias<"vmov${p}.f64 $Dn, $Rt, $Rt2",
(VMOVDRR DPR:$Dn, GPR:$Rt, GPR:$Rt2, pred:$p)>;
ARM size suffix on VFP single-precision 'vmov' is optional. rdar://10435114 llvm-svn: 144698
2011-11-16 05:18:35 +08:00
// VMOVS doesn't need the .f32 to disambiguate from the NEON encoding the way
// VMOVD does.
def : VFP2InstAlias<"vmov${p} $Sd, $Sm",
(VMOVS SPR:$Sd, SPR:$Sm, pred:$p)>;
Add ARM fconsts/fconstd aliases for vmov.f32/vmov.f64 This commit adds the pre-UAL aliases of fconsts and fconstd for vmov.f32 and vmov.f64. They use an InstAlias rather than a MnemonicAlias to properly support the predicate operand. We need to support encoded 8-bit constants in order to implement the pre-UAL fconsts/fconstd aliases for vmov.f32/vmov.f64, so this commit also fixes parsing of encoded floating point constants used in vmov.f32/vmov.f64 instructions. Now we can support assembly code like this: fconsts s0, #0x70 which is equivalent to vmov.f32 s0, #1.0. Most of the code was already in place to support this feature. Previously the code was trying to accept encoded 8-bit float constants for the vmov.f32/vmov.f64 instructions. It looks like the support for parsing encoded floats was lost in a refactoring in commit r148556 and we did not have any tests in place to catch it. The change in this commit is to keep the parsed value as a 32-bit float instead of a 64-bit double because that is what the isFPImm() function expects to find. There is no loss of precision by using a 32-bit float here because we are still limited to an 8-bit encoded value in the end. Additionally, we explicitly reject encoded 8-bit floats for vmovf.32/64. This is the same as the current behavior, but we now do it explicitly rather than accidently. llvm-svn: 198697
2014-01-08 02:19:23 +08:00
// FCONSTD/FCONSTS alias for vmov.f64/vmov.f32
// These aliases provide added functionality over vmov.f instructions by
// allowing users to write assembly containing encoded floating point constants
// (e.g. #0x70 vs #1.0). Without these alises there is no way for the
// assembler to accept encoded fp constants (but the equivalent fp-literal is
// accepted directly by vmovf).
def : VFP3InstAlias<"fconstd${p} $Dd, $val",
(FCONSTD DPR:$Dd, vfp_f64imm:$val, pred:$p)>;
def : VFP3InstAlias<"fconsts${p} $Sd, $val",
(FCONSTS SPR:$Sd, vfp_f32imm:$val, pred:$p)>;