This is an archive of the discontinued LLVM Phabricator instance.

[clang][PPC] Checking Unknown Values Passed to -mcpu
ClosedPublic

Authored by qiongsiwu1 on Dec 9 2022, 8:26 AM.

Details

Summary

Currently ppc::getPPCTargetCPU returns an empty string when it encounters an unknown value passed to -mcpu. This causes clang to ignore unknown -mcpu values silently.

This patch changes the behaviour of ppc::getPPCTargetCPU so that it passes the unknown option to the target info, so the target info can actually check if the CPU string is supported, and report an error when encountering unknown/unsupported CPU string.

Diff Detail

Event Timeline

qiongsiwu1 created this revision.Dec 9 2022, 8:26 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 9 2022, 8:26 AM
qiongsiwu1 requested review of this revision.Dec 9 2022, 8:26 AM
amyk added a comment.Dec 9 2022, 1:08 PM

It might be good to add a test case to illustrate the 'unknown target CPU' error that is issued as a result of this patch.

qiongsiwu1 updated this revision to Diff 481739.Dec 9 2022, 1:42 PM

Update to include a new test case against the unknown target error message. Thanks for the suggestion @amyk !

qiongsiwu1 edited the summary of this revision. (Show Details)Dec 9 2022, 2:14 PM
jamieschmeiser requested changes to this revision.Dec 12 2022, 5:50 AM
jamieschmeiser added inline comments.
clang/lib/Driver/ToolChains/Arch/PPC.cpp
77

This seems strange. If the option is "generic", it calls getPPCGenericTargetCPU(), but if it is "common", it returns "generic." I think you may want to also call getPPCGenericTargetCPU() here. There should probably also be an assume where this returns that it didn't return "generic" if that is the intended result. Also, there should also be tests for what happens when "generic" and "common" are specified.

100

Why did you change the type from const char *? Couldn't you use CPUName->data() in the default instead? With your change, I think it may need to create StringRefs around all of the choices and then just get the string from them.

This revision now requires changes to proceed.Dec 12 2022, 5:50 AM
qiongsiwu1 added inline comments.Dec 12 2022, 6:36 AM
clang/lib/Driver/ToolChains/Arch/PPC.cpp
77

I agree this generic vs common behaviour is strange. They way this patch handles generic vs common keeps the existing behaviour. In short, before this patch, clang already treats -mcpu=generic and -mcpu=common differently.

When -mcpu=generic is specified, we do some processing depending on the OS and architecture (effectively calling getPPCGenericTargetCPU). This happens because generic is not one of the cases of the big StringSwitch, and we return an empty string from ppc::getPPCTargetCPU.

On the other hand, when -mcpu=common is specified, the StringSwitch maps common to generic, and we simply returns generic as the target CPU name here.

Is this behaviour what we expect? If it is not, I will add a bug fix (with this patch or with a different patch if a separate one is easier to review). We only have an existing test case for generic, but not for common. I will add one with the bug fix.

100

I was worried about the comment on top of StringRef::data() which says "Get a pointer to the start of the string (which may not be null terminated).". I was not sure what would happen if the data inside CPUName was not null terminated (it might be fine) so I thought it would be safer to use the StringRefs directly instead.

jamieschmeiser added inline comments.
clang/lib/Driver/ToolChains/Arch/PPC.cpp
77

Yeah, I saw that you weren't changing the behaviour; I just suspect that it was an existing bug...Not sure who to check with about that @nemanjai? @hubert.reinterpretcast?

100

Probably the same sort of thing that would happen with creating a StringRef since that calls strlen to set the size of the string it is wrapping :-)

Updating to revert back to const char * in the big StringSwitch.

qiongsiwu1 marked 2 inline comments as done.Dec 12 2022, 8:26 AM
qiongsiwu1 added inline comments.
clang/lib/Driver/ToolChains/Arch/PPC.cpp
100

Got it! Thanks for the suggestion/clarification! The patch is updated to use const char *. I looked around and I do see StringRef::data() used quite liberally here and there (e.g. here). So I agree in this case we should be fine.

qiongsiwu1 marked an inline comment as done.Dec 12 2022, 10:31 AM

I'm fine with handling the return for common as a separate change, if necessary.
Is the error produced now because it passes back the incorrect option rather than quietly changing it to something appropriate as it did before?

qiongsiwu1 added a comment.EditedDec 12 2022, 12:26 PM

I'm fine with handling the return for common as a separate change, if necessary.

Sounds good! In this case I will fix it in a different patch once we decide what exactly to do for the -mcpu=common case.

Is the error produced now because it passes back the incorrect option rather than quietly changing it to something appropriate as it did before?

Yes precisely. When a TargetInfo is created, we have this code that checks the validity of the CPU string. Currently, we silently change anything weird to something reasonable and use it to create the TargetInfo. This patch removes that filtering and passes on the incorrect CPU string so we can catch the error.

jamieschmeiser accepted this revision.Dec 12 2022, 12:37 PM

LGTM

Thanks.

This revision is now accepted and ready to land.Dec 12 2022, 12:37 PM