On Nov 22, 2013, at 1:39 PM, Renato Golin <[email protected]> wrote:
> On 22 November 2013 21:29, Jim Grosbach <[email protected]> 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..
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
