When targeting cortex-a53, set this linker flag rather than relying
on the toolchain users to do it in their build.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/Driver/ToolChains/Fuchsia.cpp | ||
---|---|---|
91 | How does this relate to -march, -mtune, and/or -mcpu? |
clang/lib/Driver/ToolChains/Fuchsia.cpp | ||
---|---|---|
91 | This is the same logic as used by the Gnu driver. getCPUName only considers -mcpu, it ignores -march and -mtune as far as I can tell. |
clang/lib/Driver/ToolChains/Fuchsia.cpp | ||
---|---|---|
91 | If the empty or "generic" case is what will apply when no -mcpu switch is given regardless of -march then I guess this is adequate since we're not really concerned with any architectures older than A53 where someone might use -mcpu=... as a proxy for "X and later" where X<A53. I think this area needs to be more clearly specified and documented eventually, however. Ideally the determinant would whether the combination of -march and/or -mcpu switches indicates generating code that is compatible with an A53 CPU, since only if running on an A53 is ruled out should we omit the erratum workaround. |
How does this relate to -march, -mtune, and/or -mcpu?
It's not at all clear to me how we discern automatically when a A53 might be included in the supported target CPU set. I'm not entirely sure we should have automatic injection in some cases where A53 is a valid target but not all. That is, if some compiler option combinations that produce code meant to be compatible with an A53 won't automatically get the --fix option, then perhaps it's better to require the explicit --fix option when supporting A53 is the explicit intent.