<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 4, 2011, at 2:55 PM, Ruben Van Boxem wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><p>Op 4 nov. 2011 21:51 schreef "Eric Christopher" <<a href="mailto:echristo@apple.com">echristo@apple.com</a>> het volgende:<br>
><br>
><br>
> On Nov 4, 2011, at 1:08 PM, Matthieu Monrocq wrote:<br>
><br>
>> This would also allow implementing a *sane* option syntax, like for example a hierarchical option parser:<br>
>><br>
>> --codegen-stackframe-limit=50<br>
>><br>
>> Where "stackframe-limit=50" is dispatched to the "codegen" plugin, which itself dispatch "limit=50kB" to its stackframe object, which sets its "limit" attribute to 50000 (for example).<br>
><br>
><br>
> There's one particular set of use cases that this brings up that I'd like to mention: <br>
><br>
> "Less knobs for users to use"<br>
><br>
> I realize it's an example, and a good way of describing a partial way of evaluation options, however, the idea behind this option in particular is something I explicitly don't want to do. I believe we want less knobs, not more. We don't want the users mucking with things like inlining heuristics, the size of the stack, and whether they want to unroll 4 loops or 3. These are the kinds of decisions that the optimizer should be able to handle and people working on the compiler have their own ways of mucking with these sorts of options.</p><p>Wrong; to successfully build the cellspu tblgen files on windows x64, one had to increase stack size for tblgen not to crash. I'm quite certain this use case is far from unique. I do agree hiding low level options casual users shouldn't know about (although they should be well documented), but not having it is really shooting yourself in the foot..</p><div><br></div></blockquote>Then the port is broken. You shouldn't need a compiler option for this.</div><div><br></div><div>-eric</div><br></body></html>