aboutsummaryrefslogtreecommitdiff
path: root/bolt/lib/Passes/CacheMetrics.cpp
AgeCommit message (Collapse)AuthorFilesLines
2024-05-22[BOLT][NFC] Eliminate uses of throwing std::map::at (#92950)shaw young1-10/+33
Remove calls to std::unordered_map::at, std::map::at, and std::vector::at.
2024-02-12[BOLT][NFC] Log through JournalingStreams (#81524)Amir Ayupov1-19/+20
Make core BOLT functionality more friendly to being used as a library instead of in our standalone driver llvm-bolt. To accomplish this, we augment BinaryContext with journaling streams that are to be used by most BOLT code whenever something needs to be logged to the screen. Users of the library can decide if logs should be printed to a file, no file or to the screen, as before. To illustrate this, this patch adds a new option `--log-file` that allows the user to redirect BOLT logging to a file on disk or completely hide it by using `--log-file=/dev/null`. Future BOLT code should now use `BinaryContext::outs()` for printing important messages instead of `llvm::outs()`. A new test log.test enforces this by verifying that no strings are print to screen once the `--log-file` option is used. In previous patches we also added a new BOLTError class to report common and fatal errors, so code shouldn't call exit(1) now. To easily handle problems as before (by quitting with exit(1)), callers can now use `BinaryContext::logBOLTErrorsAndQuitOnFatal(Error)` whenever code needs to deal with BOLT errors. To test this, we have fatal.s that checks we are correctly quitting and printing a fatal error to the screen. Because this is a significant change by itself, not all code was yet ported. Code from Profiler libs (DataAggregator and friends) still print errors directly to screen. Co-authored-by: Rafael Auler <rafaelauler@fb.com> Test Plan: NFC
2024-01-12[BOLT] Fix double conversion in CacheMetrics (#75253)spupyrev1-18/+15
The change (i) fixes an issue with double-int conversion in CacheMetrics and (ii) removes command-line options for computing metrics (which aren't modified anyway). This change might break some tests verifying the exact output of CacheMetrics.
2022-09-19[BOLT] Unifying implementations of ext-tspspupyrev1-72/+18
After BOLT's merge to LLVM, there are two (almost identical) versions of the code layout algorithm. The diff unifies the implementations by keeping the one in LLVM. There are mild changes in the resulting block orders. I tested the changes extensively both on the clang binary and on prod services. Didn't see stat sig differences on average. Reviewed By: Amir Differential Revision: https://reviews.llvm.org/D129895
2022-08-24[BOLT] Towards FunctionLayout const-correctnessFabian Parzefall1-2/+2
A const-qualified reference to function layout allows accessing non-const qualified basic blocks on a const-qualified function. This patch adds or removes const-qualifiers where necessary to indicate where basic blocks are used in a non-const manner. Reviewed By: rafauler Differential Revision: https://reviews.llvm.org/D132049
2022-08-24Revert "[BOLT] Towards FunctionLayout const-correctness"Fabian Parzefall1-2/+2
This reverts commit 587d2653420d75ef10f30bd612d86f1e08fe9ea7.
2022-08-24[BOLT] Towards FunctionLayout const-correctnessFabian Parzefall1-2/+2
A const-qualified reference to function layout allows accessing non-const qualified basic blocks on a const-qualified function. This patch adds or removes const-qualifiers where necessary to indicate where basic blocks are used in a non-const manner. Reviewed By: rafauler Differential Revision: https://reviews.llvm.org/D132049
2022-07-16[BOLT] Add function layout classFabian Parzefall1-7/+8
This patch adds a dedicated class to keep track of each function's layout. It also lays the groundwork for splitting functions into multiple fragments (as opposed to a strict hot/cold split). Reviewed By: maksfb Differential Revision: https://reviews.llvm.org/D129518
2022-07-14[BOLT] Replace uses of layout with basic block listFabian Parzefall1-20/+22
As we are moving towards support for multiple fragments, loops that iterate over all basic blocks of a function, but do not depend on the order of basic blocks in the final layout, should iterate over binary functions directly, rather than the layout. Eventually, all loops using the layout list should either iterate over the function, or be aware of multiple layouts. This patch replaces references to binary function's block layout with the binary function itself where only little code changes are necessary. Reviewed By: maksfb Differential Revision: https://reviews.llvm.org/D129585
2021-12-28[BOLT][NFC] Fix braces usage in PassesAmir Ayupov1-4/+2
Summary: Refactor bolt/*/Passes to follow the braces rule for if/else/loop from [LLVM Coding Standards](https://llvm.org/docs/CodingStandards.html). (cherry picked from FBD33344642)
2021-12-21[BOLT][NFC] Fix file-description commentsMaksim Panchenko1-2/+3
Summary: Fix comments at the start of source files. (cherry picked from FBD33274597)
2021-12-14[BOLT][NFC] Reformat with clang-formatMaksim Panchenko1-42/+38
Summary: Selectively apply clang-format to BOLT code base. (cherry picked from FBD33119052)
2021-10-08Rebase: [NFC] Refactor sources to be buildable in shared modeRafael Auler1-0/+316
Summary: Moves source files into separate components, and make explicit component dependency on each other, so LLVM build system knows how to build BOLT in BUILD_SHARED_LIBS=ON. Please use the -c merge.renamelimit=230 git option when rebasing your work on top of this change. To achieve this, we create a new library to hold core IR files (most classes beginning with Binary in their names), a new library to hold Utils, some command line options shared across both RewriteInstance and core IR files, a new library called Rewrite to hold most classes concerned with running top-level functions coordinating the binary rewriting process, and a new library called Profile to hold classes dealing with profile reading and writing. To remove the dependency from BinaryContext into X86-specific classes, we do some refactoring on the BinaryContext constructor to receive a reference to the specific backend directly from RewriteInstance. Then, the dependency on X86 or AArch64-specific classes is transfered to the Rewrite library. We can't have the Core library depend on targets because targets depend on Core (which would create a cycle). Files implementing the entry point of a tool are transferred to the tools/ folder. All header files are transferred to the include/ folder. The src/ folder was renamed to lib/. (cherry picked from FBD32746834)