[PATCH] Refactor duplicate functions

[Jim Grosbach]

On Nov 22, 2013, at 1:16 PM, Renato Golin <renato.golin at linaro.org> wrote:

> On 22 November 2013 19:55, Jim Grosbach <grosbach at apple.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131122/06d09925/attachment.html>