var-const ldionne philnik
- Group Reviewers
- rG87dd8c728934: [libc++][CI] increases constexpr evaluation limit.
I think it would be helpful to write the default value for comparison (I think it's 1048576 for Clang -- see clang/include/clang/Basic/LangOptions.def).
This flag is not supported by GCC. Does this configuration know not to pass the flag to GCC (and same for the GCC flag)?
Thanks for working on this, by the way -- I've seen a few cases where we had to change the code to work around this largely arbitrary limit, and really wished we didn't have to do that.
Is there a reason we don't want this in params.py? I can't really see a case where we want to restrict tests based on clang-constexpr-steps or gcc-constexpr-steps.
Are we sure we want to bring this right to the maximum? This could increase the built time by 100x when you actually have bad code.
Thanks for the reviews!
I'm not entirely sure what you mean. params.py is the file with the user configurable settings. I don't want the user to change this setting. What am I missing?
I don' think that's really helpful, Clang may change this at some point and then the comment is out of date. When really wanted to have the number I'd rather link to the source of truth.
Yes that's done by the hasCompileFlag part, when not supported it isn't added.
I can remove one 0 and it still works, but I like to have a bit of a margin. Lowering it further fails in the test.
I'd be a lot more comfortable with "just" a 10x increase. We can still bump it higher if we really need to later. By that time we might want to consider adding some easy way to disable this for specific tests to not have the compiler working for ages just to let us know we have a bug in our code. The ranges.transform.pass.cpp test is already horrible to work in. I can't imagine how it would be if we needed this step limit.
I don't feel very strongly, but I'd still add it. I think it's obvious to the reader that this number may be out of date, but it could be made explicit by adding a note like "at the time of writing". What I find useful here isn't so much the exact number as having a point of comparison -- i.e., are we increasing the default limit two times, ten times, a hundred times, etc.?
I think ideally we'd keep the default limit and then increase it as an opt-in for certain tests (that way, the increased number can be finer-grained to the needs of each test file). But currently I think there is no way to pass flags to e.g. only Clang.
I hate to rain on the parade, but I don't think this patch is desirable as-is. Indeed, we want to make sure that we compile our test suite with flags as similar as possible to what the users use. Otherwise, you end up not testing what matters, i.e. what users do.
For example, if we add -fconstexpr-steps=10000000 to the test suite, we could easily introduce a constexpr algorithm that always busts the default Clang limit even for small inputs, and our test suite would never catch it. Users would try to use the algorithm with a trivial example and things wouldn't work. That would be rather embarrassing.
So any approach where we turn this on for the whole test suite is a no-go IMO. Instead, we should increase the limit only for tests that actually require it, to reduce our exposure to the above bugs. One way to do it would be:
// In a test that requires more constexpr steps: // ADDITIONAL_COMPILE_FLAGS(has-fconstexpr-steps): -fconstexpr-steps=100000 // ADDITIONAL_COMPILE_FLAGS(has-fconstexpr-ops-limit): -fconstexpr-ops-limit=100000
Then, in features.py:
Feature(name='has-fconstexpr-steps', when=lambda cfg: hasCompileFlag(cfg, '-fconstexpr-steps=1')), Feature(name='has-fconstexpr-ops-limit', when=lambda cfg: hasCompileFlag(cfg, '-fconstexpr-ops-limit=1')),
I just need to implement support for this new fancy form of ADDITIONAL_COMPILE_FLAGS. I'll look into it immediately, this would be useful on its own even regardless of this review.
As mention during our live review I disagree with the "rain on the parade". IMO this is how code review should work. With your suggestions and the new feature you added I think we have a better solution to solve this problem. Thanks!
This isn't needed here (yet) but will be in the future. Add it here new to test whether the changes pass the CI.
With the suggested approach of @ldionne the hard-coded value is removed here.
With the suggested approach of @ldionne the limit will be per test and no longer a global value.