[PATCH] Refactor duplicate functions

[Jim Grosbach]

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

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

I think this is conflating -arch arguments, which specify the MachO cpu subtype field and imply a default CPU value, with the arguments to -march= which are (currently) somewhat undefined. Having -march= also accept those shorthand designations might be friendly, but I don’t believe it’s necessary, at least on Darwin. “-arch” and “-march” have very different purposes.

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

Yeah. It’s a long road, and also raises the typical questions of just how much GCC command line compatibility is worth, etc..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131122/f3ffa90e/attachment.html>