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

[Puyan Lotfi]

On Oct 4, 2013, at 10:28 AM, Chandler Carruth <chandlerc at google.com> wrote:

> Since Reid pointed me at this thread, I thought I would provide some hopefully useful ideas.
> 
> First, a clarification: we have a large number of users that are parsing command line options with LLVM used as a library. They have requirements to not leak memory in addition to not having a good way to persist the strings being parsed. I'm very opposed to any direction which assumes that the parsed flags are memory managed externally to LLVM because it isn't true today and would regress a large amount of customer code.
> 
> It feels like there is a reasonably simple, reasonably clear strategy here:
> 
> 1) flags don't own their memory, and point at a global constant on construction
> 2) parsing flags allocates memory for new values (preferably on LLVMContext), and sets the flags to point at these new things
> 3) when shutting down an LLVMContext, we reset the flags to their global constants
> 

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. 

> Without doing something to take ownership of the memory when parsing flags, this change will break a very large number of users of LLVM, so I don't think there is going to be a significantly simpler solution here.
> 

I think this could work. Do you think a persistent uniquing string pool (StringMap of char*’s) in LLVMContext would be in order?  

> The only thing seriously broken about the above is that users of LLVMContext in multiple threads cannot parse commandline flags. That's already true though, so I don't worry about *this* breaking existing users.


Thanks

-Puyan