[PATCH] Refactor duplicate functions

[Renato Golin]

On 22 November 2013 21:29, Jim Grosbach <grosbach at apple.com> wrote:

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

I like -fred. ;)

Now seriously, I agree this is the issue, and as Eric said, we ought to be
doing this already.

I personally dislike v7K, v7F etc. because that tells me nothing about the
underlying architecture and can be confusing to remember all letters, not
to mention conflicts. If I could chose, I'd say something like v7A-F,
v7A-8, v7A-9, v7A-15, v7A-S, etc. I don't think it's a secret that some
Apple/Qualcomm CPUs are v7A or v8, at least not at the time of launch, so
this shouldn't hurt marketing or legal folks too bad. Well, at least
nothing more than what "v7S" already gives away.

What they mean can easily alias in the implementation level
(ToolChains.cpp) but it has to be clear to the user what they mean. We
should have all current behaviour mapped into the new scheme (whatever is
it), possibly in a separate file with a big warning "Here Be Dragons!", so
that people know with what they're messing about.


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

This may break build systems that are still expecting GCC behaviour. I
think warnings would be good until we convince GCC folks that this is
madness and they also add the warnings. 2 years ago, this phrase would
provoke laugh from everyone in this mailing list, but recently I think we
got a lot closer than we would like to admit. It should not be hard to
convince people that a clearly bad design is bad, but will take *a lot* of
time for them to convince their hardcore users to adopt the new design.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131122/116b5997/attachment.html>