[clang][cli] Implement `getAllArgValues` marshalling

This infrastructure can be used ~30 more command line options.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D93631

[clang] Use enum for LangOptions::SYCLVersion instead of unsigned

`LangOptions::SYCLVersion` can only have two values. This patch introduces an enum that allows us to reduce the member size from 32

[clang] Use enum for LangOptions::SYCLVersion instead of unsigned

`LangOptions::SYCLVersion` can only have two values. This patch introduces an enum that allows us to reduce the member size from 32 bits to 1 bit.

Consequently, this also makes marshalling of this option fit into our model for enums: D84674.

Reviewed By: bader

Differential Revision: https://reviews.llvm.org/D93540

show more ...

[clang][cli] Let denormalizer decide how to render the option based on the option class

Before this patch, you needed to use `AutoNormalizeEnumJoined` whenever you wanted to **de**normalize joined e

[clang][cli] Let denormalizer decide how to render the option based on the option class

Before this patch, you needed to use `AutoNormalizeEnumJoined` whenever you wanted to **de**normalize joined enum.
Besides the naming confusion, this means the fact the option is joined is specified in two places: in the normalization multiclass and in the `Joined<["-"], ...>` multiclass.
This patch makes this work automatically, taking into account the `OptionClass` of options.

Also, the enum denormalizer now just looks up the spelling of the present enum case in a table and forwards it to the string denormalizer.

I also added more tests that exercise this.

Reviewed By: dexonsmith

Original patch by Daniel Grumberg.

Differential Revision: https://reviews.llvm.org/D84189

show more ...

[clang][cli] Port CodeGenOpts simple string flags to new option parsing system

Depends on D84668

Reviewed By: Bigcheese

Original patch by Daniel Grumberg.

Differential Revision: https://reviews.l

[clang][cli] Port CodeGenOpts simple string flags to new option parsing system

Depends on D84668

Reviewed By: Bigcheese

Original patch by Daniel Grumberg.

Differential Revision: https://reviews.llvm.org/D84669

show more ...

[clang][cli] Port FrontendOpts simple string based options to new option parsing system

Depends on D84189

Reviewed By: dexonsmith

Original patch by Daniel Grumberg.

Differential Revision: https:/

[clang][cli] Port FrontendOpts simple string based options to new option parsing system

Depends on D84189

Reviewed By: dexonsmith

Original patch by Daniel Grumberg.

Differential Revision: https://reviews.llvm.org/D84190

show more ...

[clang][cli] Port PreprocessorOpts simple string based options to new option parsing system

Depends on D84671

Reviewed By: Bigcheese

Original patch by Daniel Grumberg.

Differential Revision: http

[clang][cli] Port PreprocessorOpts simple string based options to new option parsing system

Depends on D84671

Reviewed By: Bigcheese

Original patch by Daniel Grumberg.

Differential Revision: https://reviews.llvm.org/D84672

show more ...

[clang][cli] Port LangOpts simple string based options to new option parsing system

Depends on D84670

Reviewed By: Bigcheese

Original patch by Daniel Grumberg.

Differential Revision: https://revi

[clang][cli] Port LangOpts simple string based options to new option parsing system

Depends on D84670

Reviewed By: Bigcheese

Original patch by Daniel Grumberg.

Differential Revision: https://reviews.llvm.org/D84671

show more ...

[clang][cli] Port TargetOpts simple string based options to new option parsing system

Depends on D84190

Reviewed By: Bigcheese

Original patch by Daniel Grumberg.

Differential Revision: https://re

[clang][cli] Port TargetOpts simple string based options to new option parsing system

Depends on D84190

Reviewed By: Bigcheese

Original patch by Daniel Grumberg.

Differential Revision: https://reviews.llvm.org/D84668

show more ...

[clang][cli] Port HeaderSearch simple string options to new option parsing system

Depends on D84669

Reviewed By: Bigcheese

Original patch by Daniel Grumberg.

Differential Revision: https://review

[clang][cli] Port HeaderSearch simple string options to new option parsing system

Depends on D84669

Reviewed By: Bigcheese

Original patch by Daniel Grumberg.

Differential Revision: https://reviews.llvm.org/D84670

show more ...

[clang][cli] Convert Analyzer option string based options to new option parsing system

Depends on D84185

Reviewed By: dexonsmith

Original patch by Daniel Grumberg.

Differential Revision: https://

[clang][cli] Convert Analyzer option string based options to new option parsing system

Depends on D84185

Reviewed By: dexonsmith

Original patch by Daniel Grumberg.

Differential Revision: https://reviews.llvm.org/D84186

show more ...

[clang][cli] Port DependencyOutput string based options to new option parsing system

Depends on D84186

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D84187

[clang][cli] Port LangOpts option flags to new option parsing system

