On Nov 22, 2013, at 1:16 PM, Renato Golin <[email protected]> wrote:
> On 22 November 2013 19:55, Jim Grosbach <[email protected]> wrote:
> Using -march= and -mcpu= at the same time should probably be a hard error.
> -march is preferable and 32-bit ARM is the outlier for historical reasons in
> preferring -mcpu. I’d love to be able to change that, but it’s likely to be a
> hard road.
>
> The problem is that ARMv7A has very different CPU types (A8 vs. A9 vs. A15),
> so getting "armv7a" doesn't narrow it down well enough. For all the rest (M
> and R), it's ok to say "armv7r", "armv6m", "armv7m" (mostly by coincidence,
> not design).
>
> Some alternatives, such as "armv7l" or "armv7hl", don't specify the CPU,
> while "armv7s", "armv7k" or "armv7f" do, but it's not "v7a", which makes it
> even more cryptic. With all that confusion, I still prefer the good old -mcpu
> over -march every day.
>
> Also, I don't think that (march + mcpu) should be a hard error, unless your
> march can completely specify the CPU type, or at least, the optimization
> profile.
That’s exactly the goal model. It should be legal to use either a more generic
“armv7a” or a specific “cortex-a9” via the same command line option. There is
no need for two. As-is, you can specify nonsensical combinations like
-march=armv7a -mcpu=cortex-m0. There should be only one command line option
that is sufficiently flexible to specify the needs. I don’t really care whether
than option is spelled “-mcpu=“ “-march=“ or “-fred=“. It’s that we pick one
and stick with it that matters.
The tricky bit is how we get there from here. My first-pass thought is to make
-mcpu= and -march= synonyms in the driver and issue an error if both are used.
It may be necessary to start with a deprecation warning with a help note
indicating the preferred usage, then actually enforce via an error in a
following release.
-Jim
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
