[PATCH] Allow for the use of StringRef command line options instead of cl::opt<std::string>

Chandler Carruth chandlerc at google.com
Fri Oct 4 10:55:24 PDT 2013

On Fri, Oct 4, 2013 at 1:52 PM, Puyan Lotfi <plotfi at apple.com> wrote:

> On Oct 4, 2013, at 10:43 AM, Chandler Carruth <chandlerc at google.com>
> wrote:
> On Fri, Oct 4, 2013 at 1:39 PM, Puyan Lotfi <plotfi at apple.com> wrote:
>> I like this solution but do you think there should be some way to tell
>> the library (optional parameter, or a separate API function) to use the
>> argv data directly instead of allocating memory on the context. Seems like
>> it would be good to not hurt performance of the common case.
> I don't think there is a common case where performance is a concern. Why?
> 1) We're parsing commandline flags in an inherently race-prone way, and
> for flags which are explicitly for debugging and custom manipulations only.
> 2) It can only happen once per LLVMContext spin up / tear down
> I mean the common case where ParseCommandLineOptions is being called from
> main and being passed argv directly. Wouldn’t it be better to not allocate
> duplicates inside LLVMContext in this case? But yeah, otherwise I like the
> idea of putting strings into LLVMContext.

The question to ask here is what problem does it solve.

If it is being called from main, it will be called exactly once per
execution. That means that it will do at most a number of allocations
corresponding to the number of command line arguments passed to the binary.
I think that malloc overhead is not worth *any* complexity in the system,
and certainly not a bug-prone interface.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131004/6a21dbdb/attachment.html>

More information about the llvm-commits mailing list