This is an archive of the discontinued LLVM Phabricator instance.

[clang][cli] Add flexible TableGen multiclass for boolean options
ClosedPublic

Authored by jansvoboda11 on Dec 7 2020, 10:09 AM.

Details

Summary

This introduces more flexible multiclass for declaring two flags controlling the same boolean keypath.

Compared to existing Opt{In,Out}FFlag multiclasses, the new syntax makes it easier to read option declarations and reason about the keypath.

This also makes specifying common properties of both flags possible.

I'm open to suggestions on the class names. Not 100% sure the benefits are worth the added complexity.

Depends on D92774.

Diff Detail

Event Timeline

jansvoboda11 created this revision.Dec 7 2020, 10:09 AM
jansvoboda11 requested review of this revision.Dec 7 2020, 10:09 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptDec 7 2020, 10:09 AM

Not 100% sure the benefits are worth the added complexity.

I think this is worth it. Names seem pretty clear to me. All around, this seems a lot more clear to me than the approach you had in the CodeGenOptions patch.

clang/unittests/Frontend/CompilerInvocationTest.cpp
236–237

Can you clarify why this was dropped? Was it previously emitted due to a limitation in the implementation, or are we no longer supporting options that always get emitted for clarity?

That's great to hear, thanks.

clang/include/clang/Driver/Options.td
371

Does TableGen support some kind of assertion mechanism?

clang/unittests/Frontend/CompilerInvocationTest.cpp
236–237

This option was the only one using the old infrastructure (BooleanMarshalledFFlag).
It was set up to always generate the flag, even when it wasn't necessary (this flag sets the keypath to its default value).

I think we should aim to generate only command line arguments that are necessary to preserve the original invocation semantics.
I imagine this will be useful when debugging: one won't need to scan hundreds of flags that don't have any effect on CompilerInvocation.

llvm/include/llvm/Option/OptParser.td
175–176

Removal of this property causes the disappearance of -fno-experimental-new-pass-manager from list of generated arguments.

dexonsmith accepted this revision.Dec 8 2020, 6:48 AM

LGTM if you undo the change to lose support for AlwaysEmit (happy to consider in a separate patch if it’s the right thing to do though).

clang/include/clang/Driver/Options.td
371

Not that I’m aware of. @Bigcheese?

clang/unittests/Frontend/CompilerInvocationTest.cpp
236–237

This is a change in direction; the original thinking was that some options should always be emitted for human readability. I don’t feel too strongly about it, but I think this should be changed / dropped independently of other work if it’s done. I suggest splitting this out; I’d also like to hear @Bigcheese’s thoughts on that change since he did more of the original reviews.

This revision is now accepted and ready to land.Dec 8 2020, 6:48 AM
Bigcheese added inline comments.Dec 8 2020, 8:37 AM
clang/unittests/Frontend/CompilerInvocationTest.cpp
236–237

In general there are some options that should always be kept, such as the triple, but I don't see any reason to always keep -fno-experimental-new-pass-manager.

Split out change to "always emit" behavior of -f[no-]experimental-new-pass-manager and rebase.

jansvoboda11 added inline comments.Dec 8 2020, 9:22 AM
clang/unittests/Frontend/CompilerInvocationTest.cpp
236–237

I've extracted this into D92857.

dexonsmith accepted this revision.Dec 11 2020, 2:13 PM

(LGTM, in case my conditional approval earlier wasn't clear...)

This revision was landed with ongoing or failed builds.Dec 12 2020, 1:54 AM
This revision was automatically updated to reflect the committed changes.