Skip to content
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

configure: fix --cpu=host for Intel Celeron and Pentium #507

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

ulmus-scott
Copy link
Contributor

class processors.

This is necessary because they don't support AVX, but e.g. gcc's
-march=haswell enables AVX instructions; however, the Haswell
Pentium G3258 does not support AVX, which -march=native correctly
selects.

cpu cannot be set to native, since then the conditional checks,
for e.g. fast cmov, are not executed.

This should fix #505 in master and can be cherry-picked cleanly into fixes/31 and fixes/31.

class processors.

This is necessary because they don't support AVX, but e.g. gcc's
-march=haswell enables AVX instructions; however, the Haswell
Pentium G3258 does not support AVX, which -march=native correctly
selects.

cpu cannot be set to native, since then the conditional checks,
for e.g. fast cmov, are not executed.
@pcrow
Copy link

pcrow commented Feb 27, 2022

Executive summary: It looks good for me.

Details:

I saved the patch to /etc/portage/patches/media-tv/mythtv and emerged mythtv-31.0_p20210731. [This is a Gentoo-ism for applying patches during a build while continuing to use the package management system.] I'm compiling on a Haswell Celeron. The configuration set HAVE_LRINT correctly (the first symptom of the problem encountered). Running 'ps' during the build, I see -march=native on the gcc command lines, but on the cc1 command lines, I see -march=haswell, but then with tons of explicit flags including -mno-avx, so I think this is just exposing some irrelevant gcc internals, and it's doing the right thing. I didn't do any further code testing, but it appears to me that it solves the problem. (I also didn't closely examine the code changes.)

Doing a grep -r haswell in the build tree while running, I do notice:

mythtv/libs/libmythbase/moc/moc_predefs.h:#define __tune_haswell__ 1
mythtv/libs/libmythbase/moc/moc_predefs.h:#define __haswell__ 1
mythtv/libs/libmythui/moc/moc_predefs.h:#define __tune_haswell__ 1
mythtv/libs/libmythui/moc/moc_predefs.h:#define __haswell__ 1
mythtv/libs/libmythservicecontracts/moc/moc_predefs.h:#define __tune_haswell__ 1
mythtv/libs/libmythservicecontracts/moc/moc_predefs.h:#define __haswell__ 1

(More show up as the build progresses.) I don't see anywhere where those defines are used unless I'm missing something, so I assume it's harmless.

@ulmus-scott
Copy link
Contributor Author

Running 'ps' during the build, I see -march=native on the gcc command lines, but on the cc1 command lines, I see -march=haswell, but then with tons of explicit flags including -mno-avx, so I think this is just exposing some irrelevant gcc internals, and it's doing the right thing.

I suspect this has to do with how -march=native probably works: the gcc program converts it to options for cc1 which itself knows nothing about -march=native.

Doing a grep -r haswell in the build tree while running, I do notice:

mythtv/libs/libmythbase/moc/moc_predefs.h:#define __tune_haswell__ 1
mythtv/libs/libmythbase/moc/moc_predefs.h:#define __haswell__ 1
mythtv/libs/libmythui/moc/moc_predefs.h:#define __tune_haswell__ 1
mythtv/libs/libmythui/moc/moc_predefs.h:#define __haswell__ 1
mythtv/libs/libmythservicecontracts/moc/moc_predefs.h:#define __tune_haswell__ 1
mythtv/libs/libmythservicecontracts/moc/moc_predefs.h:#define __haswell__ 1

(More show up as the build progresses.) I don't see anywhere where those defines are used unless I'm missing something, so I assume it's harmless.

moc is the Qt Meta-Object Compiler, so that is probably fine.

For GCC:
x86: "Using -mtune=native produces code optimized for the local
machine under the constraints of the selected instruction set."

AArch64: "Additionally on native AArch64 GNU/Linux systems the value
‘native’ tunes performance to the host system. This option has no
effect if the compiler is unable to recognize the processor of the
host system."

Similar for other architectures.

Note: this is equivalent to -mcpu=native for architectures that support
that option; notably, for x86, -mcpu is a deprecated synonym of -mtune.
However, on x86, -march implies -mtune in this and most cases.

For clang: from its command line reference for -mtune=<arg>:
"Only supported on X86 and RISC-V. Otherwise accepted for compatibility
with GCC."
@ulmus-scott
Copy link
Contributor Author

I added another commit to set -mtune=native for equivalent behavior on non-x86 architectures.

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

Successfully merging this pull request may close these issues.

Fail to build for armhf
2 participants