This is an archive of the discontinued LLVM Phabricator instance.

[libc++] [test] Add support for `ADDITIONAL_COMPILE_FLAGS_IF_SUPPORTED` directive.
AbandonedPublic

Authored by philnik on Jul 26 2021, 8:17 AM.

Details

Reviewers
ldionne
curdeius
Group Reviewers
Restricted Project
Summary

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

Event Timeline

curdeius created this revision.Jul 26 2021, 8:17 AM
curdeius requested review of this revision.Jul 26 2021, 8:17 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 26 2021, 8:17 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript

@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.

@ldionne, is this acceptable or is it too hackish?

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?

@ldionne, is this acceptable or is it too hackish?

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?

Exactly. GCC is okay by default.

@ldionne, is this acceptable or is it too hackish?

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?

Exactly. GCC is okay 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?

@ldionne, is this acceptable or is it too hackish?

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?

Exactly. GCC is okay 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.

philnik commandeered this revision.Dec 14 2022, 6:28 PM
philnik added a reviewer: curdeius.
philnik added a subscriber: philnik.

This has been superseded by D132575, so I'm abandoning this patch.

Herald added a project: Restricted Project. · View Herald TranscriptDec 14 2022, 6:28 PM
philnik abandoned this revision.Dec 14 2022, 6:28 PM