[PATCH] Add support for a directory argument to llvm-link

[Sean Silva]

On Mon, Mar 31, 2014 at 3:25 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> > For feeding a large number of bitcode files to llvm-link (especially
> without
> > worrying about command-line length and/or response file escaping).
>
> When do you do that as part of regular development?
>

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.


>
> >> > Besides, making the tool easier to use is not a concession that it
> >> > should be
> >> > used for production purposes or is supported for production purposes;
> >> > it's
> >> > just that: making the tool easier to use. Think about it this way: if
> >> > llvm-link were originally written with this behavior, would you be
> dying
> >> > to
> >> > rip that functionality out?
> >>
> >> Would not be the top of my priorities. But it is not in trunk, so the
> >> burden is on the other side to show that this is a useful thing to
> >> have in a development environment.
> >
> >
> > Agreed. I think the experience last Summer fulfills that burden of proof
> and
> > demonstrates that this feature would be handy to have.
> >
>
> No, it doesn't. Quiet the opposite. Having a feature that makes it
> easier to use llvm-mc in production is undesirable.
>

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.

These prototypes are not alien to upstream development. Prototypes feed
back experience that informs upstream development and allocation of
development effort.

-- Sean Silva


>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140401/96374ea3/attachment.html>