[AArch64] Add Cavium ThunderX subtarget support.

[joelkevinjones]

Summary

[AArch64] Add Cavium ThunderX subtarget support.

Add subtarget detail and scheduling model for Cavium ThunderX core
(ARMv8.1A).

[t.p.northover]

There should probably be MC tests for the v8.1a features, but other than that the non-scheduler bits look fine (we'll have to take your word on the scheduler).

[rengolin]

Please, add TargetParser unit tests, to make sure the correct options are selected, but otherwise, also looks good to me.

[echristo]

Seems a little light on testing, but then again there's not a lot of reason to add tons of identical testing (though we have it right now).

TargetParser does need tests.

Probably wants a clang patch as well?

-eric

lib/Target/AArch64/AArch64Subtarget.h

48

Can you add a trailing , to this so we don't have to worry in the future?

[joelkevinjones]

I'm going to be working on this patch from Ananth. For the AsmParser test, I'm assuming that the file being referred to is: unittests/Support/TargetParserTest.cpp? If so, I have several questions:

1. What is this testing exactly? It just seems to be repeating the information in include/llvm/Support/AArch64TargetParser.def
2. Is simply adding "thunderx" to the "CPU" array initialization sufficient?

[jmolloy]

Hi,

This generally looks good to me - I agree that the targetparser testing is pretty tautological. Eric, do you have input on whether that's needed?

Cheers,

James

lib/Target/AArch64/AArch64.td

267

Indentation is off here.

[rengolin]

In D24540#572750, @jmolloy wrote:

Hi,

This generally looks good to me - I agree that the targetparser testing is pretty tautological. Eric, do you have input on whether that's needed?

We also have some parsing tests to make sure we're not loosing anything, but I agree, the number of relevant tests there is not great.

I think this can be a task for a separate patch.

cheers,
--renato

[jgreenhalgh]

lib/Target/AArch64/AArch64.td

267

I'm confused by this feature bit, and it doesn't line up with the -mcpu=thunderx support in GCC.

As far as I am aware, HasV8_1aOps enables support for all of the ARMv8.1-A extensions, i.e. the Large System Extensions, PAN, and the RDMA instructions. But, there exist ThunderX implementations which don't provide support for all of these extensions. For these ThunderX targets, the set of extensions enabled here would be too large.

The GCC implementation only enables ARMv8-A with the CRC, Advanced SIMD, Floating-Point and Cryptography extensions.

Would that be more correct here?

[rengolin]

lib/Target/AArch64/AArch64.td

267

If that's the case, then yes, ARMv8A would be a better match. I don't know enough about ThunderX support to have an opinion, though.

[davidlt]

lib/Target/AArch64/AArch64.td

267

IIRC, ThunderX Pass 1 was ARMv8.0 silicon (before landed in general availability products, I guess), but what's shipping now is ThunderX Pass 2 which is ARMv8.1.

From Andrew Pinski patch (Nov 2015) which probably never landed in GCC:

The reason why thunderxt88pass1 is seperate from thunderx is because
thunderx is changed to be an ARMv8.1 arch core while thunderxt88pass1
is still an ARMv8 arch core.

See, e.g. https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02148.html

[joelkevinjones]

We also have some parsing tests to make sure we're not loosing anything, but I agree, the number of relevant tests there is not great.

I think this can be a task for a separate patch.

cheers,
--renato

I've done a search in both test and unittests for some kind of parsing test for features present vs. not present, but I could find what you were referring to.

[jgreenhalgh]

lib/Target/AArch64/AArch64.td

267

OK. My memory was that there was no ThunderX part which supported the RDMA AdvancedSIMD extensions, only the Large System Extensions. But that GCC patch would have enabled the same set of extensions and would bring LLVM and GCC back in line. I'm happy to withdraw my objection.

[joelkevinjones]

lib/Target/AArch64/AArch64.td

267

That is correct. Although there were very few pass 1 machines that "escaped", I will redo the patch to have a means of specifying explicitly that ones wants to generate code for a pass 1 thunderx. Would it be best to (is it even possible) in AArch64.td to use a SubtargetFeature<"pass1", ... to disable features from a base of "thunderx"?

[rengolin]

lib/Target/AArch64/AArch64.td

267

No, they should be two different cpus: "thunderx1" and thunderx2".

Or we only implement "thunderx" as "thunderx2" and tell those few people that have pass1 to use:

-march=armv8-a+crc+crypto+nolse+nordma+nopan

[davidlt]

lib/Target/AArch64/AArch64.td

267

You don't want to use "thunderx2" for "pass 2" silicons. Cavium already announced 2nd gen silicons aka "thunderx2", those are ARMv8.2. You can read more here: http://cavium.com/newsevents-Cavium-Announces-ThunderX2.html

[rengolin]

lib/Target/AArch64/AArch64.td

267

Hum... And I thought X2 was the same as pass 2... :/

Right, than I suggest you just leave the pass 1 people in the dark and make thunderx 8.1, requiring the convoluted march command line to the few damned souls.

Isn't that what happens in GCC, too?

[jgreenhalgh]

lib/Target/AArch64/AArch64.td

267

Not until someone updates the support for -mcpu=thunderx to be ThunderX Pass 2. At the moment GCC can only target ThunderX Pass 1, and you need the command line dance to get LSE extensions (and others) enabled for Pass 2.

[joelkevinjones]

lib/Target/AArch64/AArch64.td

267

Not having to do a separate sub-target works for me. :-)