Depends on D83892 & D83694 & D93104.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D83979

[clang][cli] Port CodeGen option flags to new option parsing system

Depends on D83697.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D83892

[clang][cli] Prevent double denormalization

If both flags created through BoolOption are CC1Option and the keypath has a non-default or non-implied value, the denormalizer gets called twice. If the

[clang][cli] Prevent double denormalization

If both flags created through BoolOption are CC1Option and the keypath has a non-default or non-implied value, the denormalizer gets called twice. If the denormalizer has the ability to generate both flags, we can end up generating the same flag twice.

Reviewed By: dexonsmith, Bigcheese

Differential Revision: https://reviews.llvm.org/D93094

show more ...

[clang][cli] Do not marshall only CC1Option flags in BoolOption

We cannot be sure whether a flag is CC1Option inside the definition of `BoolOption`. Take the example below:

```
let Flags = [CC1Opti

[clang][cli] Do not marshall only CC1Option flags in BoolOption

We cannot be sure whether a flag is CC1Option inside the definition of `BoolOption`. Take the example below:

```
let Flags = [CC1Option] in {
defm xxx : BoolOption<...>;
}
```

where TableGen applies `Flags = [CC1Option]` to the `xxx` and `no_xxx` records **after** they have been is fully declared by `BoolOption`.

For the refactored `-f[no-]debug-pass-manager` flags (see the diff), this means `BoolOption` never adds any marshalling info, as it doesn't see either of the flags as `CC1Option`.

For that reason, we should defensively append the marshalling information to both flags inside `BoolOption`. Now the check for `CC1Option` needs to happen later, in the parsing macro, when all TableGen logic has been resolved.

However, for some flags defined through `BoolOption`, we can run into issues:

```
// Options.td
def fenable_xxx : /* ... */;

