Another spin-off of D79555. This directive will help keeping tests simple and adding -fconstexpr-steps only for clang-based compilers that need it.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
@ldionne, is this acceptable or is it too hackish?
I'm not very proud of importing dsl in format.py, but couldn't find a better solution.
It's a bit hackish IMO. I'm trying to think of better solutions. To be sure, importing dsl.py into format.py isn't much worse than what we do for _supportsVerify.
So this is to add -fconstexpr-steps=N, correct? Clang supports that flag, GCC doesn't. Does GCC have a sufficiently large number of constexpr steps by default?
That would just be side-stepping the problem, but perhaps that means that Clang's default limit on constexpr steps is too low? What do you think?
I'm not sure if it's the way to go. Clang has already a limit of 1Mi (1<<20), which seems reasonably high for normal code.
However, GCC has higher limits, -fconstexpr-loop-limit=n is 1<<18 and -fconstexpr-ops-limit=n (equivalent of -fconstexpr-steps=n) is 1<<25 so about 32Mi.
Also, changing the limit in clang will mean that we need to wait like 1 year to be able to use it in all supported versions of clang.
Another option, not sure if there's anything similar there already, having a directive that will map to the appropriate compiler option.
E.g. // MAX_CONSTEXPR_STEPS: 123456 would map to -fconstexpr-steps=123456 on Clang and -fconstexpr-ops-limit=123456 on GCC, and (possibly) /fconstexpr:steps123456 on MSVC.
It could be probably made more generic to just have one directive for many flags. E.g. // MAP_COMPILE_FLAGS: constexpr-steps=123456, other-flag=something.
The advantage would be to error out on unsupported flags.
In comparison, ADDITIONAL_COMPILE_FLAGS_IF_SUPPORTED would just ignore e.g. a flag with a typo silently on all compilers.