<p>Op 4 nov. 2011 23:55 schreef "Eric Christopher" <<a href="mailto:echristo@apple.com">echristo@apple.com</a>> het volgende:<br>
>><br>
>><br>
>> > Then the port is broken. You shouldn't need a compiler option for this.<br>
>><br>
>> 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.<br>

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

><br>
> 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.</p>
<p>OK, workarounds are a bad reason.</p>
<p>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.</p>

<p>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.</p>
<p>Ruben</p>
<p>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.</p>
<p>><br>
> -eric</p>