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

Flang should handle the -mtune option #84947

Closed
tukss opened this issue Mar 12, 2024 · 9 comments
Closed

Flang should handle the -mtune option #84947

tukss opened this issue Mar 12, 2024 · 9 comments

Comments

@tukss
Copy link

tukss commented Mar 12, 2024

flang-new already knows about the -march option but not about -mtune. clang (and also gcc/gfortran) handles both options. For context, -mtune produces code that's optimized for a certain subarchitecture (say haswell or zen3) while retaining compatibility with other subarchitectures, whereas -march might produce illegal instructions when run on the wrong hardware.

My reason for asking is that is makes it hard to use flang-new within Spack. Spack handles flang-new as the Fortran component of the clang compiler but unfortunately doesn't provide a way to specify different compiler flags for the C, C++, and Fortran compilers. -mtune is used as an option for most architectures (e.g., here), which breaks using flang-new to build anything with Spack.

Even if -mtune wasn't implemented immediately it would at least be helpful if flang-new wouldn't just stop compilation but just display a warning and continue.

@github-actions github-actions bot added the flang Flang issues not falling into any other category label Mar 12, 2024
@AlexisPerry AlexisPerry self-assigned this Mar 12, 2024
@AlexisPerry
Copy link
Contributor

PR for basic mtune support: #95043

@EugeneZelenko EugeneZelenko added flang:driver flang:ir and removed flang Flang issues not falling into any other category labels Jun 25, 2024
@llvmbot
Copy link
Collaborator

llvmbot commented Jun 25, 2024

@llvm/issue-subscribers-flang-driver

Author: Philipp Edelmann (tukss)

`flang-new` already knows about the `-march` option but not about `-mtune`. `clang` (and also `gcc`/`gfortran`) handles both options. For context, `-mtune` produces code that's optimized for a certain subarchitecture (say `haswell` or `zen3`) while retaining compatibility with other subarchitectures, whereas `-march` might produce illegal instructions when run on the wrong hardware.

My reason for asking is that is makes it hard to use flang-new within Spack. Spack handles flang-new as the Fortran component of the clang compiler but unfortunately doesn't provide a way to specify different compiler flags for the C, C++, and Fortran compilers. -mtune is used as an option for most architectures (e.g., here), which breaks using flang-new to build anything with Spack.

Even if -mtune wasn't implemented immediately it would at least be helpful if flang-new wouldn't just stop compilation but just display a warning and continue.

@llvmbot
Copy link
Collaborator

llvmbot commented Jun 25, 2024

@llvm/issue-subscribers-flang-ir

Author: Philipp Edelmann (tukss)

`flang-new` already knows about the `-march` option but not about `-mtune`. `clang` (and also `gcc`/`gfortran`) handles both options. For context, `-mtune` produces code that's optimized for a certain subarchitecture (say `haswell` or `zen3`) while retaining compatibility with other subarchitectures, whereas `-march` might produce illegal instructions when run on the wrong hardware.

My reason for asking is that is makes it hard to use flang-new within Spack. Spack handles flang-new as the Fortran component of the clang compiler but unfortunately doesn't provide a way to specify different compiler flags for the C, C++, and Fortran compilers. -mtune is used as an option for most architectures (e.g., here), which breaks using flang-new to build anything with Spack.

Even if -mtune wasn't implemented immediately it would at least be helpful if flang-new wouldn't just stop compilation but just display a warning and continue.

@banach-space
Copy link
Contributor

@AlexisPerry , thanks for working on this! Given that #95043 has landed, can we close this ticket?

@tukss
Copy link
Author

tukss commented Jun 26, 2024

I was just about to test it but then I've seen it has been reverted in #96678.
So I guess we leave this open for now.

@AlexisPerry
Copy link
Contributor

#95043 was reverted. A fixed version of the patch has been posted: #96688

@AlexisPerry
Copy link
Contributor

PR #98517 has been merged. @tukss Could you check to see if the issue still persists? Thank you.

@llvmbot
Copy link
Collaborator

llvmbot commented Jul 16, 2024

@llvm/issue-subscribers-flang-frontend

Author: Philipp Edelmann (tukss)

`flang-new` already knows about the `-march` option but not about `-mtune`. `clang` (and also `gcc`/`gfortran`) handles both options. For context, `-mtune` produces code that's optimized for a certain subarchitecture (say `haswell` or `zen3`) while retaining compatibility with other subarchitectures, whereas `-march` might produce illegal instructions when run on the wrong hardware.

My reason for asking is that is makes it hard to use flang-new within Spack. Spack handles flang-new as the Fortran component of the clang compiler but unfortunately doesn't provide a way to specify different compiler flags for the C, C++, and Fortran compilers. -mtune is used as an option for most architectures (e.g., here), which breaks using flang-new to build anything with Spack.

Even if -mtune wasn't implemented immediately it would at least be helpful if flang-new wouldn't just stop compilation but just display a warning and continue.

@tukss
Copy link
Author

tukss commented Jul 23, 2024

Yes, the option works fine for me on the current main branch. I can't speak to how much of an optimization benefit this brings but I mainly care about flang-new accepting the option for things like spack. That works great now. Thank you!

@tukss tukss closed this as completed Jul 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants