Chad Rosier
2015-Jan-23 21:24 UTC
[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
Chris Bieneman
2015-Jan-23 22:33 UTC
[LLVMdev] Using cl::ZeroOrMore more pervasively with the cl::opt class
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
Chad Rosier
2015-Jan-23 22:48 UTC
[LLVMdev] Using cl::ZeroOrMore more pervasively with the cl::opt class
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 > >
Reasonably Related Threads
- Issues with XML validation after upgrade to 1.2.12
- [LLVMdev] llvm-config --cxxflags is not consistent when building by cmake.
- [LLVMdev] llvm-config --cxxflags is not consistent when building by cmake.
- [LLVMdev] Analysis of polly-detect overhead in oggenc
- [LLVMdev] [cfe-dev] C++ Expression Template Benchmarks for GCC/Clang/Intel/PGI/MSVC