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
runtime: Handle auxv data for ppc64 and ppc64le #16643
Comments
I'll submit a change shortly to add this. |
CC @laboger |
So we still don't want to add a runtime/cpu for runtime cpu feature
detection? I remember I filled a bug for that. At least arm and PPC don't
provide user level instructions to query available cpu features. And using
cpuid on x86 means the program has to use assembly.
|
Are you referring to #15403? I don't believe I had seen this proposal before. Sounds like it is doing the same thing as this but in a more general way. |
Ah... it seems I missed that issue. Thanks, @laboger @minux 's proposal is more generic than what I have. My idea was to create a 'runtime/os_linux_ppc64x.go' file and implement archauxv() to read from HWCAP/HWCAP2, then implement a function that does the check. I'm fine with either proposal, so I'll wait and see the opinions of others before submitting any changes. |
Yeah, my proposal is an internal package, but what I really want is to
export that package.
I think the internal package proposal is not controversial and will help
reducing duplicated cpu feature detection code.
|
@minux good, I also prefer not duplicating code. Are you already working on this? Btw, I don't think the functions for checking capabilities need to be necessarily internal. We could export those in a similar way gcc does with __builtin_cpu_is() / __builtin_cpu_supports(). Just an idea. |
The purpose of this check is to be able to tell when altivec is available. If the change for altivec breaks ppc64 BE we need this check, either the way Carlos has proposed it or Minux' proposal in order to determine it. |
@laboger this proposal moved forward in thread #15403. @mundaym suggested that I add (hackily) some simple mechanism for now and then clean it up later when the proposed package is in place. I was thinking about something trivial, like ceseo/go@ca09310. If no one objects, I can submit that quickly. |
Btw, the check is needed for POWER5 and POWER5+ (big endian), since neither have Altivec capability. PPC970, POWER6 and beyond are good. |
This implements a check that can be done at runtime for the ISA level and hardware capability. It follows the same implementation as in s390x. Updates golang#15403 Fixes golang#16643
This implements a check that can be done at runtime for the ISA level and hardware capability. It follows the same implementation as in s390x. Updates golang#15403 Fixes golang#16643
This implements a check that can be done at runtime for the ISA level and hardware capability. It follows the same implementation as in s390x. Updates golang#15403 Fixes golang#16643
CL https://golang.org/cl/32330 mentions this issue. |
Please answer these questions before submitting your issue. Thanks!
go version
)?go1.7rc6
go env
)?linux/ppc64le and linux/ppc64
N/A
N/A
ppc64/ppc64le lacks runtime checks for hardware capabilities / ISA levels. These will be important as we start to add runtime optimizations for POWER8/POWER9, so they don't break compatibility with older processors. We will need to read the HWCAP/HWCAP2 values from the auxv for this verification.
The text was updated successfully, but these errors were encountered: