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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355984 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355964 91177308-0d34-0410-b5e6-96231b3b80d8
Current PGO profile counts are not context sensitive. The branch probabilities
for the inlined functions are kept the same for all call-sites, and they might
be very different from the actual branch probabilities. These suboptimal
profiles can greatly affect some downstream optimizations, in particular for
the machine basic block placement optimization.
In this patch, we propose to have a post-inline PGO instrumentation/use pass,
which we called Context Sensitive PGO (CSPGO). For the users who want the best
possible performance, they can perform a second round of PGO instrument/use on
the top of the regular PGO. They will have two sets of profile counts. The
first pass profile will be manly for inline, indirect-call promotion, and
CGSCC simplification pass optimizations. The second pass profile is for
post-inline optimizations and code-gen optimizations.
A typical usage:
// Regular PGO instrumentation and generate pass1 profile.
> clang -O2 -fprofile-generate source.c -o gen
> ./gen
> llvm-profdata merge default.*profraw -o pass1.profdata
// CSPGO instrumentation.
> clang -O2 -fprofile-use=pass1.profdata -fcs-profile-generate -o gen2
> ./gen2
// Merge two sets of profiles
> llvm-profdata merge default.*profraw pass1.profdata -o profile.profdata
// Use the combined profile. Pass manager will invoke two PGO use passes.
> clang -O2 -fprofile-use=profile.profdata -o use
This change touches many components in the compiler. The reviewed patch
(D54175) will committed in phrases.
Differential Revision: https://reviews.llvm.org/D54175
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354930 91177308-0d34-0410-b5e6-96231b3b80d8
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@351636 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Sometimes it's useful to emit assembly after LTO stage to modify it manually. Emitting precodegen bitcode file (via save-temps plugin option) and then feeding it to llc doesn't always give the same binary as original.
This patch is simpler alternative to https://reviews.llvm.org/D24020.
Patch by Denis Bakhvalov.
Reviewers: mehdi_amini, tejohnson
Reviewed By: tejohnson
Subscribers: MaskRay, inglorion, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D56114
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350276 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
r336838 allowed these to be toggleable.
r336858 reverted r336838.
r336943 made the generation of these sections conditional on LDPO_REL.
This commit brings back the toggle-ability. You can specify:
-plugin-opt=-function-sections
-plugin-opt=-data-sections
For your linker flags to disable the changes made in r336943.
Without toggling r336943 off, arm64 linux kernels linked with gold-plugin
see significant boot time regressions, but with r336943 outright reverted
x86_64 linux kernels linked with gold-plugin fail to boot.
Reviewers: pcc, void
Reviewed By: pcc
Subscribers: javed.absar, kristof.beyls, llvm-commits, srhines
Differential Revision: https://reviews.llvm.org/D55291
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@348389 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This is to be consistent with lld behavior since rLLD340364.
Reviewers: tejohnson
Reviewed By: tejohnson
Subscribers: steven_wu, eraman, mehdi_amini, inglorion, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D51060
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@340380 91177308-0d34-0410-b5e6-96231b3b80d8
Not all programs want section ordering when compiled with LTO.
In particular, the Linux kernel is very sensitive when it comes to linking, and
doesn't boot when each function is placed in its own sections.
Reviewed By: pcc
Differential Revision: https://reviews.llvm.org/D48756
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@336943 91177308-0d34-0410-b5e6-96231b3b80d8
Some programs (e.g. Linux) aren't able to handle function/data sections when
LTO is used. Thus they need a way to disable it. That can be done with these
plugin options:
-plugin-opt=-function-sections=0
-plugin-opt=-data-sections=0
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@336838 91177308-0d34-0410-b5e6-96231b3b80d8
I don't know how to build this code, but based on the failing
buildbot error message it looks like this change should get
the buildbot up and running again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@334231 91177308-0d34-0410-b5e6-96231b3b80d8
With the upcoming patch to add summary parsing support, IsAnalysis would
be true in contexts where we are not performing module summary analysis.
Rename to the more specific and approprate HaveGVs, which is essentially
what this flag is indicating.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@334140 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Instead of manually invoking PrintStatistics, simply invoke
llvm_shutdown which will take care of destroying managed statics, and as
a side effect will destroy the StatisticInfo ManagedStatic, invoking
PrintStatistics when needed.
Reviewers: fhahn
Subscribers: inglorion, llvm-commits
Differential Revision: https://reviews.llvm.org/D45820
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330341 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This enables debug fission on implicit ThinLTO when linked with gold. It will put the .dwo files in a directory specified by user.
Reviewers: tejohnson, pcc, dblaikie
Reviewed By: pcc
Subscribers: JDevlieghere, mehdi_amini, inglorion
Differential Revision: https://reviews.llvm.org/D44792
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@329988 91177308-0d34-0410-b5e6-96231b3b80d8
These aren't the .def style files used in LLVM that require a macro
defined before their inclusion - they're just basic non-modular includes
to stamp out command line flag variables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@329840 91177308-0d34-0410-b5e6-96231b3b80d8
It was reported that this change measurably regressed -plugin-opt=O3
performance.
There is an ongoing discussion on llvm-dev about the correct way to
set the CG opt level, see thread "[llvm-dev] [RFC] Adding function
attributes to represent codegen optimization level".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@329458 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
(Restores r327459 with handling for old plugin-api.h)
Utilize new gold plugin api interface for obtaining --wrap option
arguments, and LTO API handling (added for --wrap support in lld LTO),
to mark symbols so that LTO does not optimize them inappropriately.
Note the test cases will be in a new gold test subdirectory that
is dependent on the next release of gold which will contain the new
interfaces.
Reviewers: pcc, tmsriram
Subscribers: mehdi_amini, llvm-commits, inglorion
Differential Revision: https://reviews.llvm.org/D44235
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327506 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Utilize new gold plugin api interface for obtaining --wrap option
arguments, and LTO API handling (added for --wrap support in lld LTO),
to mark symbols so that LTO does not optimize them inappropriately.
Note the test cases will be in a new gold test subdirectory that
is dependent on the next release of gold which will contain the new
interfaces.
Reviewers: pcc, tmsriram
Subscribers: mehdi_amini, llvm-commits, inglorion
Differential Revision: https://reviews.llvm.org/D44235
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327459 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
As pointed out in the review for D37993, for consistency with other
linkers, gold plugin should perform cache pruning whenever there is a
cache directory specified, which will use the default cache policy.
Reviewers: pcc
Subscribers: llvm-commits, inglorion
Differential Revision: https://reviews.llvm.org/D43389
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325830 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
ThinLTO indexing may decide to skip all objects. If we don't write something to
the list build system may consider this as failure or linker can reuse a file
from the previews build.
Reviewers: pcc, tejohnson
Subscribers: mehdi_amini, inglorion, eraman, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D43415
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325819 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This will avoid the race condition described in the review for D37993.
I believe that the Path parameter to AddBufferFn is no longer utilized.
I would prefer to remove that as a follow up clean up patch to reduce
the diffs in this patch.
Reviewers: pcc
Reviewed By: pcc
Subscribers: inglorion, llvm-commits
Differential Revision: https://reviews.llvm.org/D43396
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325618 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Gold plugin does not add pass to ThinLTO modules without useful symbols.
In this case ThinLTO can't create corresponding index file and some features, like CFI,
cannot be processes by backed correctly without index.
Given that we don't need the backed output we can request it to avoid
processing the module. This is implemented by this patch using new
"SkipModuleByDistributedBackend" flag.
Reviewers: pcc, tejohnson
Subscribers: mehdi_amini, inglorion, eraman, cfe-commits
Differential Revision: https://reviews.llvm.org/D42995
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325411 91177308-0d34-0410-b5e6-96231b3b80d8
The LTO opt level should not affect the codegen opt level, and indeed
it does not affect it in lld. Ideally the codegen opt level should
be controlled by an IR-level attribute based on the compile-time opt
level, but that hasn't been implemented yet.
Differential Revision: https://reviews.llvm.org/D43040
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324557 91177308-0d34-0410-b5e6-96231b3b80d8
Since this isn't a real header - it includes static functions and had
external linkage variables (though this change makes them static, since
that's what they should be) so can't be included more than once in a
program.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319082 91177308-0d34-0410-b5e6-96231b3b80d8
This is both a potential security issue and a potential functionality
issue because we create temporary files from multiple threads. Use
the safe version of createTemporaryFile instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@310636 91177308-0d34-0410-b5e6-96231b3b80d8
This is needed, among others, to respect --section-ordering-file
with LTO. I'll follow up with a similar change for data sections.
I hope every version of gold available on the bots has support for
--section-ordering file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@309056 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
ELF linkers generate __start_<secname> and __stop_<secname> symbols
when there is a value in a section <secname> where the name is a valid
C identifier. If dead stripping determines that the values declared
in section <secname> are dead, and we then internalize (and delete)
such a symbol, programs that reference the corresponding start and end
section symbols will get undefined reference linking errors.
To fix this, add the section name to the IRSymtab entry when a symbol is
defined in a specific section. Then use this in the gold-plugin to mark
the symbol as external and visible from outside the summary when the
section name is a valid C identifier.
Reviewers: pcc
Subscribers: mehdi_amini, inglorion, eraman, llvm-commits
Differential Revision: https://reviews.llvm.org/D35639
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@309009 91177308-0d34-0410-b5e6-96231b3b80d8
Francis Visoiu Mistrih