summaryrefslogtreecommitdiffstats
path: root/llvm/tools/llvm-opt-report
Commit message (Collapse)AuthorAgeFilesLines
* [llvm-opt-report] Improve error handlingFrancis Visoiu Mistrih2019-09-131-3/+5
| | | | | | | | * std::move the error extracted from the parsing creation to avoid asserts * print a newline after the error message * create the parser from the metadata llvm-svn: 371895
* Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2019-08-051-2/+1
| | | | | | F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
* [Remarks][NFC] Rename remarks::Parser to remarks::RemarkParserFrancis Visoiu Mistrih2019-07-251-2/+2
| | | | llvm-svn: 366965
* [Remarks] Simplify the creation of remark serializersFrancis Visoiu Mistrih2019-07-241-3/+16
| | | | | | | Introduce two new functions to create a serializer, and add support for more combinations to the YAMLStrTabSerializer. llvm-svn: 366919
* [Remarks] Simplify and refactor the RemarkParser interfaceFrancis Visoiu Mistrih2019-07-161-7/+19
| | | | | | | | | | | | | | | | | | | | Before, everything was based on some kind of type erased parser implementation which container a lot of boilerplate code when multiple formats were to be supported. This simplifies it by: * the remark now owns its arguments * *always* returning an error from the implementation side * working around the way the YAML parser reports errors: catch them through callbacks and re-insert them in a proper llvm::Error * add a CParser wrapper that is used when implementing the C API to avoid cluttering the C++ API with useless state * LLVMRemarkParserGetNext now returns an object that needs to be released to avoid leaking resources * add a new API to dispose of a remark entry: LLVMRemarkEntryDispose llvm-svn: 366217
* [Remarks][NFC] Combine ParserFormat and SerializerFormatFrancis Visoiu Mistrih2019-07-161-1/+1
| | | | | | It's useless to have both. llvm-svn: 366216
* [Remarks] Require an explicit format to the parserFrancis Visoiu Mistrih2019-07-041-1/+1
| | | | | | | | | Make the parser require an explicit format. This allows new formats to be easily added by following YAML as an example. llvm-svn: 365102
* [CommandLineParser] Add DefaultOption flagDon Hinton2019-04-151-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add DefaultOption flag to CommandLineParser which provides a default option or alias, but allows users to override it for some other purpose as needed. Also, add `-h` as a default alias to `-help`, which can be seamlessly overridden by applications like llvm-objdump and llvm-readobj which use `-h` as an alias for other options. (relanding after revert, r358414) Added DefaultOptions.clear() to reset(). Reviewers: alexfh, klimek Reviewed By: klimek Subscribers: kristina, MaskRay, mehdi_amini, inglorion, dexonsmith, hiraditya, llvm-commits, jhenderson, arphaman, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D59746 llvm-svn: 358428
* Revert r358337: "[CommandLineParser] Add DefaultOption flag"Ilya Biryukov2019-04-151-0/+7
| | | | | | | The change causes test failures under asan. Reverting to unbreak our integrate. llvm-svn: 358414
* [CommandLineParser] Add DefaultOption flagDon Hinton2019-04-131-7/+0
| | | | | | | | | | | | | | | | | | | | | | Summary: Add DefaultOption flag to CommandLineParser which provides a default option or alias, but allows users to override it for some other purpose as needed. Also, add `-h` as a default alias to `-help`, which can be seamlessly overridden by applications like llvm-objdump and llvm-readobj which use `-h` as an alias for other options. Reviewers: alexfh, klimek Reviewed By: klimek Subscribers: MaskRay, mehdi_amini, inglorion, dexonsmith, hiraditya, llvm-commits, jhenderson, arphaman, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D59746 llvm-svn: 358337
* Reland "[Remarks] Add a new Remark / RemarkParser abstraction"Francis Visoiu Mistrih2019-03-191-37/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a Remark class that allows us to share code when working with remarks. The C API has been updated to reflect this. Instead of the parser generating C structs, it's now using a C++ object that is used through opaque pointers in C. This gives us much more flexibility on what changes we can make to the internal state of the object and interacts much better with scenarios where the library is used through dlopen. * C API updates: * move from C structs to opaque pointers and functions * the remark type is now an enum instead of a string * unit tests updates: * use mostly the C++ API * keep one test for the C API * rename to YAMLRemarksParsingTest * a typo was fixed: AnalysisFPCompute -> AnalysisFPCommute. * a new error message was added: "expected a remark tag." * llvm-opt-report has been updated to use the C++ parser instead of the C API Differential Revision: https://reviews.llvm.org/D59049 Original llvm-svn: 356491 llvm-svn: 356519
* Revert "[Remarks] Add a new Remark / RemarkParser abstraction"Francis Visoiu Mistrih2019-03-191-37/+37
| | | | | | | | | This reverts commit 51dc6a8c84cd6a58562e320e1828a0158dbbf750. Breaks http://lab.llvm.org:8011/builders/clang-cmake-x86_64-sde-avx512-linux/builds/20034/steps/build%20stage%201/logs/stdio. llvm-svn: 356492
* [Remarks] Add a new Remark / RemarkParser abstractionFrancis Visoiu Mistrih2019-03-191-37/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a Remark class that allows us to share code when working with remarks. The C API has been updated to reflect this. Instead of the parser generating C structs, it's now using a C++ object that is used through opaque pointers in C. This gives us much more flexibility on what changes we can make to the internal state of the object and interacts much better with scenarios where the library is used through dlopen. * C API updates: * move from C structs to opaque pointers and functions * the remark type is now an enum instead of a string * unit tests updates: * use mostly the C++ API * keep one test for the C API * rename to YAMLRemarksParsingTest * a typo was fixed: AnalysisFPCompute -> AnalysisFPCommute. * a new error message was added: "expected a remark tag." * llvm-opt-report has been updated to use the C++ parser instead of the C API Differential Revision: https://reviews.llvm.org/D59049 llvm-svn: 356491
* [OptRemarks] Make OptRemarks more generic: rename OptRemarks to RemarksFrancis Visoiu Mistrih2019-03-052-11/+11
| | | | | | | | | | | | | | | Getting rid of the name "optimization remarks" for anything that involves handling remarks on the client side. It's safer to do this now, before we get stuck with that name in all the APIs and public interfaces we decide to export to users in the future. This renames llvm/tools/opt-remarks to llvm/tools/remarks-shlib, and now generates `libRemarks.dylib` instead of `libOptRemarks.dylib`. Differential Revision: https://reviews.llvm.org/D58535 llvm-svn: 355439
* Fix some include order and file headers issues. NFCFangrui Song2019-02-211-1/+1
| | | | llvm-svn: 354550
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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. llvm-svn: 351636
* [Support] Remove error return value from one overload of fs::make_absolutePavel Labath2019-01-161-7/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: The version of make_absolute which accepted a specific directory to use as the "base" for the computation could never fail, even though it returned a std::error_code. The reason for that seems to be historical -- the CWD flavour (which can fail due to failure to retrieve CWD) was there first, and the new version was implemented by extending that. This removes the error return value from the non-CWD overload and reimplements the CWD version on top of that. This enables us to remove some dead code where people were pessimistically trying to handle the errors returned from this function. Reviewers: zturner, sammccall Subscribers: hiraditya, kristina, llvm-commits Differential Revision: https://reviews.llvm.org/D56599 llvm-svn: 351317
* Reland: [OptRemarks] Add library for parsing optimization remarksFrancis Visoiu Mistrih2018-10-102-107/+39
| | | | | | | | | | | | | | | | | | | | | | | Add a library that parses optimization remarks (currently YAML, so based on the YAMLParser). The goal is to be able to provide tools a remark parser that is not completely dependent on YAML, in case we decide to change the format later. It exposes a C API which takes a handler that is called with the remark structure. It adds a libLLVMOptRemark.a static library, and it's used in-tree by the llvm-opt-report tool (from which the parser has been mostly moved out). Differential Revision: https://reviews.llvm.org/D52776 Fixed the tests by removing the usage of C++11 strings, which seems not to be supported by gcc 4.8.4 if they're used as a macro argument. llvm-svn: 344171
* Revert "[OptRemarks] Add library for parsing optimization remarks"Francis Visoiu Mistrih2018-10-102-39/+107
| | | | | | | | This reverts commit 1cc98e6672b6319fdb00b70dd4474aabdadbe193. Seems to break bots: http://lab.llvm.org:8011/builders/clang-x86_64-linux-abi-test/builds/33398/steps/build-unified-tree/logs/stdio llvm-svn: 344164
* [OptRemarks] Add library for parsing optimization remarksFrancis Visoiu Mistrih2018-10-102-107/+39
| | | | | | | | | | | | | | | | | | | | Add a library that parses optimization remarks (currently YAML, so based on the YAMLParser). The goal is to be able to provide tools a remark parser that is not completely dependent on YAML, in case we decide to change the format later. It exposes a C API which takes a handler that is called with the remark structure. It adds a libLLVMOptRemark.a static library, and it's used in-tree by the llvm-opt-report tool (from which the parser has been mostly moved out). Differential Revision: https://reviews.llvm.org/D52776 llvm-svn: 344162
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-011-1/+1
| | | | | | | | | | | | | | | | We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
* [tools] Use WithColor for printing errors.Jonas Devlieghere2018-04-211-12/+12
| | | | | | | Use convenience helpers in WithColor to print errors, warnings and notes in a few more tools. llvm-svn: 330524
* Define InitLLVM to do common initialization all at once.Rui Ueyama2018-04-131-5/+4
| | | | | | | | | | | We have a few functions that virtually all command wants to run on process startup/shutdown. This patch adds InitLLVM class to do that all at once, so that we don't need to copy-n-paste boilerplate code to each llvm command's main() function. Differential Revision: https://reviews.llvm.org/D45602 llvm-svn: 330046
* Don't call exit from cl::PrintHelpMessage.Rafael Espindola2017-09-071-1/+3
| | | | | | | | | Most callers were not expecting the exit(0) and trying to exit with a different value. This also adds back the call to cl::PrintHelpMessage in llvm-ar. llvm-svn: 312761
* [llvm-opt-report] Fix context-sensitive lines where nothing happenedHal Finkel2017-01-071-3/+11
| | | | | | | | | | | | | | | | | Don't print a line multiple times, each for different inlining contexts, if nothing happened in any context. This prevents situations like this: [[ > main: 65 | if ((i * ni + j) % 20 == 0) fprintf > print_array: 65 | if ((i * ni + j) % 20 == 0) fprintf ]] which could happen if different optimizations were missed in different inlining contexts. llvm-svn: 291361
* [llvm-opt-report] Fix unroll-count reportingHal Finkel2016-10-241-1/+1
| | | | | | | Fix the implementation of OptReportLocationInfo's operator < so that contexts with different unroll counts are reported separately. llvm-svn: 284957
* [llvm-opt-report] Don't leave space for opts that never happenHal Finkel2016-10-081-6/+13
| | | | | | | | | | Because screen space is precious, if an optimization (vectorization, for example) never happens, don't leave empty space for the associated markers on every line of the output. This makes the output much more compact, and allows for the later inclusion of markers for more (although perhaps rare) optimizations. llvm-svn: 283626
* [llvm-opt-report] Left justify unrolling counts, etc.Hal Finkel2016-10-071-5/+12
| | | | | | | | | | | | In the left part of the reports, we have things like U<number>; if some of these numbers use more digits than others, we don't want a space in between the U and the start of the number. Instead, the space should come afterward. This way it is clear that the number goes with the U and not any other optimization indicator that might come later on the line. Tests committed in r283518. llvm-svn: 283519
* [llvm-opt-report] Use -no-demangle to disable demanglingHal Finkel2016-10-071-3/+3
| | | | | | | As this is intended to be a user-facing option, -no-demangle seems much better than -demangle=0. Add testing for the option. llvm-svn: 283516
* [llvm-opt-report] Record VF, etc. correctly for multiple opts on one lineHal Finkel2016-10-061-13/+8
| | | | | | | When there are multiple optimizations on one line, record the vectorization factors, etc. correctly (instead of incorrectly substituting default values). llvm-svn: 283443
* [llvm-opt-report] Print line numbers starting from 1Hal Finkel2016-10-061-1/+1
| | | | | | Line numbers should start from 1, not 2. llvm-svn: 283440
* [llvm-opt-report] Distinguish inlined contexts when optimizations differHal Finkel2016-10-052-74/+184
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | How code is optimized sometimes, perhaps often, depends on the context into which it was inlined. This change allows llvm-opt-report to track the differences between the optimizations performed, or not, in different contexts, and when these differ, display those differences. For example, this code: $ cat /tmp/q.cpp void bar(); void foo(int n) { for (int i = 0; i < n; ++i) bar(); } void quack() { foo(4); } void quack2() { foo(4); } will now produce this report: < /home/hfinkel/src/llvm/test/tools/llvm-opt-report/Inputs/q.cpp 2 | void bar(); 3 | void foo(int n) { [[ > foo(int): 4 | for (int i = 0; i < n; ++i) > quack(), quack2(): 4 U4 | for (int i = 0; i < n; ++i) ]] 5 | bar(); 6 | } 7 | 8 | void quack() { 9 I | foo(4); 10 | } 11 | 12 | void quack2() { 13 I | foo(4); 14 | } 15 | Note that the tool has demangled the function names, and grouped the reports associated with line 4. This shows that the loop on line 4 was unrolled by a factor of 4 when inlined into the functions quack() and quack2(), but not in the function foo(int) itself. llvm-svn: 283402
* Add an llvm-opt-report tool to generate basic source-annotated optimization ↵Hal Finkel2016-10-052-0/+407
summaries LLVM now has the ability to record information from optimization remarks in a machine-consumable YAML file for later analysis. This can be enabled in opt (see r282539), and D25225 adds a Clang flag to do the same. This patch adds llvm-opt-report, a tool to generate basic optimization "listing" files (annotated sources with information about what optimizations were performed) from one of these YAML inputs. D19678 proposed to add this capability directly to Clang, but this more-general YAML-based infrastructure was the direction we decided upon in that review thread. For this optimization report, I focused on making the output as succinct as possible while providing information on inlining and loop transformations. The goal here is that the source code should still be easily readable in the report. My primary inspiration here is the reports generated by Cray's tools (http://docs.cray.com/books/S-2496-4101/html-S-2496-4101/z1112823641oswald.html). These reports are highly regarded within the HPC community. Intel's compiler, for example, also has an optimization-report capability (https://software.intel.com/sites/default/files/managed/55/b1/new-compiler-optimization-reports.pdf). $ cat /tmp/v.c void bar(); void foo() { bar(); } void Test(int *res, int *c, int *d, int *p, int n) { int i; #pragma clang loop vectorize(assume_safety) for (i = 0; i < 1600; i++) { res[i] = (p[i] == 0) ? res[i] : res[i] + d[i]; } for (i = 0; i < 16; i++) { res[i] = (p[i] == 0) ? res[i] : res[i] + d[i]; } foo(); foo(); bar(); foo(); } D25225 adds -fsave-optimization-record (and -fsave-optimization-record=filename), and this would be used as follows: $ clang -O3 -o /tmp/v.o -c /tmp/v.c -fsave-optimization-record $ llvm-opt-report /tmp/v.yaml > /tmp/v.lst $ cat /tmp/v.lst < /tmp/v.c 2 | void bar(); 3 | void foo() { bar(); } 4 | 5 | void Test(int *res, int *c, int *d, int *p, int n) { 6 | int i; 7 | 8 | #pragma clang loop vectorize(assume_safety) 9 V4,2 | for (i = 0; i < 1600; i++) { 10 | res[i] = (p[i] == 0) ? res[i] : res[i] + d[i]; 11 | } 12 | 13 U16 | for (i = 0; i < 16; i++) { 14 | res[i] = (p[i] == 0) ? res[i] : res[i] + d[i]; 15 | } 16 | 17 I | foo(); 18 | 19 | foo(); bar(); foo(); I | ^ I | ^ 20 | } Each source line gets a prefix giving the line number, and a few columns for important optimizations: inlining, loop unrolling and loop vectorization. An 'I' is printed next to a line where a function was inlined, a 'U' next to an unrolled loop, and 'V' next to a vectorized loop. These are printed on the relevant code line when that seems unambiguous, or on subsequent lines when multiple potential options exist (messages, both positive and negative, from the same optimization with different column numbers are taken to indicate potential ambiguity). When on subsequent lines, a '^' is output in the relevant column. Annotated source for all relevant input files are put into the listing file (each starting with '<' and then the file name). You can disable having the unrolling/vectorization factors appear by using the -s flag. Differential Revision: https://reviews.llvm.org/D25262 llvm-svn: 283398
OpenPOWER on IntegriCloud