Is there a good place to place user documentation for the pass 1 dance?

[rengolin]

lib/Target/AArch64/AArch64.td

267

I can't think of any place where we store those magic runes. I have written one about cross-compilation a while ago, but that was orthogonal to the problem here, and creating a new one just for that isn't feasible.

Is there somewhere at Cavium where this could be? Some "Getting started with Cavium LLVM"?

[joelkevinjones]

I'm in charge of this revision now.

[joelkevinjones]

I'm splitting this revision into two parts, One will be to have the target names match those in the GCC proposal (see the gcc-patches mailing list, 1 November 2016, https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00155.html). The other will be a fix to the instruction mapping to scheduling information.

include/llvm/Support/AArch64TargetParser.def

                 (AArch64::AEK_SIMD | AArch64::AEK_CRC | AArch64::AEK_CRYPTO))
 AARCH64_CPU_NAME("vulcan", AK_ARMV8_1A, FK_CRYPTO_NEON_FP_ARMV8, false,
                 (AArch64::AEK_SIMD | AArch64::AEK_CRC | AArch64::AEK_CRYPTO))
+AARCH64_CPU_NAME("thunderx", AK_ARMV8_1A, FK_CRYPTO_NEON_FP_ARMV8, false,
+                (AArch64::AEK_SIMD | AArch64::AEK_CRC | AArch64::AEK_CRYPTO))
+
 // Invalid CPU
 AARCH64_CPU_NAME("invalid", AK_INVALID, FK_INVALID, true, AArch64::AEK_INVALID)
 #undef AARCH64_CPU_NAME

lib/Target/AArch64/AArch64.td

 include "AArch64SchedM1.td"
 include "AArch64SchedKryo.td"
 include "AArch64SchedVulcan.td"
+include "AArch64SchedThunderX.td"
 
 def ProcA35     : SubtargetFeature<"a35", "ARMProcFamily", "CortexA35",
                                    "Cortex-A35 ARM processors", [

                                    FeaturePredictableSelectIsExpensive,
                                    HasV8_1aOps]>;
 
