r231787 - Allow -target= and --target options

Chandler Carruth chandlerc at google.com
Thu Mar 12 04:19:58 PDT 2015


On Thu, Mar 12, 2015 at 4:13 AM, Renato Golin <renato.golin at linaro.org>
wrote:

> So, does "compatibility" means "only the ones that other tools have
> specifically" (such as -mcpu), or "similar to what other tools have"
> (such as -target)?
>

Similarity does not mean compatibility to me.

When trying to be drop-in compatible, we need only care about the actual
flags supported by actual tools.


>
> If the former, than I suggest we use the compatibility layer to
> convert "legacy" options into standard ones. So, "--target=foo",
> "--mcpu=bar" are the standard and "-target foo" and "-mcpu=bar" are
> accepted as legacy options.
>

I think this is much more rigid than what we actually need.

We don't need to try to define a nice new name for every flags that exists.
Many of them are only used infrequently or just don't merit trying to
invent nice new syntax. Specifying a specific CPU variant might be one of
the few that does merit it, but I'm not super keen to rush and paint that
bikeshed today. Until we need to re-paint the bikeshed away from
compatibility options, the compatibility options seem fine when they exist.
The place we *need* to pick a consistent syntax is when we're adding
specific new flags. '-target' is just an *old* spelling of this flag, which
is somewhat different from the the general long-lived compatibility we
maintain with GCC, etc.

I also don't think we need to over-engineer *how* we translate back and
forth between these things. If someone is highly motivated to build us a
nice set of abstractions here baked into the tablegen stuff, fantastic. But
I don't think the current state is that bad either.


> If the latter, than accepting all options for all choices is the only
> way to keep everyone happy.
>

This just results in a confusing pile of code. I think we can and must do
better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150312/c5a6b4a1/attachment.html>


More information about the cfe-commits mailing list