| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Function names in ObjC can have spaces in them. This interacts poorly
with name compression, which uses spaces to separate PGO names. Fix the
issue by using a different separator and update a test.
I chose "\01" as the separator because 1) it's non-printable, 2) we
strip it from PGO names, and 3) it's the next natural choice once "\00"
is discarded (that one's overloaded).
This reverts the revert commit beaf3d18. What's changed?
- I fixed up the covmap-V2 binary format tests using a linux VM.
- I updated the expected counts in instrprof-comdat.h to account for
the fact that there have been bugfixes to clang coverage.
- I added an assert to make sure we don't get bitten by this again.
Differential Revision: http://reviews.llvm.org/D18516
llvm-svn: 264641
|
|
|
|
|
|
|
|
|
| |
This reverts commit r264587. Reverting to investigate 6 unexpected
failures on the ppc bot:
http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/2822
llvm-svn: 264590
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Function names in ObjC can have spaces in them. This interacts poorly
with name compression, which uses spaces to separate PGO names. Fix the
issue by using a different separator and update a test.
I chose "\01" as the separator because 1) it's non-printable, 2) we
strip it from PGO names, and 3) it's the next natural choice once "\00"
is discarded (that one's overloaded).
Differential Revision: http://reviews.llvm.org/D18516
llvm-svn: 264587
|
|
|
|
|
|
| |
Patch suggested by David Li!
llvm-svn: 264586
|
|
|
|
|
|
|
|
|
| |
When emitting coverage mappings for functions with local linkage and an
unknown filename, we use "<unknown>:func" for the PGO function name. The
problem is that we don't strip "<unknown>" from the name when loading
coverage data, like we do for other file names. Fix that and add a test.
llvm-svn: 264559
|
|
|
|
| |
llvm-svn: 263666
|
|
|
|
|
|
|
|
|
|
|
| |
The swift frontend needs to be able to look up PGO function name
variables based on the original raw function name. That's because it's
not possible to create PGO function name variables while emitting swift
IR. Instead, we have to create the name variables while lowering swift
IR to llvm IR, at which point we fix up all calls to the increment
intrinsic to point to the right name variable.
llvm-svn: 263662
|
|
|
|
|
|
|
|
| |
Since the static getGlobalIdentifier and getGUID methods are now called
for global values other than functions, reflect that by moving these
methods to the GlobalValue class.
llvm-svn: 263524
|
|
|
|
|
|
|
|
|
| |
Add another interface to function annotateValueSite() which directly uses the
VauleData array.
Differential Revision: http://reviews.llvm.org/D17108
llvm-svn: 260741
|
|
|
|
|
|
|
|
|
|
| |
The patch adds a parameter in annotateValueSite() to control the max number
of records written to the value profile meta data for each value site. The
default is kept as the current value of 3.
Differential Revision: http://reviews.llvm.org/D17084
llvm-svn: 260450
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Move the function renaming logic into the Function class, and the
MD5Hash routine into the MD5 header.
This will enable these routines to be shared with ThinLTO, which
will be changed to store the MD5 hash instead of full function name
in the combined index for significant size reductions. And using the same
function naming for locals in the function index facilitates future
integration with indirect call value profiles.
Reviewers: davidxl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17006
llvm-svn: 260197
|
|
|
|
| |
llvm-svn: 259851
|
|
|
|
|
|
|
|
|
|
| |
Summary computation is not just for instrumented profiling and so I have moved
the ProfileSummary class to ProfileCommon.h (named so to allow code unrelated
to summary but common to instrumented and sampled profiling to be placed there)
Differential Revision: http://reviews.llvm.org/D16661
llvm-svn: 259846
|
|
|
|
|
|
|
| |
Add interfaces to do value profile data IR annnotation
and read. Needed by both FE and IR based PGO.
llvm-svn: 259813
|
|
|
|
|
|
|
| |
- Remove unused valuemapper parameter
- add totalcount optional parameter
llvm-svn: 259756
|
|
|
|
| |
llvm-svn: 259630
|
|
|
|
|
|
|
|
|
|
| |
With this patch, the profile summary data will be available in indexed
profile data file so that profiler reader/compiler optimizer can start
to make use of.
Differential Revision: http://reviews.llvm.org/D16258
llvm-svn: 259626
|
|
|
|
| |
llvm-svn: 258876
|
|
|
|
|
|
|
|
| |
other minor fixes.
Differential revision: reviews.llvm.org/D16568
llvm-svn: 258831
|
|
|
|
| |
llvm-svn: 258271
|
|
|
|
| |
llvm-svn: 257819
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add SaturatingMultiplyAdd convenience function template since A + (X * Y) comes up frequently when doing weighted arithmetic.
Reviewers: davidxl, silvas
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15385
llvm-svn: 257532
|
|
|
|
|
|
|
|
|
|
| |
For a new record with weight != 1, only edge profiling
counters are scaled, VP data is not properly scaled.
This patch refactors the code and fixes the problem.
Also added sort by count interface (for follow up patch).
llvm-svn: 257143
|
|
|
|
|
|
| |
Patch Suggested by Vedant.
llvm-svn: 256785
|
|
|
|
|
|
|
| |
For readability and code sharing.
(Adapted from Suggestions by Vedant).
llvm-svn: 256784
|
|
|
|
| |
llvm-svn: 256781
|
|
|
|
|
|
| |
linear)
llvm-svn: 256776
|
|
|
|
| |
llvm-svn: 256695
|
|
|
|
|
|
|
|
|
|
| |
This is part of the effort/prepration to reduce the size
instr-pgo (object, binary, memory footprint, and raw data).
The functionality is currently off by default and not yet
used by any clients.
llvm-svn: 256667
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the support of value profiling added, the Indexed prof
reader gets less efficient. The prof reader initialization
used to be just reading the file header, but with VP support
added, initialization needs to walk through all profile keys
of ondisk hash table resulting in very poor locality and large
memory increase (keys are stored together with the profile data
in the mapped profile buffer). Even worse, when the reader is
used by the compiler (not llvm-profdata too), the penalty becomes
very high as compilation of each single module requires touching
profile data buffer for the whole program.
In this patch, the icall target values (MD5hash) are no longer eargerly
converted back to name strings when the data is read into memory. New
interface is added to to profile reader so that InstrProfSymtab can be
lazily created for Indexed profile reader on-demand. Creating of the
symtab is intended to be used by llvm-profdata tool for symbolic dumping
of VP data. It can be used with compiler (for legacy out of tree uses)
too but not recommended due to compile time and memory reasons
mentioned above.
Some other cleanups are also included: Function Addr to md5 map is now
consolated into InstrProfSymtab. InstrProfStringtab is no longer used and
eliminated.
llvm-svn: 256114
|
|
|
|
| |
llvm-svn: 256113
|
|
|
|
| |
llvm-svn: 256058
|
|
|
|
| |
llvm-svn: 256047
|
|
|
|
| |
llvm-svn: 255680
|
|
|
|
| |
llvm-svn: 255670
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before the patch, -fprofile-instr-generate compile will fail
if no integrated-as is specified when the file contains
any static functions (the -S output is also invalid).
This is the second try. The fix in this patch is very localized.
Only profile symbol names of profile symbols with internal
linkage are fixed up while initializer of name syms are not
changes. This means there is no format change nor version bump.
llvm-svn: 255434
|
|
|
|
| |
llvm-svn: 255369
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before the patch, -fprofile-instr-generate compile will fail
if no integrated-as is specified when the file contains
any static functions (the -S output is also invalid).
This patch fixed the issue. With the change, the index format
version will be bumped up by 1. Backward compatibility is
preserved with this change.
Differential Revision: http://reviews.llvm.org/D15243
llvm-svn: 255365
|
|
|
|
|
|
|
|
|
| |
Different version of indexed format may use different
name uniquing schemes for static functions. Pass the
version info to the name interface so that different
schmes can be picked (for profile lookup).
llvm-svn: 254838
|
|
|
|
| |
llvm-svn: 254447
|
|
|
|
|
|
|
|
|
|
| |
This is the last step to enable profile runtime to share the same value prof
data format and reader/writer code with llvm host tools. The VP related
data structures are moved to a section in InstrProfData.inc enabled with macro
INSTR_PROF_VALUE_PROF_DATA, and common API implementations are enabled with
INSTR_PROF_COMMON_API_IMPL. There should be no functional change.
llvm-svn: 254235
|
|
|
|
| |
llvm-svn: 254220
|
|
|
|
|
|
|
|
|
| |
Raw profile writer needs to write all data of one kind in one continuous block,
so the buffer needs to be pre-allocated and passed to the writer method in
pieces for function profile data. The change adds the support for raw value data
writing.
llvm-svn: 254219
|
|
|
|
| |
llvm-svn: 254217
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is one of the many steps to commonize value profiling support between profile
runtime and compiler/llvm tools.
After this change, profiler runtime now can share the same C APIs to do VP
serialization/deseriazation with LLVM host tools (and produces value data
in identical format between indexed and raw profile).
It is not yet enabled in profiler runtime yet.
Also added a unit test case to test runtime profile data serialization/deserialization
interfaces implemented using common closure code.
llvm-svn: 254110
|
|
|
|
| |
llvm-svn: 254080
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
methods
1. Convert serialization methods using InstrProfRecord as source into C (impl)
interfaces using Closure.
2. Reimplement InstrProfRecord serialization method to use new C interface
as dummy wrapper.
Now it is ready to implement wrapper for runtime value profile data.
(The new code need better source location -- but not changed in this patch to
minimize diffs. )
llvm-svn: 254057
|
|
|
|
| |
llvm-svn: 254056
|
|
|
|
| |
llvm-svn: 254055
|
|
|
|
| |
llvm-svn: 254045
|