llvm dev - Jan 2015 - [LLVMdev] Using cl::ZeroOrMore more pervasively with the cl::opt class

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.

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.

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. :(

 Chad

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

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
>
>