I think this may have come across as more of a proposal than I intended, I
really want to gather information such that I can propose an appropriate
patch on list. (As it stood the patch I would have proposed would have
simply removed 7s/7k/7f since I did not know others requirements properly,
and I felt that creating such a patch would be wasted effort since I
expected such a patch to get rejected).
I'll step back from what I wrote previously and try to explain exactly what
I'm trying to achieve.
Currently the LLVM backend has the following CPU -> feature mappings:
cortex-a9 -> A9
cortex-a9-mp -> A9 + MP
swift -> swift + MP
cortex-a15 -> A15 + MP
cortex-a53 -> A53 + MP
cortex-a57 -> A57 + MP
A9 is the odd one out here in that it enables MP via a separate CPU name
rather than by default, my aim is to make this consistent across LLVM/Clang.
The sensible way to address this it seems is to remove cortex-a9-mp
altogether and enable MP by default on cortex-a9 (and also add MP to all
other relevant cores as a default feature).
* Do you have any expectation that users will need the CPU name cortex-a9-mp
If not, the next step is to make the frontend consistent with this, that is,
remove cortex-a9-mp and inherit the fact that cortex-a9 provides MP.
* Similarly, do you expect users to need cortex-a9-mp in Clang?
Even if not, this presents a problem, Clang has the following CPU ->
cortex-a9 -> armv7a
cortex-a9-mp -> armv7f
If we were to simply remove cortex-a9-mp then there would no longer be any
CPU that mapped to the armv7f architecture, which I assume would be a
problem for users? The naive answer is to remove v7f and pass the CPUSubType
information it provides to the backend in a different manner, however as you
have stated this is not an option due to needing to keep -arch armv7f etc.
Another approach is to not have these architectures as real architectures in
the LLVM sense, and instead introduce a CPUSubType option (or something like
this) to LLVM. The CPU cortex-a9 could then always map to v7a and in some
separate logic Clang could figure out a CPUSubType in addition. That way we
get the benefits of the naive approach, yet preserve the -arch options. This
could result in something like the following mappings:
-march=v7f -> -march=v7a + v7f-CPUSubType
-mcpu=cortex-a9 -> -mcpu=cortex-a9 + v7f-CPUSubType (-march=v7a).
This could also be OS/driver agnostic, since the backend can simply ignore
the CPUSubType if it doesn't care, or instead clang could only generate and
pass it for a relevant OS. However this approach would remove v7f as an
architecture from LLVM, would this be an issue?
Are the v7f/v7k/v7s architectures only relevant for Darwin/iOS targets? If
so, another approach could be to move these architectures such that they are
only accepted for such targets? In which case, cortex-a9 would map to v7f
for Darwin/iOS and would map to v7a elsewhere. Would such a change be too
confusing for users?
If none of these approaches work could you explain what your requirements
are for these architectures (and cortex-a9-mp if relevant), so that I can
come up with a solution that might work? Thanks.