<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 31, 2014 at 3:25 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> For feeding a large number of bitcode files to llvm-link (especially without<br>
> worrying about command-line length and/or response file escaping).<br>
<br>
</div>When do you do that as part of regular development?<br></blockquote><div><br></div><div>For example, when creating large bitcode files from entire projects (e.g. for analysis of llvm optimizations or performance testing (of llvm libs), or just for stress testing). Until LLD rules the world and has turnkey LTO and an emit-bitcode option (a while yet), there will be a need for flexibly linking a ton of bitcode modules.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
>> > Besides, making the tool easier to use is not a concession that it<br>
>> > should be<br>
>> > used for production purposes or is supported for production purposes;<br>
>> > it's<br>
>> > just that: making the tool easier to use. Think about it this way: if<br>
>> > llvm-link were originally written with this behavior, would you be dying<br>
>> > to<br>
>> > rip that functionality out?<br>
>><br>
>> Would not be the top of my priorities. But it is not in trunk, so the<br>
>> burden is on the other side to show that this is a useful thing to<br>
>> have in a development environment.<br>
><br>
><br>
> Agreed. I think the experience last Summer fulfills that burden of proof and<br>
> demonstrates that this feature would be handy to have.<br>
><br>
<br>
</div>No, it doesn't. Quiet the opposite. Having a feature that makes it<br>
easier to use llvm-mc in production is undesirable.<br></blockquote><div><br></div><div>There's a big difference between a prototype for a product and going to production. Also, for prototypes being able to quickly pull things together and have them work is important and convenience of use is a big part of that.</div>
<div><br></div><div>These prototypes are not alien to upstream development. Prototypes feed back experience that informs upstream development and allocation of development effort.</div><div><br></div><div>-- Sean Silva</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>