Add free functions llvm::CodeGenOpt::{getLevel,getID,parseLevel} to
provide common implementations for functionality that has been
duplicated in many places across the codebase.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
I wasn't sure whether to include getID and unit-test it, or just drop it until it is used. If anyone has a preference let me know and I'll update the review.
The error handling inconsistency is kind of annoying too but this is an improvement. I thought traditionally GCC accepted whatever big number you put after -O
llvm/include/llvm/Support/CodeGen.h | ||
---|---|---|
57 | This is ABI breaking, so maybe we don't want/need to define the underlying type? |
llvm/include/llvm/Support/CodeGen.h | ||
---|---|---|
57 | This isn't in the C API, and this isn't for a release branch so I don't think it matters |
llvm/include/llvm/Support/CodeGen.h | ||
---|---|---|
67 | As I can see, clients do not check for nullopt. Either add checks or replace this check with an assertion and drop std::optional (in this case parseLevel should be updated accordingly). |
- Fix return type of getID
- Fix mistakenly updated option help text
- Add back in missing asserts
llvm/include/llvm/Support/CodeGen.h | ||
---|---|---|
57 | There is no strict need, it just:
I originally intended to change this to an enum class rather than a class in a namespace, but that is slightly more disruptive and should probably be done for every other enumeration defined here at the same time. | |
67 | Good catch! I was working off of the old behavior of llvm::Optional and assuming the new std::optional was guaranteed to assert on dereference as well. I think the right interface is to expose the optional, so for the callsites which currently do the equivalent of asserting I will just carry over an explicit assert to the new version. I posted to https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716/26 to discuss the issue more generally, as at least some of the patches which moved code from llvm::Optional to std::optional accidentally dropped assertions. |
llvm/include/llvm/Support/CodeGen.h | ||
---|---|---|
57 | Thanks for the explanation.
The downside is that int is usually more efficient.
cppreference says Values of unscoped enumeration type are implicitly-convertible to integral types. If the underlying type is not fixed, the value is convertible to the first type from the following list able to hold their entire value range: int, unsigned int, ... so casting to int should be safe. |
llvm/include/llvm/Support/CodeGen.h | ||
---|---|---|
67 | This causes massive amounts of warnings when built with GCC: ../include/llvm/Support/CodeGen.h:67:12: warning: comparison is always false due to limited range of data type [-Wtype-limits] 67 | if (ID < 0 || ID > 3) | ~~~^~~ |
llvm/include/llvm/Support/CodeGen.h | ||
---|---|---|
67 | Fixed in 2dc33713de7ceae3e28a13be1d72c862ec0efb2c Thank you for reporting, sorry for the noise! |
I also ended up changing the underlying type to int to resolve https://lab.llvm.org/buildbot/#/builders/61/builds/38754 , and I removed the getID function (with the implicit conversions it would never get used anyway).
flang/lib/Frontend/FrontendActions.cpp | ||
---|---|---|
591 | Does this need llvm::? ../llvm-project/flang/lib/Frontend/FrontendActions.cpp:590:7: error: use of undeclared identifier 'CodeGenOpt'; did you mean 'llvm::CodeGenOpt'? CodeGenOpt::getLevel(CGOpts.OptimizationLevel); ^~~~~~~~~~ llvm::CodeGenOpt ../llvm-project/llvm/include/llvm/Support/CodeGen.h:53:13: note: 'llvm::CodeGenOpt' declared here namespace CodeGenOpt { ^ See https://lab.llvm.org/buildbot/#/builders/191/builds/13832. |
flang/lib/Frontend/FrontendActions.cpp | ||
---|---|---|
591 | Yes, I just commited a1baa7a5c57ea3065f8f354d2fc758b3328040fd to fix this; I thought I was building flang locally but didn't verify it and clearly was not Thank you and sorry for the noise! |
Does this need llvm::?
See https://lab.llvm.org/buildbot/#/builders/191/builds/13832.