+def ProcThunderX     : SubtargetFeature<"thunderx", "ARMProcFamily", "ThunderX",
+                                   "ThunderX ARM processors", [
+                                   FeatureCRC,
+                                   FeatureCrypto,
+                                   FeatureFPARMv8,
+                                   FeatureMergeNarrowLd,
+                                   FeatureNEON,
+                                   FeaturePerfMon,
+                                   FeaturePostRAScheduler,
+           HasV8_1aOps]>;
+
+
 def : ProcessorModel<"generic", NoSchedModel, [
                      FeatureCRC,
                      FeatureFPARMv8,

 def : ProcessorModel<"exynos-m2", ExynosM1Model, [ProcExynosM1]>;
 def : ProcessorModel<"kryo", KryoModel, [ProcKryo]>;
 def : ProcessorModel<"vulcan", VulcanModel, [ProcVulcan]>;
+def : ProcessorModel<"thunderx", ThunderXModel, [ProcThunderX]>;
 
 //===----------------------------------------------------------------------===//
 // Assembly parser

lib/Target/AArch64/AArch64SchedThunderX.td

+//==- AArch64SchedThunderX.td - ThunderX Scheduling Definitions -*- tablegen -*-=//
+//
+//                     The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===----------------------------------------------------------------------===//
+//
+// This file defines the itinerary class data for the Cavium ThunderX processors.
+//
+//===----------------------------------------------------------------------===//
+
+// ===---------------------------------------------------------------------===//
+// The following definitions describe the simpler per-operand machine model.
+// This works with MachineScheduler. See MCSchedModel.h for details.
+
+// ThunderX machine model for scheduling and other instruction cost heuristics.
+def ThunderXModel : SchedMachineModel {
+  let MicroOpBufferSize = 0; // Explicitly set to zero since ThunderX is in-order.
+  let IssueWidth = 2;        // 2 micro-ops are dispatched per cycle.
+  let LoadLatency = 3;       // Optimistic load latency assuming bypass.
+                             // This is overriden by OperandCycles if the
+                             // Itineraries are queried instead.
+  let MispredictPenalty = 7; 
+  let CompleteModel = 1;
+  let LoopMicroOpBufferSize = 8;
+}
+
+
+//===----------------------------------------------------------------------===//
+// Define each kind of processor resource and number available.
+
+def ThunderXUnitALU    : ProcResource<2> { let BufferSize = 0; } // Int ALU
+def ThunderXUnitMAC    : ProcResource<1> { let BufferSize = 0; } // Int MAC
+def ThunderXUnitDiv    : ProcResource<1> { let BufferSize = 0; } // Int Division
+def ThunderXUnitLdSt   : ProcResource<1> { let BufferSize = 0; } // Load/Store
+def ThunderXUnitB      : ProcResource<1> { let BufferSize = 0; } // Branch
+def ThunderXUnitFPALU  : ProcResource<1> { let BufferSize = 0; } // FP ALU
+def ThunderXUnitFPMDS  : ProcResource<1> { let BufferSize = 0; } // FP Mult/Div/Sqrt
+
+
+//===----------------------------------------------------------------------===//
+// Subtarget-specific SchedWrite types which both map the ProcResources and
+// set the latency.
+
+let SchedModel = ThunderXModel in {
+
+// ALU - Despite having a full latency of 4, most of the ALU instructions can
+//       forward a cycle earlier and then two cycles earlier in the case of a
+//       shift-only instruction. These latencies will be incorrect when the
+//       result cannot be forwarded, but modeling isn't rocket surgery.
+def : WriteRes<WriteImm, [ThunderXUnitALU]> { let Latency = 3; }
+def : WriteRes<WriteI, [ThunderXUnitALU]> { let Latency = 3; }
+def : WriteRes<WriteISReg, [ThunderXUnitALU]> { let Latency = 3; }
+def : WriteRes<WriteIEReg, [ThunderXUnitALU]> { let Latency = 3; }
+def : WriteRes<WriteIS, [ThunderXUnitALU]> { let Latency = 2; }
+def : WriteRes<WriteExtr, [ThunderXUnitALU]> { let Latency = 3; }
+
+// MAC
+def : WriteRes<WriteIM32, [ThunderXUnitMAC]> { let Latency = 4; }
+def : WriteRes<WriteIM64, [ThunderXUnitMAC]> { let Latency = 4; }
+
+// Div
+def : WriteRes<WriteID32, [ThunderXUnitDiv]> { let Latency = 15; }
+def : WriteRes<WriteID64, [ThunderXUnitDiv]> { let Latency = 15; }
+
+// Load
+def : WriteRes<WriteLD, [ThunderXUnitLdSt]> { let Latency = 3; }
+def : WriteRes<WriteLDIdx, [ThunderXUnitLdSt]> { let Latency = 3; }
+def : WriteRes<WriteLDHi, [ThunderXUnitLdSt]> { let Latency = 3; }
+
+// Vector Load - Vector loads take 1-5 cycles to issue. For the WriteVecLd
+//               below, choosing the median of 3 which makes the latency 6.
+//               May model this more carefully in the future. The remaining
+//               ThunderXWriteVLD# types represent the 1-5 cycle issues explicitly.
+def : WriteRes<WriteVLD, [ThunderXUnitLdSt]> { let Latency = 6;
+                                          let ResourceCycles = [3]; }
+def ThunderXWriteVLD1 : SchedWriteRes<[ThunderXUnitLdSt]> { let Latency = 4; }
+def ThunderXWriteVLD2 : SchedWriteRes<[ThunderXUnitLdSt]> { let Latency = 12;
+                                                  let ResourceCycles = [8]; }
+def ThunderXWriteVLD3 : SchedWriteRes<[ThunderXUnitLdSt]> { let Latency = 14;
+                                                  let ResourceCycles = [10]; }
+def ThunderXWriteVLD4 : SchedWriteRes<[ThunderXUnitLdSt]> { let Latency = 16;
+                                                  let ResourceCycles = [12]; }
+def ThunderXWriteVLD5 : SchedWriteRes<[ThunderXUnitLdSt]> { let Latency = 16;
+                                                  let ResourceCycles = [12]; }
+
+// Pre/Post Indexing - Performed as part of address generation which is already
+//                     accounted for in the WriteST* latencies below
+def : WriteRes<WriteAdr, []> { let Latency = 0; }
+
+// Store
+def : WriteRes<WriteST, [ThunderXUnitLdSt]> { let Latency = 1; }
+def : WriteRes<WriteSTP, [ThunderXUnitLdSt]> { let Latency = 1; }
+def : WriteRes<WriteSTIdx, [ThunderXUnitLdSt]> { let Latency = 1; }
+def : WriteRes<WriteSTX, [ThunderXUnitLdSt]> { let Latency = 1; }
+
+// Vector Store - Similar to vector loads, can take 1-3 cycles to issue.
+def : WriteRes<WriteVST, [ThunderXUnitLdSt]> { let Latency = 5;
+                                          let ResourceCycles = [2];}
+def ThunderXWriteVST1 : SchedWriteRes<[ThunderXUnitLdSt]> { let Latency = 4; }
+def ThunderXWriteVST2 : SchedWriteRes<[ThunderXUnitLdSt]> { let Latency = 5;
+                                                  let ResourceCycles = [2]; }
+def ThunderXWriteVST3 : SchedWriteRes<[ThunderXUnitLdSt]> { let Latency = 6;
+                                                  let ResourceCycles = [3]; }
+
+def : WriteRes<WriteAtomic, []> { let Unsupported = 1; }
+
+// Branch
+def : WriteRes<WriteBr, [ThunderXUnitB]>;
+def : WriteRes<WriteBrReg, [ThunderXUnitB]>;
+def : WriteRes<WriteSys, [ThunderXUnitB]>;
+def : WriteRes<WriteBarrier, [ThunderXUnitB]>;
+def : WriteRes<WriteHint, [ThunderXUnitB]>;
+
+// FP ALU
+def : WriteRes<WriteF, [ThunderXUnitFPALU]> { let Latency = 6; }
+def : WriteRes<WriteFCmp, [ThunderXUnitFPALU]> { let Latency = 6; }
+def : WriteRes<WriteFCvt, [ThunderXUnitFPALU]> { let Latency = 6; }
+def : WriteRes<WriteFCopy, [ThunderXUnitFPALU]> { let Latency = 6; }
+def : WriteRes<WriteFImm, [ThunderXUnitFPALU]> { let Latency = 6; }
+def : WriteRes<WriteV, [ThunderXUnitFPALU]> { let Latency = 6; }
+
+// FP Mul, Div, Sqrt
+def : WriteRes<WriteFMul, [ThunderXUnitFPMDS]> { let Latency = 6; }
+def : WriteRes<WriteFDiv, [ThunderXUnitFPMDS]> { let Latency = 33;
+                                            let ResourceCycles = [29]; }
+def ThunderXWriteFMAC : SchedWriteRes<[ThunderXUnitFPMDS]> { let Latency = 10; }
+def ThunderXWriteFDivSP : SchedWriteRes<[ThunderXUnitFPMDS]> { let Latency = 18;
+                                                     let ResourceCycles = [14]; }
+def ThunderXWriteFDivDP : SchedWriteRes<[ThunderXUnitFPMDS]> { let Latency = 33;
+                                                     let ResourceCycles = [29]; }
+def ThunderXWriteFSqrtSP : SchedWriteRes<[ThunderXUnitFPMDS]> { let Latency = 17;
+                                                      let ResourceCycles = [13]; }
+def ThunderXWriteFSqrtDP : SchedWriteRes<[ThunderXUnitFPMDS]> { let Latency = 32;
+                                                      let ResourceCycles = [28]; }
+
+//===----------------------------------------------------------------------===//
+// Subtarget-specific SchedRead types.
+
+// No forwarding for these reads.
+def : ReadAdvance<ReadExtrHi, 0>;
+def : ReadAdvance<ReadAdrBase, 0>;
+def : ReadAdvance<ReadVLD, 0>;
+
+// ALU - Most operands in the ALU pipes are not needed for two cycles. Shiftable
+//       operands are needed one cycle later if and only if they are to be
+//       shifted. Otherwise, they too are needed two cycles later. This same
+//       ReadAdvance applies to Extended registers as well, even though there is
+//       a separate SchedPredicate for them.
+def : ReadAdvance<ReadI, 2, [WriteImm,WriteI,
+                             WriteISReg, WriteIEReg,WriteIS,
+                             WriteID32,WriteID64,
+                             WriteIM32,WriteIM64]>;
+def ThunderXReadShifted : SchedReadAdvance<1, [WriteImm,WriteI,
+                                          WriteISReg, WriteIEReg,WriteIS,
+                                          WriteID32,WriteID64,
+                                          WriteIM32,WriteIM64]>;
+def ThunderXReadNotShifted : SchedReadAdvance<2, [WriteImm,WriteI,
+                                             WriteISReg, WriteIEReg,WriteIS,
+                                             WriteID32,WriteID64,
+                                             WriteIM32,WriteIM64]>;
+def ThunderXReadISReg : SchedReadVariant<[
+  SchedVar<RegShiftedPred, [ThunderXReadShifted]>,
+  SchedVar<NoSchedPred, [ThunderXReadNotShifted]>]>;
+def : SchedAlias<ReadISReg, ThunderXReadISReg>;
+
+def ThunderXReadIEReg : SchedReadVariant<[
+  SchedVar<RegExtendedPred, [ThunderXReadShifted]>,
+  SchedVar<NoSchedPred, [ThunderXReadNotShifted]>]>;
+def : SchedAlias<ReadIEReg, ThunderXReadIEReg>;
+
+// MAC - Operands are generally needed one cycle later in the MAC pipe.
+//       Accumulator operands are needed two cycles later.
+def : ReadAdvance<ReadIM, 1, [WriteImm,WriteI,
+                              WriteISReg, WriteIEReg,WriteIS,
+                              WriteID32,WriteID64,
+                              WriteIM32,WriteIM64]>;
+def : ReadAdvance<ReadIMA, 2, [WriteImm,WriteI,
+                               WriteISReg, WriteIEReg,WriteIS,
+                               WriteID32,WriteID64,
+                               WriteIM32,WriteIM64]>;
+
+// Div
+def : ReadAdvance<ReadID, 1, [WriteImm,WriteI,
+                              WriteISReg, WriteIEReg,WriteIS,
+                              WriteID32,WriteID64,
+                              WriteIM32,WriteIM64]>;
+
+//===----------------------------------------------------------------------===//
+// Subtarget-specific InstRWs.
+
+//---
+// Miscellaneous
+//---
+def : InstRW<[WriteI], (instrs COPY)>;
+
+//---
+// Vector Loads
+//---
+def : InstRW<[ThunderXWriteVLD1], (instregex "LD1i(8|16|32|64)$")>;
+def : InstRW<[ThunderXWriteVLD1], (instregex "LD1Rv(8b|4h|2s|1d|16b|8h|4s|2d)$")>;
+def : InstRW<[ThunderXWriteVLD1], (instregex "LD1Onev(8b|4h|2s|1d|16b|8h|4s|2d)$")>;
+def : InstRW<[ThunderXWriteVLD2], (instregex "LD1Twov(8b|4h|2s|1d|16b|8h|4s|2d)$")>;
+def : InstRW<[ThunderXWriteVLD3], (instregex "LD1Threev(8b|4h|2s|1d|16b|8h|4s|2d)$")>;
+def : InstRW<[ThunderXWriteVLD4], (instregex "LD1Fourv(8b|4h|2s|1d|16b|8h|4s|2d)$")>;
+def : InstRW<[ThunderXWriteVLD1, WriteAdr], (instregex "LD1i(8|16|32|64)_POST$")>;
+def : InstRW<[ThunderXWriteVLD1, WriteAdr], (instregex "LD1Rv(8b|4h|2s|1d|16b|8h|4s|2d)_POST$")>;
+def : InstRW<[ThunderXWriteVLD1, WriteAdr], (instregex "LD1Onev(8b|4h|2s|1d|16b|8h|4s|2d)_POST$")>;
+def : InstRW<[ThunderXWriteVLD2, WriteAdr], (instregex "LD1Twov(8b|4h|2s|1d|16b|8h|4s|2d)_POST$")>;
+def : InstRW<[ThunderXWriteVLD3, WriteAdr], (instregex "LD1Threev(8b|4h|2s|1d|16b|8h|4s|2d)_POST$")>;
+def : InstRW<[ThunderXWriteVLD4, WriteAdr], (instregex "LD1Fourv(8b|4h|2s|1d|16b|8h|4s|2d)_POST$")>;
+
+def : InstRW<[ThunderXWriteVLD1], (instregex "LD2i(8|16|32|64)$")>;
+def : InstRW<[ThunderXWriteVLD1], (instregex "LD2Rv(8b|4h|2s|1d|16b|8h|4s|2d)$")>;
+def : InstRW<[ThunderXWriteVLD2], (instregex "LD2Twov(8b|4h|2s)$")>;
+def : InstRW<[ThunderXWriteVLD4], (instregex "LD2Twov(16b|8h|4s|2d)$")>;
+def : InstRW<[ThunderXWriteVLD1, WriteAdr], (instregex "LD2i(8|16|32|64)(_POST)?$")>;
+def : InstRW<[ThunderXWriteVLD1, WriteAdr], (instregex "LD2Rv(8b|4h|2s|1d|16b|8h|4s|2d)(_POST)?$")>;
+def : InstRW<[ThunderXWriteVLD2, WriteAdr], (instregex "LD2Twov(8b|4h|2s)(_POST)?$")>;
+def : InstRW<[ThunderXWriteVLD4, WriteAdr], (instregex "LD2Twov(16b|8h|4s|2d)(_POST)?$")>;
+
+def : InstRW<[ThunderXWriteVLD2], (instregex "LD3i(8|16|32|64)$")>;
+def : InstRW<[ThunderXWriteVLD2], (instregex "LD3Rv(8b|4h|2s|1d|16b|8h|4s|2d)$")>;
+def : InstRW<[ThunderXWriteVLD4], (instregex "LD3Threev(8b|4h|2s|1d|16b|8h|4s)$")>;
+def : InstRW<[ThunderXWriteVLD3], (instregex "LD3Threev(2d)$")>;
+def : InstRW<[ThunderXWriteVLD2, WriteAdr], (instregex "LD3i(8|16|32|64)_POST$")>;
+def : InstRW<[ThunderXWriteVLD2, WriteAdr], (instregex "LD3Rv(8b|4h|2s|1d|16b|8h|4s|2d)_POST$")>;
+def : InstRW<[ThunderXWriteVLD4, WriteAdr], (instregex "LD3Threev(8b|4h|2s|1d|16b|8h|4s)_POST$")>;
+def : InstRW<[ThunderXWriteVLD3, WriteAdr], (instregex "LD3Threev(2d)_POST$")>;
+
+def : InstRW<[ThunderXWriteVLD2], (instregex "LD4i(8|16|32|64)$")>;
+def : InstRW<[ThunderXWriteVLD2], (instregex "LD4Rv(8b|4h|2s|1d|16b|8h|4s|2d)$")>;
+def : InstRW<[ThunderXWriteVLD5], (instregex "LD4Fourv(8b|4h|2s|1d|16b|8h|4s)$")>;
+def : InstRW<[ThunderXWriteVLD4], (instregex "LD4Fourv(2d)$")>;
+def : InstRW<[ThunderXWriteVLD2, WriteAdr], (instregex "LD4i(8|16|32|64)_POST$")>;
+def : InstRW<[ThunderXWriteVLD2, WriteAdr], (instregex "LD4Rv(8b|4h|2s|1d|16b|8h|4s|2d)_POST$")>;
+def : InstRW<[ThunderXWriteVLD5, WriteAdr], (instregex "LD4Fourv(8b|4h|2s|1d|16b|8h|4s)_POST$")>;
+def : InstRW<[ThunderXWriteVLD4, WriteAdr], (instregex "LD4Fourv(2d)_POST$")>;
+
+//---
+// Vector Stores
+//---
+def : InstRW<[ThunderXWriteVST1], (instregex "ST1i(8|16|32|64)$")>;
+def : InstRW<[ThunderXWriteVST1], (instregex "ST1Onev(8b|4h|2s|1d|16b|8h|4s|2d)$")>;
+def : InstRW<[ThunderXWriteVST1], (instregex "ST1Twov(8b|4h|2s|1d|16b|8h|4s|2d)$")>;
+def : InstRW<[ThunderXWriteVST2], (instregex "ST1Threev(8b|4h|2s|1d|16b|8h|4s|2d)$")>;
+def : InstRW<[ThunderXWriteVST2], (instregex "ST1Fourv(8b|4h|2s|1d|16b|8h|4s|2d)$")>;
+def : InstRW<[ThunderXWriteVST1, WriteAdr], (instregex "ST1i(8|16|32|64)_POST$")>;
+def : InstRW<[ThunderXWriteVST1, WriteAdr], (instregex "ST1Onev(8b|4h|2s|1d|16b|8h|4s|2d)_POST$")>;
+def : InstRW<[ThunderXWriteVST1, WriteAdr], (instregex "ST1Twov(8b|4h|2s|1d|16b|8h|4s|2d)_POST$")>;
+def : InstRW<[ThunderXWriteVST2, WriteAdr], (instregex "ST1Threev(8b|4h|2s|1d|16b|8h|4s|2d)_POST$")>;
+def : InstRW<[ThunderXWriteVST2, WriteAdr], (instregex "ST1Fourv(8b|4h|2s|1d|16b|8h|4s|2d)_POST$")>;
+
+def : InstRW<[ThunderXWriteVST1], (instregex "ST2i(8|16|32|64)$")>;
+def : InstRW<[ThunderXWriteVST1], (instregex "ST2Twov(8b|4h|2s)$")>;
+def : InstRW<[ThunderXWriteVST2], (instregex "ST2Twov(16b|8h|4s|2d)$")>;
+def : InstRW<[ThunderXWriteVST1, WriteAdr], (instregex "ST2i(8|16|32|64)_POST$")>;
+def : InstRW<[ThunderXWriteVST1, WriteAdr], (instregex "ST2Twov(8b|4h|2s)_POST$")>;
+def : InstRW<[ThunderXWriteVST2, WriteAdr], (instregex "ST2Twov(16b|8h|4s|2d)_POST$")>;
+
+def : InstRW<[ThunderXWriteVST2], (instregex "ST3i(8|16|32|64)$")>;
+def : InstRW<[ThunderXWriteVST3], (instregex "ST3Threev(8b|4h|2s|1d|16b|8h|4s)$")>;
+def : InstRW<[ThunderXWriteVST2], (instregex "ST3Threev(2d)$")>;
+def : InstRW<[ThunderXWriteVST2, WriteAdr], (instregex "ST3i(8|16|32|64)_POST$")>;
+def : InstRW<[ThunderXWriteVST3, WriteAdr], (instregex "ST3Threev(8b|4h|2s|1d|16b|8h|4s)_POST$")>;
+def : InstRW<[ThunderXWriteVST2, WriteAdr], (instregex "ST3Threev(2d)_POST$")>;
+
+def : InstRW<[ThunderXWriteVST2], (instregex "ST4i(8|16|32|64)$")>;
+def : InstRW<[ThunderXWriteVST3], (instregex "ST4Fourv(8b|4h|2s|1d|16b|8h|4s)$")>;
+def : InstRW<[ThunderXWriteVST2], (instregex "ST4Fourv(2d)$")>;
+def : InstRW<[ThunderXWriteVST2, WriteAdr], (instregex "ST4i(8|16|32|64)_POST$")>;
+def : InstRW<[ThunderXWriteVST3, WriteAdr], (instregex "ST4Fourv(8b|4h|2s|1d|16b|8h|4s)_POST$")>;
+def : InstRW<[ThunderXWriteVST2, WriteAdr], (instregex "ST4Fourv(2d)_POST$")>;
+
+//---
+// Floating Point MAC, DIV, SQRT
+//---
+def : InstRW<[ThunderXWriteFMAC], (instregex "^FN?M(ADD|SUB).*")>;
+def : InstRW<[ThunderXWriteFMAC], (instregex "^FML(A|S).*")>;
+def : InstRW<[ThunderXWriteFDivSP], (instrs FDIVSrr)>;
+def : InstRW<[ThunderXWriteFDivDP], (instrs FDIVDrr)>;
+def : InstRW<[ThunderXWriteFDivSP], (instregex "^FDIVv.*32$")>;
+def : InstRW<[ThunderXWriteFDivDP], (instregex "^FDIVv.*64$")>;
+def : InstRW<[ThunderXWriteFSqrtSP], (instregex "^.*SQRT.*32$")>;
+def : InstRW<[ThunderXWriteFSqrtDP], (instregex "^.*SQRT.*64$")>;
+
+}

lib/Target/AArch64/AArch64Subtarget.h

     Cyclone,
     ExynosM1,
     Kryo,
-    Vulcan
+    Vulcan,
+    ThunderX
   };
 
 protected:

