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

[Evan Cheng]

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

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
>> 
> 
> 
>