[LLVMdev] Using cl::ZeroOrMore more pervasively with the cl::opt class

[Chad Rosier]

Thanks for the feedback, Chris.  I tend to agree with you given your
reasoning.  I think disabling the warning is a reasonable solution for the
time being.

> Let me start by saying the NumOccurances flags are a particularly nasty
> bit of code that is on my list to clean up.
>
>> On Jan 23, 2015, at 1:24 PM, Chad Rosier <mcrosier at codeaurora.org>
>> wrote:
>>
>> All,
>> Is there any particular reason we don't use cl::ZeroOrMore more
>> pervasively with the cl::opt class of command-line options?
>>
>> 1. Some of llvm's optimizations are enabled/disabled by llvm
>> command-line
>> options.  Passing these options to our build system via CFF and CXXF
>> result in redundant CL options.  If the CL option is a cl::opt which
>> defaults to cl::Optional, a warning is emitted.  In turn, our build
>> system
>> bails on these type of warnings.
>
> I believe this is the correct behavior. Any cl::opt inherently can only
> have one value, which is why they are cl::Option. Values marked
> cl::ZeroOrMore are allowed to have more than one value. This is the
> default setting for cl::list and cl::bits. The problem with making cl::opt
> cl::ZeroOrMore is that if you pass a flag (say -unroll-threshold) more
> than once which value gets used? cl::opt options only have storage for a
> single value.
>
> It is unfortunate that these warnings are hurting your build system
> causing it to bail. Maybe we should expose a flag to disable that warning.
>
>>
>> 2. We have internal meta flags (similar to -Ofast) that expand to
>> multiple
>> llvm CL flags.  If this type of flag expands, but I'd like to disable
>> one
>> of the optimizations I'll hit a warning and the build will fail.
>
> Yea, and this sucks. I’m really hopeful to make clang not actually rely
> on the LLVM command line parsing code, so we can deal with some of these
> unfortunate issues.
>
>>
>> IIRC, the clang driver does not warn if you specify redundant options.
>> It
>> follows the last option wins policy.  It would be great if the llvm CL
>> options did the same, IMO.  Let me know if I've missed something.
>>
>> The solution we have internally is to add the cl::ZeroOrMore option to
>> many of the CL options.  This causes our internal code base to diverge.
>> This make me sad. :(
>
> Setting cl::opts to cl::ZeroOrMore doesn’t seem right to me. An
> alternative out-of-tree approach to this could be suppressing that warning
> message. That change would likely have less code divergence.
>
> -Chris
>
>>
>> Chad
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>