On Thu, Mar 12, 2015 at 4:13 AM, Renato Golin <[email protected]> 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
