This is an archive of the discontinued LLVM Phabricator instance.

Make march/target-cpu print a note with the list of valid values for ARM
ClosedPublic

Authored by erichkeane on Feb 6 2018, 11:05 AM.

Details

Summary

When rejecting a march= or target-cpu command line parameter,
the message is quite lacking. This patch adds a note that prints
all possible values for the current target, if the target supports it.

This adds support for the ARM/AArch64 targets (more to come!). These
two also require: https://reviews.llvm.org/D42979

Diff Detail

Repository
rL LLVM

Event Timeline

erichkeane created this revision.Feb 6 2018, 11:05 AM
fhahn added a subscriber: fhahn.

I like the idea. However for all backends, except Arm and AArch64, we would have to maintain another list of CPU names. At least for the targets which implement isValidCPUName, we could add an array with valid names and use that. That's still not ideal, but I do not think we should hold back this patch until all targets use the same infrastructure to handle CPUs. As for tests, we should test the note for all backends I think.

test/Misc/target-parser.c
3 ↗(On Diff #133049)

drop one set of //

fhahn added a comment.Feb 7 2018, 1:52 AM

Also with tests for each backend, this diff will get quite big. As this is opt-in, it might make sense to enable backends separately.

erichkeane retitled this revision from Make march/target-cpu print a note with the list of valid values to Make march/target-cpu print a note with the list of valid values for ARM.
erichkeane edited the summary of this revision. (Show Details)

I think this means that the Clang test needs to be updated whenever somebody adds an architecture to LLVM? Maybe just test that Clang emits a note and don't check which values it prints? These should be checked in the backend...

fhahn added a comment.Feb 8 2018, 1:34 AM

I think this means that the Clang test needs to be updated whenever somebody adds an architecture to LLVM? Maybe just test that Clang emits a note and don't check which values it prints? These should be checked in the backend...

Yes, I agree checking all CPUs names is too fragile and not necessary for AArch64 or ARM, as the list of CPUs is provided by llvm.

It is probably enough to check if we emit the note for AArch64 and ARM and maybe check that it is non-empty or checking that it contains a CPU we know should always be there. Checking the full list may make sense for other backends, as we have to modify Clang directly to add support.

That makes sense. I changed the ARM one to check ONLY the first one, since in each case that seems like the oldest anyway. It at least makes sure that the lists are distinct, and avoids this cross-repo fragility.

erichkeane updated this revision to Diff 133435.Feb 8 2018, 9:00 AM

Simplified ARM tests as requested.

fhahn accepted this revision.Feb 8 2018, 9:26 AM

LGTM thanks. Please wait a day or so with committing so others can raise additional concerns.

test/Misc/target-invalid-cpu-note.c
8 ↗(On Diff #133435)

stray newline? :)

This revision is now accepted and ready to land.Feb 8 2018, 9:26 AM
erichkeane updated this revision to Diff 133442.Feb 8 2018, 9:43 AM
erichkeane marked an inline comment as done.

Removed extra newline.

Hahnfeld added inline comments.Feb 8 2018, 10:20 AM
test/Misc/target-invalid-cpu-note.c
1 ↗(On Diff #133442)

Is there a reason you don't use -verify=<prefix> in this test? That's what I've usually seen for checking errors and notes...

3 ↗(On Diff #133442)

Is this guaranteed to be first? If not, you might want to add {{.*}} to account for future updates.

(If not using -verify as suggested above, you could also use ARM-SAME on a new-line. This should also allow arbitrary values in between.)

erichkeane added inline comments.Feb 8 2018, 10:36 AM
test/Misc/target-invalid-cpu-note.c
1 ↗(On Diff #133442)

Um... wow... TIL.

3 ↗(On Diff #133442)

Not guaranteed. I'll do this, thanks!

erichkeane added inline comments.Feb 8 2018, 10:56 AM
test/Misc/target-invalid-cpu-note.c
1 ↗(On Diff #133442)

Sadly, -verify= doesn't seem to have a way to specify things that happen without a line-number, so I wasn't able to do it :/

Relaxed the test further.

This revision was automatically updated to reflect the committed changes.

@erichkeane Could you please tell me why this was done only for -cc1 and if there is any plan to add this to the driver in general ?

nhaehnle removed a subscriber: nhaehnle.Mar 17 2018, 5:25 AM