Skip to content

[compiler-rt][X86] Unify getIntelProcessorTypeAndSubtype #97861

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
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

boomanaiden154
Copy link
Contributor

This patch unifies getIntelProcessorTypeAndSubtype between LLVM and compiler-rt as there is a reasonable amount of divergence between the two implementations.

This patch is one step in refactoring out several blocks of code in these two files to identical .inc files that can be tested that they are the same to better facilitate code sharing between LLVM and compiler-rt.

This patch unifies getIntelProcessorTypeAndSubtype between LLVM and
compiler-rt as there is a reasonable amount of divergence between the
two implementations.

This patch is one step in refactoring out several blocks of code in
these two files to identical .inc files that can be tested that they are
the same to better facilitate code sharing between LLVM and compiler-rt.
Copy link

github-actions bot commented Jul 5, 2024

✅ With the latest revision this PR passed the C/C++ code formatter.

@@ -512,15 +523,15 @@ static const char *getIntelProcessorTypeAndSubtype(unsigned Family,
// Alderlake:
case 0x97:
case 0x9a:
// Gracemont:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is 0xbe moved above?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's how it was on the LLVM side, and I figured moving it into alphabetical order by codename made more sense than sticking it at the end.

No real preference here though. The only thing I'm trying to get is consistency between the two implementations.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@FreddyLeaf where's the Gracemont model from? I didn't find it in ISE. Besides, the Gracemont is not CPU name but microarchitecture name.

@boomanaiden154
Copy link
Contributor Author

Bump on this when reviewers have a chance. Thanks!

@@ -646,10 +657,102 @@ static const char *getIntelProcessorTypeAndSubtype(unsigned Family,
*Type = INTEL_KNM;
break;

default: // Unknown family 6 CPU.
default: // Unknown family 6 CPU, try to guess.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recall I saw discussion somewhere says it's not proved returning a guessed CPU is better than unknown one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you have a link? Should we remove this then? This just unifies the implementations, so if we shouldn't guess, then we should remove it from the LLVM implementation.

More than happy to put up a patch for that if that's what is desired.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I can't find it. I'm even not quite sure of it. I think we can put both way in an RFC and see others' opinion. Do you know the behavior of libgcc? It would be a good reference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants