[cfe-dev] RFC: Clang driver redesign

Ruben Van Boxem vanboxem.ruben at gmail.com
Fri Nov 4 16:17:49 PDT 2011


Op 4 nov. 2011 23:55 schreef "Eric Christopher" <echristo at apple.com> het
volgende:
>>
>>
>> > Then the port is broken. You shouldn't need a compiler option for this.
>>
>> Agreed, but that doesn't take away there will always be wanted and
controlled cases where these types of things are required. It would only
limit Clang's power by removing that compiler option interface. And there
will always be compiler bugs, that could be effectively worked around by
using these kinds of options.
>
> Did you file a bug? Did you fix the bad behavior? Or did you just look
for an undocumented option that would work around it and have left that in?
Even if you did the right thing most users won't. Supporting and
maintaining those sorts of behaviors with explicit command line options is
exactly why those kinds of options shouldn't exist.
>
> A generic interface for short term fixes (perhaps a reason for the
plugins that James mentioned) might be OK, but the general driver should
expose as little of the backend as possible.

OK, workarounds are a bad reason.

The optimizer will not always make the best decisions, especially in
situations where numerical data is processed that is unknown at compile
time. Backend inlining  options can improve performance if the user knows
what to optimize for. I agree there's most probably a lot of mucky options,
but sometimes fine-grained control beyond what the backend itself can
provide, is very wanted, if not necessary.

All I'm trying to say is a (too) dumbed down interface can be harmful (to
adoption, usefulness, adaptability, research...) as much as too many
obscure options can lead to misuse.

Ruben

PS: the stack size option was for the linker, making it a bit irrelevant in
light of the current discussion, I wrongfully picked it up from a previous
message.

>
> -eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111105/cba72ac4/attachment.html>


More information about the cfe-dev mailing list