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

[Bradley Smith]

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
>