lib/Target/AArch64/AArch64Subtarget.cpp

     MinPrefetchStride = 1024;
     MaxPrefetchIterationsAhead = 11;
     break;
+  case ThunderX:
+    CacheLineSize = 128;
+    PrefetchDistance = 256;
+    PrefFunctionAlignment = 5;
+    PrefLoopAlignment = 5;
+    MinPrefetchStride = 8;
+    MaxPrefetchIterationsAhead = 7;
+    MergeNarrowLoads = true;
+    break;
   case Vulcan:
     MaxInterleaveFactor = 4;
     break;

test/CodeGen/AArch64/cpus.ll

 ; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=exynos-m2 2>&1 | FileCheck %s
 ; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=kryo 2>&1 | FileCheck %s
 ; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=vulcan 2>&1 | FileCheck %s
+; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=thunderx 2>&1 | FileCheck %s
 ; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=invalidcpu 2>&1 | FileCheck %s --check-prefix=INVALID
 
 ; CHECK-NOT: {{.*}}  is not a recognized processor for this target

test/CodeGen/AArch64/remat.ll

 ; RUN: llc -mtriple=aarch64-linux-gnuabi -mcpu=exynos-m2 -o - %s | FileCheck %s
 ; RUN: llc -mtriple=aarch64-linux-gnuabi -mcpu=kryo -o - %s | FileCheck %s
 ; RUN: llc -mtriple=aarch64-linux-gnuabi -mcpu=vulcan -o - %s | FileCheck %s
+; RUN: llc -mtriple=aarch64-linux-gnuabi -mcpu=thunderx -o - %s | FileCheck %s
 ; RUN: llc -mtriple=aarch64-linux-gnuabi -mattr=+custom-cheap-as-move -o - %s | FileCheck %s
 
 %X = type { i64, i64, i64 }