<div dir="ltr"><br><br><div class="gmail_quote">On Thu, Mar 19, 2015 at 11:12 AM Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Having the analogous of -O0/-O1/-O2/-O3 for the LTO pipeline makes<br>
sense I think.<br>
<br>
I agree that something along option number 2 is probably the best.<br>
Some questions:<br>
<br>
* Should "clang -O3 foo.o -o foo" use LTO with -O3?<br>
* Should "clang foo.o -o foo" use LTO with -O0? That would be a fairly<br>
big change. Maybe we could make the LTO default be 3?<br>
* Should we just add a --ltoO to the clang driver that is independent of -O?<br>
* Some linkers already take a -O(1,2,3) option. Should we try to<br>
forward that or should we differentiate LTO optimizations and general<br>
linker optimizations?<br>
<br></blockquote><div><br></div><div>The linker taking -O1,2,3 as a start is fine for sure. I'd rather this go from a clang driving everything perspective than a linker driving everything, but that ship may have sailed.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If we want to differentiate linker and LTO optimizations, adding a -O<br>
plugin option to the gold plugin should be fine. As Bob points out,<br>
for ld64 for now we would just use -mllvm.<br></blockquote><div><br></div><div>Sure. A better command line interface similar to the one that we already have in clang to deal with enabling/disabling passes (or, perhaps, one that's even better - we're not very good at that at the moment) would be ultimately a good place to be. Otherwise the interface is just going to be some sort of special case hell for what everyone wants to do at the LTO level.</div><div><br></div><div>-eric</div></div></div>