-ftime-report: Move FrontendTimer closer to TimeTraceScope

... to improve consistency and make "Clang time report" cover
`FrontendAction::BeginSourceFile` and `FrontendAction::EndSourceFile`.

Reapply "[NFC] Explicitly pass a VFS when creating DiagnosticsEngine (#115852)"

This reverts commit a1153cd6fedd4c906a9840987934ca4712e34cb2 with fixes
to lldb breakages.

Fixes https://github.com/l

Reapply "[NFC] Explicitly pass a VFS when creating DiagnosticsEngine (#115852)"

This reverts commit a1153cd6fedd4c906a9840987934ca4712e34cb2 with fixes
to lldb breakages.

Fixes https://github.com/llvm/llvm-project/issues/117145.

show more ...

Revert "[NFC] Explicitly pass a VFS when creating DiagnosticsEngine (#115852)"

Reverted for causing:
https://github.com/llvm/llvm-project/issues/117145

This reverts commit bdd10d9d249bd1c2a45e3de56

Revert "[NFC] Explicitly pass a VFS when creating DiagnosticsEngine (#115852)"

Reverted for causing:
https://github.com/llvm/llvm-project/issues/117145

This reverts commit bdd10d9d249bd1c2a45e3de56a5accd97e953458.

show more ...

[NFC] Explicitly pass a VFS when creating DiagnosticsEngine (#115852)

Starting with 41e3919ded78d8870f7c95e9181c7f7e29aa3cc4 DiagnosticsEngine
creation might perform IO. It was implicitly defaultin

[NFC] Explicitly pass a VFS when creating DiagnosticsEngine (#115852)

Starting with 41e3919ded78d8870f7c95e9181c7f7e29aa3cc4 DiagnosticsEngine
creation might perform IO. It was implicitly defaulting to
getRealFileSystem. This patch makes it explicit by pushing the decision
making to callers.

It uses ambient VFS if one is available, and keeps using
`getRealFileSystem` if there aren't any VFS.

show more ...

[clang] Split ObjectFilePCHContainerReader from ObjectFilePCHContainerWriter (#99599)

Close https://github.com/llvm/llvm-project/issues/99479

See https://github.com/llvm/llvm-project/issues/99479

[clang] Split ObjectFilePCHContainerReader from ObjectFilePCHContainerWriter (#99599)

Close https://github.com/llvm/llvm-project/issues/99479

See https://github.com/llvm/llvm-project/issues/99479 for details

show more ...

Reapply "Add source file name for template instantiations in -ftime-trace" (#99757)

Reverts https://github.com/llvm/llvm-project/pull/99731

Remove accidentally added temporary file.
Also, fix th

Reapply "Add source file name for template instantiations in -ftime-trace" (#99757)

Reverts https://github.com/llvm/llvm-project/pull/99731

Remove accidentally added temporary file.
Also, fix the uninitialized read of line number.

show more ...

Revert "Reapply "Add source file name for template instantiations in -ftime-trace"" (#99731)

Reverts llvm/llvm-project#99545

There were a couple of issues reported in the PR: a sanitizer warning

Revert "Reapply "Add source file name for template instantiations in -ftime-trace"" (#99731)

Reverts llvm/llvm-project#99545

There were a couple of issues reported in the PR: a sanitizer warning
(https://lab.llvm.org/buildbot/#/builders/164/builds/1246/steps/14/logs/stdio)
and a tmp file accidentally included in the commit.

show more ...

Reapply "Add source file name for template instantiations in -ftime-trace" (#99545)

Fix the Windows test.

Revert "Add source file name for template instantiations in -ftime-trace" (#99534)

Reverts llvm/llvm-project#98320

Breaks windows tests:

```
Step 8 (test-build-unified-tree-check-clang-unit)

Revert "Add source file name for template instantiations in -ftime-trace" (#99534)

Reverts llvm/llvm-project#98320

Breaks windows tests:

```
Step 8 (test-build-unified-tree-check-clang-unit) failure: test (failure)
******************** TEST 'Clang-Unit :: Support/./ClangSupportTests.exe/1/3' FAILED ********************
Script(shard):
--
GTEST_OUTPUT=json:C:\buildbot\as-builder-3\llvm-clang-x86_64-win-fast\build\tools\clang\unittests\Support\.\ClangSupportTests.exe-Clang-Unit-4296-1-3.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=3 GTEST_SHARD_INDEX=1 C:\buildbot\as-builder-3\llvm-clang-x86_64-win-fast\build\tools\clang\unittests\Support\.\ClangSupportTests.exe
--

Script:
--
C:\buildbot\as-builder-3\llvm-clang-x86_64-win-fast\build\tools\clang\unittests\Support\.\ClangSupportTests.exe --gtest_filter=TimeProfilerTest.TemplateInstantiations
--
C:\buildbot\as-builder-3\llvm-clang-x86_64-win-fast\llvm-project\clang\unittests\Support\TimeProfilerTest.cpp(278): error: Expected equality of these values:
R"(
Frontend
| ParseFunctionDefinition (fooB)
| ParseFunctionDefinition (fooMTA)
| ParseFunctionDefinition (fooA)
| ParseDeclarationOrFunctionDefinition (test.cc:3:5)
| | ParseFunctionDefinition (user)
| PerformPendingInstantiations
| | InstantiateFunction (fooA<int>, ./a.h:7)
| | | InstantiateFunction (fooB<int>, ./b.h:3)
| | | InstantiateFunction (fooMTA<int>, ./a.h:4)
)"
Which is: "\nFrontend\n| ParseFunctionDefinition (fooB)\n| ParseFunctionDefinition (fooMTA)\n| ParseFunctionDefinition (fooA)\n| ParseDeclarationOrFunctionDefinition (test.cc:3:5)\n| | ParseFunctionDefinition (user)\n| PerformPendingInstantiations\n| | InstantiateFunction (fooA<int>, ./a.h:7)\n| | | InstantiateFunction (fooB<int>, ./b.h:3)\n| | | InstantiateFunction (fooMTA<int>, ./a.h:4)\n"
buildTraceGraph(Json)
Which is: "\nFrontend\n| ParseFunctionDefinition (fooB)\n| ParseFunctionDefinition (fooMTA)\n| ParseFunctionDefinition (fooA)\n| ParseDeclarationOrFunctionDefinition (test.cc:3:5)\n| | ParseFunctionDefinition (user)\n| PerformPendingInstantiations\n| | InstantiateFunction (fooA<int>, .\\a.h:7)\n| | | InstantiateFunction (fooB<int>, .\\b.h:3)\n| | | InstantiateFunction (fooMTA<int>, .\\a.h:4)\n"
With diff:
@@ -7,5 +7,5 @@
| | ParseFunctionDefinition (user)
| PerformPendingInstantiations
-| | InstantiateFunction (fooA<int>, ./a.h:7)
-| | | InstantiateFunction (fooB<int>, ./b.h:3)
-| | | InstantiateFunction (fooMTA<int>, ./a.h:4)\n
+| | InstantiateFunction (fooA<int>, .\\a.h:7)
+| | | InstantiateFunction (fooB<int>, .\\b.h:3)
+| | | InstantiateFunction (fooMTA<int>, .\\a.h:4)\n



C:\buildbot\as-builder-3\llvm-clang-x86_64-win-fast\llvm-project\clang\unittests\Support\TimeProfilerTest.cpp:278
Expected equality of these values:
R"(
Frontend
| ParseFunctionDefinition (fooB)
| ParseFunctionDefinition (fooMTA)
| ParseFunctionDefinition (fooA)
| ParseDeclarationOrFunctionDefinition (test.cc:3:5)
| | ParseFunctionDefinition (user)
| PerformPendingInstantiations
| | InstantiateFunction (fooA<int>, ./a.h:7)

```

show more ...

Add source file name for template instantiations in -ftime-trace (#98320)

This is helpful in identifying file and location which contain the particular template declaration.

[RISCV] Add ability to list extensions enabled for a target (#98207)

bb83a3d introduced `--print-enabled-extensions` command line option for
AArch64. This patch introduces RISC-V support for this o

[RISCV] Add ability to list extensions enabled for a target (#98207)

bb83a3d introduced `--print-enabled-extensions` command line option for
AArch64. This patch introduces RISC-V support for this option. This patch
adds documentation for this option.

`riscvExtensionsHelp` is renamed to `printSupportedExtensions` to by
synonymous with AArch64 and so it is clear what that function does.

show more ...

Re-land: "[AArch64] Add ability to list extensions enabled for a target" (#95805) (#96795)

This introduces the new `--print-enabled-extensions` command line option
to AArch64, which prints the list

Re-land: "[AArch64] Add ability to list extensions enabled for a target" (#95805) (#96795)

This introduces the new `--print-enabled-extensions` command line option
to AArch64, which prints the list of extensions that are enabled for the
target specified by the combination of `--target`/`-march`/`-mcpu`
values.

The goal of the this option is both to enable the manual inspection of
the enabled extensions by users and to enhance the testability of
architecture versions and CPU targets implemented in the compiler.

As part of this change, a new field for `FEAT_*` architecture feature
names was added to the TableGen entries. The output of the existing
`--print-supported-extensions` option was updated accordingly to show
these in a separate column.

show more ...

Revert "[AArch64] Add ability to list extensions enabled for a target" (#96768)

Reverts llvm/llvm-project#95805 due to test failures caught by the
buildbots.

[AArch64] Add ability to list extensions enabled for a target (#95805)

This introduces the new `--print-enabled-extensions` command line option
to AArch64, which prints the list of extensions that

[AArch64] Add ability to list extensions enabled for a target (#95805)

This introduces the new `--print-enabled-extensions` command line option
to AArch64, which prints the list of extensions that are enabled for the
target specified by the combination of `--target`/`-march`/`-mcpu`
values.

The goal of the this option is both to enable the manual inspection of
the enabled extensions by users and to enhance the testability of
architecture versions and CPU targets implemented in the compiler.

As part of this change, a new field for `FEAT_*` architecture feature
names was added to the TableGen entries. The output of the existing
`--print-supported-extensions` option was updated accordingly to show
these in a separate column.

show more ...

[RISCV] Split code that tablegen needs out of RISCVISAInfo. (#89684)

This introduces a new file, RISCVISAUtils.cpp and moves the rest of
RISCVISAInfo to the TargetParser library.

This will allow

[RISCV] Split code that tablegen needs out of RISCVISAInfo. (#89684)

This introduces a new file, RISCVISAUtils.cpp and moves the rest of
RISCVISAInfo to the TargetParser library.

This will allow us to generate part of RISCVISAInfo.cpp using tablegen.

show more ...

[clang] Remove old Linux kernel workaround for ensuring stack space (#81533)

PR #71709 broke the Linux PIE build with `undefined symbol: alloca`
errors. With the newly included `clang/Basic/Builtin

[clang] Remove old Linux kernel workaround for ensuring stack space (#81533)

PR #71709 broke the Linux PIE build with `undefined symbol: alloca`
errors. With the newly included `clang/Basic/Builtins.h` in that PR, it
surfaces an issue with a combination of two previous patches.

26670dcba1609574cba5942aff78ff97b567c5f3 added `#undef alloca` so clang
builtins handling of alloca would work under MSVC (unsure if this is
still necessary).

194b6a3b1b1a99cc3c12c466a04320f271ebd8aa added code that calls `alloca`
to workaround a Linux kernel < 4.1 bug. Given that Linux 4.1 was EOL in
2018, it should be ok to remove this workaround.

show more ...

[clang] Enable descriptions for --print-supported-extensions (#66715)

Enables summary descriptions along with the names of the feature.
Descriptions here are simply looked up via the available llvm

[clang] Enable descriptions for --print-supported-extensions (#66715)

Enables summary descriptions along with the names of the feature.
Descriptions here are simply looked up via the available llvm tablegen
data.

show more ...

[clang][ARM] Enable --print-supported-extensions for ARM (#66083)

```
$ ./bin/clang --target=arm-linux-gnueabihf --print-supported-extensions
<...>
All available -march extensions for ARM

[clang][ARM] Enable --print-supported-extensions for ARM (#66083)

```
$ ./bin/clang --target=arm-linux-gnueabihf --print-supported-extensions
<...>
All available -march extensions for ARM

crc
crypto
sha2
aes
dotprod
<...>
```

This follows the format set by RISC-V and AArch64. As for AArch64, ARM
doesn't have versioned extensions like RISC-V does. So there is only 1
column, which contains the name.

Any extension without a "feature" is hidden as these cannot be used with
-march.

show more ...

[clang][AArch64] Add --print-supported-extensions support (#65466)

This follows the RISC-V work done in
4b40ced4e5ba10b841516b3970e7699ba8ded572.

This uses AArch64's target parser instead. We ju

[clang][AArch64] Add --print-supported-extensions support (#65466)

This follows the RISC-V work done in
4b40ced4e5ba10b841516b3970e7699ba8ded572.

This uses AArch64's target parser instead. We just list the names,
without the "+" on them, which matches RISC-V's format.

```
$ ./bin/clang -target aarch64-linux-gnu --print-supported-extensions
clang version 18.0.0 (https://github.com/llvm/llvm-project.git 154da8aec20719c82235a6957aa6e461f5a5e030)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: <...>
All available -march extensions for AArch64

aes
b16b16
bf16
brbe
crc
crypto
cssc
<...>
```

Since our extensions don't have versions in the same way there's just
one column with the name in.

Any extension without a feature name (including the special "none") is
not listed as those cannot be passed to -march, they're just for the
backend. For example the MTE extension can be added with "+memtag" but
MTE2 and MTE3 do not have feature names so they cannot be added to
-march.

This does not attempt to tackle the fact that clang allows invalid
combinations of AArch64 extensions, it simply lists the possible
options. It's still up to the user to ask for something sensible.

Equally, this has no context of what CPU is being selected. Neither does
the RISC-V option, the user has to be aware of that.

I've added a target parser test, and a high level clang test that checks
RISC-V and AArch64 work and that Intel, that doesn't support this, shows
the correct error.

show more ...

[RISCV] Add --print-supported-extensions support

This revision supports --print-supported-extensions,
it prints out all of the extensions and corresponding version supported.

Reviewed By: craig.top

[RISCV] Add --print-supported-extensions support

This revision supports --print-supported-extensions,
it prints out all of the extensions and corresponding version supported.

Reviewed By: craig.topper, kito-cheng

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

show more ...

[Driver] -ftime-trace: derive trace file names from -o and -dumpdir

Inspired by D133662.
Close https://github.com/llvm/llvm-project/issues/57285

When -ftime-trace is specified and the driver perfor

[Driver] -ftime-trace: derive trace file names from -o and -dumpdir

Inspired by D133662.
Close https://github.com/llvm/llvm-project/issues/57285

When -ftime-trace is specified and the driver performs both compilation and
linking phases, the trace files are currently placed in the temporary directory
(/tmp by default on *NIX). A more sensible behavior would be to derive the trace
file names from the -o option, similar to how GCC derives auxiliary and dump
file names. Use -dumpdir (D149193) to implement the -gsplit-dwarf like behavior.

The following script demonstrates the time trace filenames.

```
#!/bin/sh -e
PATH=/tmp/Rel/bin:$PATH # adapt according to your build directory
mkdir -p d e f
echo 'int main() {}' > d/a.c
echo > d/b.c

a() { rm $1 || exit 1; }

clang -ftime-trace d/a.c d/b.c # previously /tmp/[ab]-*.json
a a-a.json; a a-b.json
clang -ftime-trace d/a.c d/b.c -o e/x # previously /tmp/[ab]-*.json
a e/x-a.json; a e/x-b.json
clang -ftime-trace d/a.c d/b.c -o e/x -dumpdir f/
a f/a.json; a f/b.json
clang -ftime-trace=f d/a.c d/b.c -o e/x
a f/a-*.json; a f/b-*.json

clang -c -ftime-trace d/a.c d/b.c
a a.json b.json
clang -c -ftime-trace=f d/a.c d/b.c
a f/a.json f/b.json

clang -c -ftime-trace d/a.c -o e/xa.o
a e/xa.json
clang -c -ftime-trace d/a.c -o e/xa.o -dumpdir f/g
a f/ga.json
```

The driver checks `-ftime-trace` and `-ftime-trace=`, infers the trace file
name, and passes `-ftime-trace=` to cc1. The `-ftime-trace` cc1 option is
removed.

With offloading, previously `-ftime-trace` is passed to all offloading
actions, causing the same trace file to be overwritten by host and
offloading actions. This patch doesn't attempt to support offloading (D133662),
but makes a sensible change (`OffloadingPrefix.empty()`) to ensure we don't
overwrite the trace file.

Minor behavior differences: the trace file is now a result file, which
will be removed upon an error. -ftime-trace-granularity=0, like
-ftime-trace, can now cause a -Wunused-command-line-argument warning.

Reviewed By: Maetveis

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

show more ...

[Modules] Recreate file manager for ftime-trace when compiling a module

Close https://github.com/llvm/llvm-project/issues/60544.

The root cause for the issue is that when we compile a module unit,

[Modules] Recreate file manager for ftime-trace when compiling a module

Close https://github.com/llvm/llvm-project/issues/60544.

The root cause for the issue is that when we compile a module unit, the
file manager (and proprocessor and source manager) are owned by AST
instead of the compilaton instance. So the file manager may be invalid
when we want to create a time-report file for -ftime-trace when we are
compiling a module unit.

This patch tries to recreate the file manager for -ftime-trace if we
find the file manager is not valid.

show more ...

[clang] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of m

[clang] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

Revert "[Clang] change default storing path of `-ftime-trace`"

This reverts commit 38941da066a7b785ba4771710189172e94e37824.

[Clang] change default storing path of `-ftime-trace`

1. This implementation change the default storing behavior of -ftime-trace only.

That is, if the compiling job contains the linking action, the

[Clang] change default storing path of `-ftime-trace`

1. This implementation change the default storing behavior of -ftime-trace only.

That is, if the compiling job contains the linking action, the executable file' s directory may be seem as the main work directory.
Thus the time trace files would be stored in the same directory of linking result.

By this approach, the user can easily get the time-trace files in the main work directory. The improved demo results:

```
$ clang++ -ftime-trace -o main.out /demo/main.cpp
$ ls .
main.out main-[random-string].json
```

2. In addition, the main codes of time-trace files' path inference have been refactored.

* The <path> of -ftime-trace=<path> is infered in clang driver
* After that, -ftime-trace=<path> can be added into clang's options

By this approach, the dirty work of path processing and judging can be implemented in driver layer, so that the clang may focus on its main work.

# $ clang -ftime-trace -o xxx.out xxx.cpp

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

show more ...