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

Chad

Let me start by saying the NumOccurances flags are a particularly nasty bit of code that is on my list to clean up.

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

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

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.