-
Notifications
You must be signed in to change notification settings - Fork 13.5k
[LLVM][Triple] Drop unknown object types from normalized triples #135571
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
UsmanNadeem
wants to merge
1
commit into
llvm:main
Choose a base branch
from
UsmanNadeem:triplebug
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+48
−68
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the rest of the changes is fine, but this doesn't look right to me, especially looking at
parseEnvironment
, they are not the same. I agree that the object format is treated as part of the environment, but that doesn't mean thatunknown-elf
iself
. Also, I thinkunknown
environment will yieldUnknownEnvironment
, based onparseEnvironment
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
parseEnvironment("elf")
will also yieldUnknownEnvironment
though.Before this patch the following command
clang -### --target=aarch64-pc-linux--elf
orclang -### --target=aarch64-pc-linux--elf
gives an error due to bug in version parsing but the resultant triple is:Target: aarch64-pc-linux-elf-unknown
which seems wrong.After this patch we get:
Target: aarch64-pc-linux-elf
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
which is wrong right? We need to treat the root cause not the symptoms. Even if we take format as part of environment,
aarch64-pc-linux--elf
should also be a valid one, since-elf
means the environment part is empty, andelf
is the format part. We should not treataarch64-pc-linux--elf
asaarch64-pc-linux-elf-unknown
. Instead, we should fix it such that it would be treated asaarch64-pc-linux-unknown-elf
instead ofaarch64-pc-linux-elf
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your explanation makes sense to me but the problem is that goes against current toolchain expectations and will cause clang to not find libraries for some targets, e.g. some baremetal toolchains use triples like
aarch64-none-elf
andriscv64-unknown-elf
.These would normally be canonicalized to
aarch64-unknown-none-elf
andriscv-unknown-unknown-elf
. Adding an extraunknown
to account for the missing environment will break things.Also, if you also look at some of the code in
Baremetal.cpp
they check forTriple.getEnvironmentName() == "elf"
, seems like both "elf" and "unknown-elf" should be synonymous.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean, their code is also part of LLVM code base such that they can be updated as well right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added more reviewers to get additional opinion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For context on five-part triples, see f80b49b / 3547633 / feb805f . Five-part triples are not commonly used for anything; it was just implemented that way because it was convenient at the time for the JIT. (So, for example, msvc-elf is a variant of the msvc environment, but using ELF object files.)
Everyone else wants nothing to do with five-part triples. "-elf" is just a generic baremetal ELF environment not tied to any particular operating system or libraries. Similar for "-coff" etc.
Changing the canonical form of "aarch64-pc-linux-elf" to "aarch64-pc-linux-unknown-elf" seems like it's making a lot of work without any real benefit.