[cfe-dev] [ARM] Removing v7s/v7f/v7k and cortex-a9-mp

[Bob Wilson]

On Nov 10, 2013, at 7:18 PM, Evan Cheng <evan.cheng at apple.com> wrote:

> Ok, if your main concern is to get rid of the cortex-a9-mp cpu, then I would follow Renato's suggestion of just adding a -mattr=+mp option. I don't see a bigger change like you suggested below is worth it.
> 
> Evan

That would work, but it would be good to clean up this stuff a bit and I think Bradley is on the right track.

First off, the issue here is specifically v7f.  It has nothing to do with either v7s or v7k.  I will need to double check, but I’m not aware of any fundamental reason why we need to keep v7f around.  If we remove v7f, then I’m not aware of any reason to keep the cortex-a9-mp cpu.

> 
> On Nov 8, 2013, at 4:34 AM, Bradley Smith <bradley.smith at arm.com> wrote:
> 
>> Hi Evan,
>> 
>> 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
>> in LLVM?
>> 
>> 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 ->
>> architecture mappings:
>> 
>> 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.
>> 
>> Regards,
>> Bradley Smith
>> 
>>> -----Original Message-----
>>> From: Evan Cheng [mailto:evan.cheng at apple.com]
>>> Sent: 07 November 2013 17:54
>>> To: Bradley Smith
>>> Cc: cfe-dev at cs.uiuc.edu
>>> Subject: Re: [cfe-dev] [ARM] Removing v7s/v7f/v7k and cortex-a9-mp
>>> 
>>> Can you clarify what you are proposing? Are you proposing that we
>>> eliminate the option such as -arch armv7s? If so, the answer is no.
>>> This would impact a lot of users negatively.
>>> 
>>> If you are proposing changes to how the information is communicated
>>> between the frontend and backend, then the answer is maybe. You do need
>>> to provide a much more concrete proposal that will maintain the
>>> functionality.
>>> 
>>> Evan
>>> 
>>>> On Nov 7, 2013, at 5:15 AM, Bradley Smith <bradley.smith at arm.com>
>>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I'd like to propose making a change in the ARM backend such that the
>>> MP
>>>> extensions subtarget feature is enabled by default on all CPUs with
>>> this
>>>> extension, however this has an impact on various other areas of Clang
>>> and
>>>> LLVM.
>>>> 
>>>> Most notably, Clang has a CPU name, cortex-a9-mp, that should be
>>> gotten rid
>>>> of as part of this change since it will be redundant in terms of
>>> subtarget
>>>> features enabled, (it would be identical to cortex-a9). However
>>> currently,
>>>> this CPU name maps to an architecture of armv7f. This looks to be a
>>> pseudo
>>>> architecture that from what I can gather is only used for the
>>> CPUSubType
>>>> field in the Mach-O header.
>>>> 
>>>> In order to avoid keeping this cortex-a9-mp CPU around (since it will
>>> just
>>>> be a source of confusion), I would also like to propose removing
>>> these
>>>> Mach-O specific architectures from Clang (7f, 7s, 7k) and instead
>>> pass this
>>>> information through to LLVM in a different manner, perhaps by
>>> changing the
>>>> CPUSubType logic in the ARM backend to be based upon CPU rather than
>>> these
>>>> pseudo architectures, or by passing it by command line? (I'm guessing
>>> care
>>>> will need to be taken to avoid letting CPUs that don't map to a valid
>>>> CPUSubType get through?).
>>>> 
>>>> Both of these changes should make the Clang driver a bit more sane in
>>> these
>>>> areas, so I think these are both generally good changes to do. Does
>>> anybody
>>>> have any comments/objections to this? Specifically, am I right in
>>> thinking
>>>> that the Mach-O header is the only place these pseudo architectures
>>> are
>>>> being used? What would be the right approach for getting the
>>> CPUSubType
>>>> information through to LLVM?
>>>> 
>>>> Regards,
>>>> Bradley Smith
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>> 
>> 
>> 
>> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev