maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Driver/opt-record.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

81 lines
5.6 KiB
C
Raw Normal View History

Add an option to save the backend-produced YAML optimization record to a file The backend now has the capability to save information from optimizations, the same information that can be used to generate optimization diagnostics but in machine-consumable form, into an output file. This can be enabled when using opt (see r282539), and this change enables it when using clang. The idea is that other tools will be able to consume these files, and perhaps in combination with the original source code, produce various kinds of optimization reports for users (and for compiler developers). We now have at-least two tools that can consume these files: * tools/llvm-opt-report * utils/opt-viewer Using the flag -fsave-optimization-record will cause the YAML file to be generated; the file name will be based on the output file name (if we're using -c or -S and have an output name), or the input file name. When we're using CUDA, or some other offloading mechanism, separate files are generated for each backend target. The output file name can be specified by the user using -foptimization-record-file=filename. Differential Revision: https://reviews.llvm.org/D25225 llvm-svn: 283834
2016-10-11 08:26:09 +08:00
// RUN: %clang -### -S -o FOO -fsave-optimization-record %s 2>&1 | FileCheck %s
// RUN: %clang -### -c -o FOO -fsave-optimization-record %s 2>&1 | FileCheck %s
Base optimization-record file names on the final output Using Output.getFilename() to construct the file name used for optimization recording in Clang::ConstructJob, when -c is provided, does not work correctly if we're not using the integrated assembler. With -no-integrated-as (or -save-temps) Output.getFilename() gives the name of the temporary assembly file, not the final output file. Instead, use the final output (as provided by -o). If this is not available, then fall back to using a name based on the input file. Fixes PR31532. llvm-svn: 311041
2017-08-17 05:34:27 +08:00
// RUN: %clang -### -c -o FOO.o -fsave-optimization-record %s 2>&1 | FileCheck %s
// RUN: %clang -### -save-temps -S -o FOO -fsave-optimization-record %s 2>&1 | FileCheck %s
// RUN: %clang -### -save-temps -c -o FOO.o -fsave-optimization-record %s 2>&1 | FileCheck %s
Add an option to save the backend-produced YAML optimization record to a file The backend now has the capability to save information from optimizations, the same information that can be used to generate optimization diagnostics but in machine-consumable form, into an output file. This can be enabled when using opt (see r282539), and this change enables it when using clang. The idea is that other tools will be able to consume these files, and perhaps in combination with the original source code, produce various kinds of optimization reports for users (and for compiler developers). We now have at-least two tools that can consume these files: * tools/llvm-opt-report * utils/opt-viewer Using the flag -fsave-optimization-record will cause the YAML file to be generated; the file name will be based on the output file name (if we're using -c or -S and have an output name), or the input file name. When we're using CUDA, or some other offloading mechanism, separate files are generated for each backend target. The output file name can be specified by the user using -foptimization-record-file=filename. Differential Revision: https://reviews.llvm.org/D25225 llvm-svn: 283834
2016-10-11 08:26:09 +08:00
// RUN: %clang -### -c -fsave-optimization-record %s 2>&1 | FileCheck %s -check-prefix=CHECK-NO-O
Base optimization-record file names on the final output Using Output.getFilename() to construct the file name used for optimization recording in Clang::ConstructJob, when -c is provided, does not work correctly if we're not using the integrated assembler. With -no-integrated-as (or -save-temps) Output.getFilename() gives the name of the temporary assembly file, not the final output file. Instead, use the final output (as provided by -o). If this is not available, then fall back to using a name based on the input file. Fixes PR31532. llvm-svn: 311041
2017-08-17 05:34:27 +08:00
// RUN: %clang -### -save-temps -c -fsave-optimization-record %s 2>&1 | FileCheck %s -check-prefix=CHECK-NO-O
Add an option to save the backend-produced YAML optimization record to a file The backend now has the capability to save information from optimizations, the same information that can be used to generate optimization diagnostics but in machine-consumable form, into an output file. This can be enabled when using opt (see r282539), and this change enables it when using clang. The idea is that other tools will be able to consume these files, and perhaps in combination with the original source code, produce various kinds of optimization reports for users (and for compiler developers). We now have at-least two tools that can consume these files: * tools/llvm-opt-report * utils/opt-viewer Using the flag -fsave-optimization-record will cause the YAML file to be generated; the file name will be based on the output file name (if we're using -c or -S and have an output name), or the input file name. When we're using CUDA, or some other offloading mechanism, separate files are generated for each backend target. The output file name can be specified by the user using -foptimization-record-file=filename. Differential Revision: https://reviews.llvm.org/D25225 llvm-svn: 283834
2016-10-11 08:26:09 +08:00
// RUN: %clang -### -fsave-optimization-record %s 2>&1 | FileCheck %s -check-prefix=CHECK-NO-O
// RUN: %clang -### -S -fsave-optimization-record -x cuda -nocudainc -nocudalib %s 2>&1 | FileCheck %s -check-prefix=CHECK-NO-O -check-prefix=CHECK-CUDA-DEV
// RUN: %clang -### -fsave-optimization-record -x cuda -nocudainc -nocudalib %s 2>&1 | FileCheck %s -check-prefix=CHECK-NO-O -check-prefix=CHECK-CUDA-DEV
// RUN: %clang -### -S -o FOO -fsave-optimization-record -foptimization-record-file=BAR.txt %s 2>&1 | FileCheck %s -check-prefix=CHECK-EQ
[clang] -foptimization-record-file= should imply -fsave-optimization-record The Clang option -foptimization-record-file= controls which file an optimization record is output to. Optimization records are output if you use the Clang option -fsave-optimization-record. If you specify the first option without the second, you get a warning that the command line argument was unused. Passing -foptimization-record-file= should imply -fsave-optimization-record. This fixes PR33670 Patch by: Dmitry Venikov <venikov@phystech.edu> Differential revision: https://reviews.llvm.org/D39834 llvm-svn: 321090
2017-12-20 01:16:45 +08:00
// RUN: %clang -### -S -o FOO -foptimization-record-file=BAR.txt %s 2>&1 | FileCheck %s -check-prefix=CHECK-EQ
// RUN: %clang -### -S -o FOO -foptimization-record-file=BAR.txt -fno-save-optimization-record %s 2>&1 | FileCheck %s --check-prefix=CHECK-FOPT-DISABLE
Add an option to save the backend-produced YAML optimization record to a file The backend now has the capability to save information from optimizations, the same information that can be used to generate optimization diagnostics but in machine-consumable form, into an output file. This can be enabled when using opt (see r282539), and this change enables it when using clang. The idea is that other tools will be able to consume these files, and perhaps in combination with the original source code, produce various kinds of optimization reports for users (and for compiler developers). We now have at-least two tools that can consume these files: * tools/llvm-opt-report * utils/opt-viewer Using the flag -fsave-optimization-record will cause the YAML file to be generated; the file name will be based on the output file name (if we're using -c or -S and have an output name), or the input file name. When we're using CUDA, or some other offloading mechanism, separate files are generated for each backend target. The output file name can be specified by the user using -foptimization-record-file=filename. Differential Revision: https://reviews.llvm.org/D25225 llvm-svn: 283834
2016-10-11 08:26:09 +08:00
Reland "[Remarks] Add -foptimization-record-passes to filter remark emission" Currently we have -Rpass for filtering the remarks that are displayed as diagnostics, but when using -fsave-optimization-record, there is no way to filter the remarks while generating them. This adds support for filtering remarks by passes using a regex. Ex: `clang -fsave-optimization-record -foptimization-record-passes=inline` will only emit the remarks coming from the pass `inline`. This adds: * `-fsave-optimization-record` to the driver * `-opt-record-passes` to cc1 * `-lto-pass-remarks-filter` to the LTOCodeGenerator * `--opt-remarks-passes` to lld * `-pass-remarks-filter` to llc, opt, llvm-lto, llvm-lto2 * `-opt-remarks-passes` to gold-plugin Differential Revision: https://reviews.llvm.org/D59268 Original llvm-svn: 355964 llvm-svn: 355984
2019-03-13 05:22:27 +08:00
// RUN: %clang -### -S -o FOO -fsave-optimization-record -foptimization-record-passes=inline %s 2>&1 | FileCheck %s -check-prefix=CHECK-EQ-PASSES
// RUN: %clang -### -S -o FOO -foptimization-record-passes=inline %s 2>&1 | FileCheck %s -check-prefix=CHECK-EQ-PASSES
// RUN: %clang -### -S -o FOO -foptimization-record-passes=inline -fno-save-optimization-record %s 2>&1 | FileCheck %s --check-prefix=CHECK-FOPT-DISABLE-PASSES
[Remarks] Extend -fsave-optimization-record to specify the format Use -fsave-optimization-record=<format> to specify a different format than the default, which is YAML. For now, only YAML is supported. llvm-svn: 363573
2019-06-18 00:06:00 +08:00
// RUN: %clang -### -S -o FOO -fsave-optimization-record -fsave-optimization-record=some-format %s 2>&1 | FileCheck %s -check-prefix=CHECK-EQ-FORMAT
// RUN: %clang -### -S -o FOO -fsave-optimization-record=some-format %s 2>&1 | FileCheck %s -check-prefix=CHECK-EQ-FORMAT
// RUN: %clang -### -S -o FOO -fsave-optimization-record=some-format -fno-save-optimization-record %s 2>&1 | FileCheck %s --check-prefix=CHECK-FOPT-DISABLE-FORMAT
Reland "[Remarks] Add -foptimization-record-passes to filter remark emission" Currently we have -Rpass for filtering the remarks that are displayed as diagnostics, but when using -fsave-optimization-record, there is no way to filter the remarks while generating them. This adds support for filtering remarks by passes using a regex. Ex: `clang -fsave-optimization-record -foptimization-record-passes=inline` will only emit the remarks coming from the pass `inline`. This adds: * `-fsave-optimization-record` to the driver * `-opt-record-passes` to cc1 * `-lto-pass-remarks-filter` to the LTOCodeGenerator * `--opt-remarks-passes` to lld * `-pass-remarks-filter` to llc, opt, llvm-lto, llvm-lto2 * `-opt-remarks-passes` to gold-plugin Differential Revision: https://reviews.llvm.org/D59268 Original llvm-svn: 355964 llvm-svn: 355984
2019-03-13 05:22:27 +08:00
//
Add an option to save the backend-produced YAML optimization record to a file The backend now has the capability to save information from optimizations, the same information that can be used to generate optimization diagnostics but in machine-consumable form, into an output file. This can be enabled when using opt (see r282539), and this change enables it when using clang. The idea is that other tools will be able to consume these files, and perhaps in combination with the original source code, produce various kinds of optimization reports for users (and for compiler developers). We now have at-least two tools that can consume these files: * tools/llvm-opt-report * utils/opt-viewer Using the flag -fsave-optimization-record will cause the YAML file to be generated; the file name will be based on the output file name (if we're using -c or -S and have an output name), or the input file name. When we're using CUDA, or some other offloading mechanism, separate files are generated for each backend target. The output file name can be specified by the user using -foptimization-record-file=filename. Differential Revision: https://reviews.llvm.org/D25225 llvm-svn: 283834
2016-10-11 08:26:09 +08:00
// CHECK: "-cc1"
// CHECK: "-opt-record-file" "FOO.opt.yaml"
// CHECK-NO-O: "-cc1"
// CHECK-NO-O-DAG: "-opt-record-file" "opt-record.opt.yaml"
[Driver][OpenMP] Add support to create jobs for unbundling actions. Summary: This patch adds the support to create jobs for the `OffloadBundlingAction` which will invoke the `clang-offload-bundler` tool to unbundle input files. Unlike other actions, unbundling actions have multiple outputs. Therefore, this patch adds the required changes to have a variant of `Tool::ConstructJob` with multiple outputs. The way the naming of the results is implemented is also slightly modified so that the same action can use a different offloading prefix for each use by the different offloading actions. With this patch, it is possible to compile a functional OpenMP binary with offloading support, even with separate compilation. Reviewers: echristo, tra, jlebar, ABataev, hfinkel Subscribers: mkuron, whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin Differential Revision: https://reviews.llvm.org/D21857 llvm-svn: 285326
2016-10-28 02:14:55 +08:00
// CHECK-CUDA-DEV-DAG: "-opt-record-file" "opt-record-cuda-{{nvptx64|nvptx}}-nvidia-cuda-sm_20.opt.yaml"
Add an option to save the backend-produced YAML optimization record to a file The backend now has the capability to save information from optimizations, the same information that can be used to generate optimization diagnostics but in machine-consumable form, into an output file. This can be enabled when using opt (see r282539), and this change enables it when using clang. The idea is that other tools will be able to consume these files, and perhaps in combination with the original source code, produce various kinds of optimization reports for users (and for compiler developers). We now have at-least two tools that can consume these files: * tools/llvm-opt-report * utils/opt-viewer Using the flag -fsave-optimization-record will cause the YAML file to be generated; the file name will be based on the output file name (if we're using -c or -S and have an output name), or the input file name. When we're using CUDA, or some other offloading mechanism, separate files are generated for each backend target. The output file name can be specified by the user using -foptimization-record-file=filename. Differential Revision: https://reviews.llvm.org/D25225 llvm-svn: 283834
2016-10-11 08:26:09 +08:00
// CHECK-EQ: "-cc1"
// CHECK-EQ: "-opt-record-file" "BAR.txt"
[clang] -foptimization-record-file= should imply -fsave-optimization-record The Clang option -foptimization-record-file= controls which file an optimization record is output to. Optimization records are output if you use the Clang option -fsave-optimization-record. If you specify the first option without the second, you get a warning that the command line argument was unused. Passing -foptimization-record-file= should imply -fsave-optimization-record. This fixes PR33670 Patch by: Dmitry Venikov <venikov@phystech.edu> Differential revision: https://reviews.llvm.org/D39834 llvm-svn: 321090
2017-12-20 01:16:45 +08:00
// CHECK-FOPT-DISABLE-NOT: "-fno-save-optimization-record"
Reland "[Remarks] Add -foptimization-record-passes to filter remark emission" Currently we have -Rpass for filtering the remarks that are displayed as diagnostics, but when using -fsave-optimization-record, there is no way to filter the remarks while generating them. This adds support for filtering remarks by passes using a regex. Ex: `clang -fsave-optimization-record -foptimization-record-passes=inline` will only emit the remarks coming from the pass `inline`. This adds: * `-fsave-optimization-record` to the driver * `-opt-record-passes` to cc1 * `-lto-pass-remarks-filter` to the LTOCodeGenerator * `--opt-remarks-passes` to lld * `-pass-remarks-filter` to llc, opt, llvm-lto, llvm-lto2 * `-opt-remarks-passes` to gold-plugin Differential Revision: https://reviews.llvm.org/D59268 Original llvm-svn: 355964 llvm-svn: 355984
2019-03-13 05:22:27 +08:00
// CHECK-EQ-PASSES: "-cc1"
// CHECK-EQ-PASSES: "-opt-record-passes" "inline"
// CHECK-FOPT-DISABLE-PASSES-NOT: "-fno-save-optimization-record"
[Remarks] Extend -fsave-optimization-record to specify the format Use -fsave-optimization-record=<format> to specify a different format than the default, which is YAML. For now, only YAML is supported. llvm-svn: 363573
2019-06-18 00:06:00 +08:00
// CHECK-EQ-FORMAT: "-cc1"
[Remarks][Driver] Use the specified format in the remarks file extension By default, use `.opt.yaml`, but when a format is specified with `-fsave-optimization-record=<format>`, use `.opt.<format>`. llvm-svn: 363627
2019-06-18 06:49:38 +08:00
// CHECK-EQ-FORMAT: "-opt-record-file" "FOO.opt.some-format"
[Remarks] Extend -fsave-optimization-record to specify the format Use -fsave-optimization-record=<format> to specify a different format than the default, which is YAML. For now, only YAML is supported. llvm-svn: 363573
2019-06-18 00:06:00 +08:00
// CHECK-EQ-FORMAT: "-opt-record-format" "some-format"
// CHECK-FOPT-DISABLE-FORMAT-NOT: "-fno-save-optimization-record"
[clang] Pass-through remarks options to linker Summary: Propagate driver commandline remarks options to linker when LTO is enabled. This gives novice user a convenient way to collect and filter remarks throughout a typical toolchain invocation with sample profile and LTO using single switch from the clang driver. A typical use of this option from clang command-line: * Using -Rpass* options to print remarks to screen: clang -fuse-ld=lld -flto=thin -fprofile-sample-use=foo_sample.txt -Rpass=inline -Rpass-missed=inline -Rpass-analysis=inline -fdiagnostics-show-hotness -fdiagnostics-hotness-threshold=100 -o foo foo.cpp Remarks will be dumped to screen from both pre-lto and lto compilation. * Using serialized remarks options clang -fuse-ld=lld -flto=thin -fprofile-sample-use=foo_sample.txt -fsave-optimization-record -fdiagnostics-show-hotness -fdiagnostics-hotness-threshold=100 -o foo foo.cpp This will produce multiple yaml files containing optimization remarks: 1. foo.opt.yaml : remarks from pre-lto 2. foo.opt.ld.yaml.thin.1.yaml: remark during lto Differential Revision: https://reviews.llvm.org/D85810
2020-10-28 08:11:26 +08:00
// Test remarks options pass-through
// No pass-through: lto is disabled
// RUN: %clang -target x86_64 -### -o FOO -fdiagnostics-hotness-threshold=100 -fsave-optimization-record %s 2>&1 | FileCheck %s -check-prefix=CHECK-NOPASS
// Pass-through:
// RUN: %clang -target x86_64-linux -### -fuse-ld=lld -flto -fdiagnostics-hotness-threshold=100 -fsave-optimization-record -foptimization-record-passes=inline %s 2>&1 | FileCheck %s -check-prefix=CHECK-PASS-A
// RUN: %clang -target x86_64-linux -### -o FOO -fuse-ld=gold -flto -fdiagnostics-hotness-threshold=100 -fsave-optimization-record -foptimization-record-passes=inline %s 2>&1 | FileCheck %s -check-prefix=CHECK-PASS
// RUN: %clang -target x86_64-linux -### -o FOO -fuse-ld=lld -flto=thin -fdiagnostics-hotness-threshold=100 -fsave-optimization-record=some-format -foptimization-record-file=FOO.txt %s 2>&1 | FileCheck %s -check-prefix=CHECK-PASS-CUSTOM
// RUN: %clang -target x86_64-linux -### -o FOO -fuse-ld=lld -flto=thin -fdiagnostics-hotness-threshold=100 -Rpass=inline -Rpass-missed=inline -Rpass-analysis=inline %s 2>&1 | FileCheck %s -check-prefix=CHECK-PASS-RPASS
[Remarks][2/2] Expand remarks hotness threshold option support in more tools This is the #2 of 2 changes that make remarks hotness threshold option available in more tools. The changes also allow the threshold to sync with hotness threshold from profile summary with special value 'auto'. This change expands remarks hotness threshold option -fdiagnostics-hotness-threshold in clang and *-remarks-hotness-threshold in other tools to utilize hotness threshold from profile summary. Remarks hotness filtering relies on several driver options. Table below lists how different options are correlated and affect final remarks outputs: | profile | hotness | threshold | remarks printed | |---------|---------|-----------|-----------------| | No | No | No | All | | No | No | Yes | None | | No | Yes | No | All | | No | Yes | Yes | None | | Yes | No | No | All | | Yes | No | Yes | None | | Yes | Yes | No | All | | Yes | Yes | Yes | >=threshold | In the presence of profile summary, it is often more desirable to directly use the hotness threshold from profile summary. The new argument value 'auto' indicates threshold will be synced with hotness threshold from profile summary during compilation. The "auto" threshold relies on the availability of profile summary. In case of missing such information, no remarks will be generated. Differential Revision: https://reviews.llvm.org/D85808
2020-11-18 02:43:02 +08:00
// RUN: %clang -target x86_64-linux -### -o FOO -fuse-ld=lld -flto=thin -fdiagnostics-hotness-threshold=auto -Rpass=inline -Rpass-missed=inline -Rpass-analysis=inline %s 2>&1 | FileCheck %s -check-prefix=CHECK-PASS-AUTO
[clang] Pass-through remarks options to linker Summary: Propagate driver commandline remarks options to linker when LTO is enabled. This gives novice user a convenient way to collect and filter remarks throughout a typical toolchain invocation with sample profile and LTO using single switch from the clang driver. A typical use of this option from clang command-line: * Using -Rpass* options to print remarks to screen: clang -fuse-ld=lld -flto=thin -fprofile-sample-use=foo_sample.txt -Rpass=inline -Rpass-missed=inline -Rpass-analysis=inline -fdiagnostics-show-hotness -fdiagnostics-hotness-threshold=100 -o foo foo.cpp Remarks will be dumped to screen from both pre-lto and lto compilation. * Using serialized remarks options clang -fuse-ld=lld -flto=thin -fprofile-sample-use=foo_sample.txt -fsave-optimization-record -fdiagnostics-show-hotness -fdiagnostics-hotness-threshold=100 -o foo foo.cpp This will produce multiple yaml files containing optimization remarks: 1. foo.opt.yaml : remarks from pre-lto 2. foo.opt.ld.yaml.thin.1.yaml: remark during lto Differential Revision: https://reviews.llvm.org/D85810
2020-10-28 08:11:26 +08:00
// CHECK-NOPASS-NOT: "--plugin-opt=opt-remarks-filename="
// CHECK-NOPASS-NOT: "--plugin-opt=opt-remarks-passes=inline"
// CHECK-NOPASS-NOT: "--plugin-opt=opt-remarks-format=yaml"
// CHECK-NOPASS-NOT: "--plugin-opt=opt-remarks-hotness-threshold=100"
// CHECK-PASS-A: "--plugin-opt=opt-remarks-filename=a.out.opt.ld.yaml"
// CHECK-PASS-A-SAME: "--plugin-opt=opt-remarks-passes=inline"
// CHECK-PASS-A-SAME: "--plugin-opt=opt-remarks-format=yaml"
// CHECK-PASS-A-SAME: "--plugin-opt=opt-remarks-hotness-threshold=100"
// CHECK-PASS: "--plugin-opt=opt-remarks-filename=FOO.opt.ld.yaml"
// CHECK-PASS-SAME: "--plugin-opt=opt-remarks-passes=inline"
// CHECK-PASS-SAME: "--plugin-opt=opt-remarks-format=yaml"
// CHECK-PASS-SAME: "--plugin-opt=opt-remarks-hotness-threshold=100"
// CHECK-PASS-CUSTOM: "--plugin-opt=opt-remarks-filename=FOO.txt.opt.ld.some-format"
// CHECK-PASS-CUSTOM-SAME: "--plugin-opt=opt-remarks-format=some-format"
// CHECK-PASS-CUSTOM-SAME: "--plugin-opt=opt-remarks-hotness-threshold=100"
// CHECK-PASS-RPASS: "--plugin-opt=-pass-remarks=inline"
// CHECK-PASS-RPASS-SAME: "--plugin-opt=-pass-remarks-missed=inline"
// CHECK-PASS-RPASS-SAME: "--plugin-opt=-pass-remarks-analysis=inline"
// CHECK-PASS-RPASS-SAME: "--plugin-opt=opt-remarks-hotness-threshold=100"
[Remarks][2/2] Expand remarks hotness threshold option support in more tools This is the #2 of 2 changes that make remarks hotness threshold option available in more tools. The changes also allow the threshold to sync with hotness threshold from profile summary with special value 'auto'. This change expands remarks hotness threshold option -fdiagnostics-hotness-threshold in clang and *-remarks-hotness-threshold in other tools to utilize hotness threshold from profile summary. Remarks hotness filtering relies on several driver options. Table below lists how different options are correlated and affect final remarks outputs: | profile | hotness | threshold | remarks printed | |---------|---------|-----------|-----------------| | No | No | No | All | | No | No | Yes | None | | No | Yes | No | All | | No | Yes | Yes | None | | Yes | No | No | All | | Yes | No | Yes | None | | Yes | Yes | No | All | | Yes | Yes | Yes | >=threshold | In the presence of profile summary, it is often more desirable to directly use the hotness threshold from profile summary. The new argument value 'auto' indicates threshold will be synced with hotness threshold from profile summary during compilation. The "auto" threshold relies on the availability of profile summary. In case of missing such information, no remarks will be generated. Differential Revision: https://reviews.llvm.org/D85808
2020-11-18 02:43:02 +08:00
// CHECK-PASS-AUTO: "--plugin-opt=opt-remarks-hotness-threshold=auto"