Page MenuHomePhabricator

[AArch64] Add Cavium ThunderX subtarget support.
AbandonedPublic

Authored by joelkevinjones on Sep 13 2016, 6:30 PM.

Details

Summary

[AArch64] Add Cavium ThunderX subtarget support.

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

Diff Detail

Repository
rL LLVM

Event Timeline

ajasty-cavium retitled this revision from to [AArch64] Add Cavium ThunderX subtarget support..
ajasty-cavium updated this object.
ajasty-cavium set the repository for this revision to rL LLVM.
ajasty-cavium added a subscriber: joelkevinjones.
lattner resigned from this revision.Sep 13 2016, 9:02 PM
lattner removed a reviewer: lattner.
t.p.northover edited edge metadata.Sep 14 2016, 2:22 AM

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).

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

echristo edited edge metadata.Sep 19 2016, 2:45 PM

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?

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 edited edge metadata.Oct 18 2016, 4:47 AM

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 accepted this revision.Oct 18 2016, 5:05 AM
rengolin added a reviewer: rengolin.

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

This revision is now accepted and ready to land.Oct 18 2016, 5:05 AM
jgreenhalgh added inline comments.
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 added inline comments.Oct 18 2016, 6:38 AM
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 added inline comments.
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

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 added inline comments.Oct 18 2016, 7:02 AM
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 added inline comments.Oct 18 2016, 7:08 AM
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 added inline comments.Oct 18 2016, 7:32 AM
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 added inline comments.Oct 18 2016, 7:37 AM
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 added inline comments.Oct 18 2016, 7:44 AM
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 added inline comments.Oct 18 2016, 8:00 AM
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 added inline comments.Oct 18 2016, 9:02 AM
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 added inline comments.Oct 18 2016, 9:38 AM
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 commandeered this revision.Nov 2 2016, 6:52 AM
joelkevinjones edited reviewers, added: ajasty-cavium; removed: joelkevinjones.

I'm in charge of this revision now.

joelkevinjones abandoned this revision.Nov 2 2016, 6:58 AM

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.