// Both flags are CC1Option, the first is implied.
defm xxx : BoolOption<"xxx,
"Opts.Xxx", DefaultsToFalse,
ChangedBy<PosFlag, [CC1Option], "", [fenable_xxx]>,
ResetBy<NegFlag, [CC1Option]>>;
```

When parsing `clang -cc1 -fenable-xxx`:
* we run parsing for `PosFlag`:
* set `Opts.Xxx` to default `false`,
* discover `PosFlag` is implied by `-fenable-xxx`: set `Opts.Xxx` to `true`,
* don't see `-fxxx` on command line: do nothing,
* we run parsing for `NegFlag`:
* set `Opts.Xxx` to default `false`,
* discover `NegFlag` cannot be implied: do nothing,
* don't see `-fno-xxx` on command line: do nothing.

Now we ended up with `Opts.Xxx` set to `false` instead of `true`. For this reason, we need to ensure to append the same `ImpliedByAnyOf` instance to both flags.

This means both parsing runs now behave identically (they set the same default value, run the same "implied by" check, and call `makeBooleanOptionNormalizer` that already has information on both flags, so it returns the same value in both calls).

The solution works well, but what might be confusing is this: you have defined a flag **A** that is not `CC1Option`, but can be implied by another flag **B** that is `CC1Option`:
* if **A** is defined manually, it will never get implied, as the code never runs
```
def no_signed_zeros : Flag<["-"], "fno-signed-zeros">, Group<f_Group>, Flags<[]>,
MarshallingInfoFlag<"LangOpts->NoSignedZero">, ImpliedByAnyOf<[menable_unsafe_fp_math]>;
```
* if **A** is defined by `BoolOption`, it could get implied, as the code is run by its `CC1Option` counterpart:
```
defm signed_zeros : BoolOption<"signed-zeros",
"LangOpts->NoSignedZero", DefaultsToFalse,
ChangedBy<NegFlag, [], "Allow optimizations that ignore the sign of floating point zeros",
[cl_no_signed_zeros, menable_unsafe_fp_math]>,
ResetBy<PosFlag, [CC1Option]>, "f">, Group<f_Group>;
```

This is a surprising inconsistency.

One solution might be to somehow propagate the final `Flags` of the implied flag in `ImpliedByAnyOf` and check whether it has `CC1Option` in the parsing macro. However, I think it doesn't make sense to spend time thinking about a corner case that won't come up in real code.

An observation: it is unfortunate that the marshalling information is a part of the flag definition. If we represented it in a separate structure, we could avoid the "double parsing" problem by having a single source of truth. This would require a lot of additional work though.

Note: the original patch missed the `CC1Option` check in the parsing macro, making my reasoning here incomplete. Moreover, it contained a change to denormalization that wasn't necessarily related to these changes, so I've extracted that to a follow-up patch: D93094.

Reviewed By: dexonsmith, Bigcheese

Differential Revision: https://reviews.llvm.org/D93008

show more ...

[clang][cli] Squash multiple cc1 -fxxx-exceptions flags into single -exception-model=xxx option

This patch enables marshalling of the exception model options while enforcing their mutual exclusivity

[clang][cli] Squash multiple cc1 -fxxx-exceptions flags into single -exception-model=xxx option

This patch enables marshalling of the exception model options while enforcing their mutual exclusivity. The clang driver interface remains the same, this only affects the cc1 command line.

Depends on D93215.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D93216

show more ...

[clang][cli] Squash exception model in LangOptions into one member

This squashes multiple members in LangOptions into one. This is leveraged in a follow-up patch that implements marshalling of relat

[clang][cli] Squash exception model in LangOptions into one member

This squashes multiple members in LangOptions into one. This is leveraged in a follow-up patch that implements marshalling of related command-line options.

Depends on D93214.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D93215

show more ...

[clang][cli] Port FileSystem options to new option parsing system

Depends on D84187

Reviewed By: dexonsmith

Original patch by Daniel Grumberg.

Differential Revision: https://reviews.llvm.org/D841

[clang][cli] Port FileSystem options to new option parsing system

Depends on D84187

Reviewed By: dexonsmith

Original patch by Daniel Grumberg.

Differential Revision: https://reviews.llvm.org/D84188

show more ...

[clang][cli] Better defaults for MarshallingInfoString

Depends on D84018

Reviewed By: Bigcheese

Original patch by Daniel Grumberg.

Differential Revision: https://reviews.llvm.org/D84185

[clang][cli] Port Preprocessor and PreprocessorOutput option flags to new option parsing system

Depends on D83979

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D84018

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

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

Compared to existing Opt{In,

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

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.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D92775

show more ...

Revert "[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis."

The patch introduced a cycle dependency:

clangAnalysis -> clangFrontend -> clangSema -> clangAnalysis

This re

Revert "[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis."

The patch introduced a cycle dependency:

clangAnalysis -> clangFrontend -> clangSema -> clangAnalysis

This reverts commit 00ffea77ad887b576e9db82d98c97a31fee172cb.
This reverts commit ea6641085d025ca0a5cef940465ef14d0ccace02.

show more ...

Revert "Revert "Revert "Revert "[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis.""""

This reverts commit 6a89cb8136f3435bd977b419b683dc0acc98e61e.

[Driver] Add -f[no-]legacy-pass-manager to supersede -f[no-]experimental-new-pass-manager

The new PM is considered stable and many downstream groups have adopted it (some
have adopted it for more th

[Driver] Add -f[no-]legacy-pass-manager to supersede -f[no-]experimental-new-pass-manager

The new PM is considered stable and many downstream groups have adopted it (some
have adopted it for more than two years). Add -f[no-]legacy-pass-manager to reflect the
fact that it is no longer experimental and the legacy pass manager is something we strive to retire.

In the future, when the legacy PM eventually goes away,
-fno-experimental-new-pass-manager and -flegacy-pass-manager will be removed.

This patch also changes -f[no-]legacy-pass-manager to pass `-plugin-opt={new,legacy}-pass-manager` to the linker (supported by both ld.lld and LLVMgold.so) when -flto/-flto=thin is specified

Reviewed By: aeubanks, rsmith

Differential Revision: https://reviews.llvm.org/D92915

show more ...

[Time-report] Add a flag -ftime-report={per-pass,per-pass-run} to control the pass timing aggregation

Currently, -ftime-report + new pass manager emits one line of report for each
pass run. This pot

[Time-report] Add a flag -ftime-report={per-pass,per-pass-run} to control the pass timing aggregation

Currently, -ftime-report + new pass manager emits one line of report for each
pass run. This potentially causes huge output text especially with regular LTO
or large single file (Obeserved in private tests and was reported in D51276).
The behaviour of -ftime-report + legacy pass manager is
emitting one line of report for each pass object which has relatively reasonable
text output size. This patch adds a flag `-ftime-report=` to control time report
aggregation for new pass manager.

The flag is for new pass manager only. Using it with legacy pass manager gives
an error. It is a driver and cc1 flag. `per-pass` is the new default so
`-ftime-report` is aliased to `-ftime-report=per-pass`. Before this patch,
functionality-wise `-ftime-report` is aliased to `-ftime-report=per-pass-run`.

* Adds an boolean variable TimePassesHandler::PerRun to control per-pass vs per-pass-run.
* Adds a new clang CodeGen flag CodeGenOptions::TimePassesPerRun to work with the existing CodeGenOptions::TimePasses.
* Remove FrontendOptions::ShowTimers, its uses are replaced by the existing CodeGenOptions::TimePasses.
* Remove FrontendTimesIsEnabled (It was introduced in D45619 which was largely reverted.)

Differential Revision: https://reviews.llvm.org/D92436

show more ...