This is an archive of the discontinued LLVM Phabricator instance.

[OpenMP][CUDA][AMDGPU] Accept case insensitive subarchitecture names
Needs ReviewPublic

Authored by jhuber6 on Oct 10 2022, 1:08 PM.

Details

Summary

The offloading toolchains are typically built by specifing a
subarchitecture during compilation via --offload-arch=. This patch
allows users to input subarchitecture names that ignore the case. So if
the user inputs gfx90A it will treat it as gfx90a. This is primarily
for user convenicence.

Diff Detail

Event Timeline

jhuber6 created this revision.Oct 10 2022, 1:08 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 10 2022, 1:08 PM
jhuber6 requested review of this revision.Oct 10 2022, 1:08 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptOct 10 2022, 1:08 PM
tra added a comment.Oct 10 2022, 1:31 PM

Is that really something we need/want to do? I've never seen anyone complaining about this particular issue.

clang/gcc are case-sensitive for similar options, like -march: https://godbolt.org/z/3jKzTda7h
I think offloading options should behave consistently in that regard. If we do want to make arch/CPU names case-agnostic, it should be done for all such options.

Is that really something we need/want to do? I've never seen anyone complaining about this particular issue.

clang/gcc are case-sensitive for similar options, like -march: https://godbolt.org/z/3jKzTda7h
I think offloading options should behave consistently in that regard. If we do want to make arch/CPU names case-agnostic, it should be done for all such options.

This came up with someone @jdoerfert worked with and I figured it was easy to implement. There is a precedent for -march to be case sensitive, I'm not sure if it's an issue here since it's a little arbitrary. Alternatively we could make it a warning.

I am not sure whether it is a good idea to allow gfx90A in --offload-arch, since it is not documented in LLVM AMDGPU usage. @b-sumner @arsenm

I don't really have an opinion here. I'd probably lean towards a "did you mean" kind of warning

I don't particularly see a need for this. I am not opposed to a "did you mean" in the error diagnostic.

Also, we may want to use uppercase for other purposes in the future.

First, as noted, I asked @jhuber6 to update this.

Is that really something we need/want to do? I've never seen anyone complaining about this particular issue.

I have, and not only once. Hence the request for a change.

clang/gcc are case-sensitive for similar options, like -march: https://godbolt.org/z/3jKzTda7h
I think offloading options should behave consistently in that regard. If we do want to make arch/CPU names case-agnostic, it should be done for all such options.

I don't disagree. Major difference is though that march returns a nice list of options in your example.
For offload-arch the situations is less user friendly: https://godbolt.org/z/oWYvvjTTq

Also, we may want to use uppercase for other purposes in the future.

gfx90a != gfx90A but both valid? Please, no.

I am not sure whether it is a good idea to allow gfx90A in --offload-arch, since it is not documented in LLVM AMDGPU usage. @b-sumner @arsenm

I'm not sure which documentation you mean but if it's https://llvm.org/docs/AMDGPUUsage.html, then I doubt any "end user" will have read it.
Arguably it's for compiler writers and not even in the frontend documentation. Maybe there is something else I don't know about?

I don't really have an opinion here. I'd probably lean towards a "did you mean" kind of warning

Since listing all options might not be great, I agree that we could emit a warning for upper/lower case situations instead. (FWIW, not only for amdgpu btw.)
@tra, would that be OK for you?

arsenm resigned from this revision.Nov 16 2022, 3:07 PM