summaryrefslogtreecommitdiffstats
path: root/llvm/tools
Commit message (Collapse)AuthorAgeFilesLines
...
* [llvm-exegesis] Introduce a 'naive' clustering algorithm (PR40880)Roman Lebedev2019-03-285-31/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is an alternative to D59539. Let's suppose we have measured 4 different opcodes, and got: `0.5`, `1.0`, `1.5`, `2.0`. Let's suppose we are using `-analysis-clustering-epsilon=0.5`. By default now we will start processing the `0.5` point, find that `1.0` is it's neighbor, add them to a new cluster. Then we will notice that `1.5` is a neighbor of `1.0` and add it to that same cluster. Then we will notice that `2.0` is a neighbor of `1.5` and add it to that same cluster. So all these points ended up in the same cluster. This may or may not be a correct implementation of dbscan clustering algorithm. But this is rather horribly broken for the reasons of comparing the clusters with the LLVM sched data. Let's suppose all those opcodes are currently in the same sched cluster. If i specify `-analysis-inconsistency-epsilon=0.5`, then no matter the LLVM values this cluster will **never** match the LLVM values, and thus this cluster will **always** be displayed as inconsistent. The solution is obviously to split off some of these opcodes into different sched cluster. But how do i do that? Out of 4 opcodes displayed in the inconsistency report, which ones are the "bad ones"? Which ones are the most different from the checked-in data? I'd need to go in to the `.yaml` and look it up manually. The trivial solution is to, when creating clusters, don't use the full dbscan algorithm, but instead "pick some unclustered point, pick all unclustered points that are it's neighbor, put them all into a new cluster, repeat". And just so as it happens, we can arrive at that algorithm by not performing the "add neighbors of a neighbor to the cluster" step. But that won't work well once we teach analyze mode to operate in on-1D mode (i.e. on more than a single measurement type at a time), because the clustering would depend on the order of the measurements. Instead, let's just create a single cluster per opcode, and put all the points of that opcode into said cluster. And simultaneously check that every point in that cluster is a neighbor of every other point in the cluster, and if they are not, the cluster (==opcode) is unstable. This is //yet another// step to bring me closer to being able to continue cleanup of bdver2 sched model.. Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=40880 | PR40880 ]]. Reviewers: courbet, gchatelet Reviewed By: courbet Subscribers: tschuett, jdoerfert, RKSimon, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59820 llvm-svn: 357152
* Fix typoed variable name.Eric Christopher2019-03-281-4/+4
| | | | | | NFCI. llvm-svn: 357138
* [opt-viewer] Teach optrecord.py about !Failure tagsJessica Paquette2019-03-271-0/+2
| | | | | | | | | | | | | WarnMissedTransforms.cpp produces remarks that use !Failure tags. These weren't supported in optrecord.py, so if you encountered one in any of the tools, the tool would crash. Add them as a type of missed optimization. Differential Revision: https://reviews.llvm.org/D59895 llvm-svn: 357110
* [opt-viewer] Make filter_=None by default in get_remarks and gather_resultsJessica Paquette2019-03-271-4/+6
| | | | | | | | | | | | | Right now, if you try to use optdiff.py on any opt records, it will fail because its calls to gather_results weren't updated to support filtering. Since filters are supposed to be optional, this makes them None by default in get_remarks and in gather_results. This allows other tools that don't support filtering to still use the functions as is. Differential Revision: https://reviews.llvm.org/D59894 llvm-svn: 357106
* [llvm-dwarfdump] Simplify -o handlingFangrui Song2019-03-271-15/+10
| | | | | | | | | | ToolOutputFile handles '-' so no need to specialize here. Also, we neither reassign the variable nor pass it around, thus no need to use std::unique_ptr<ToolOutputFile>. exit(1) -> return 1; to call the destructor of raw_fd_stream llvm-svn: 357051
* [llvm-objcopy] - Strip sections before symbols.George Rimar2019-03-261-2/+6
| | | | | | | | | | | | This is a fix for https://bugs.llvm.org/show_bug.cgi?id=40007. Idea is to swap the order of stripping. So that we strip sections before symbols what allows us to strip relocation sections without emitting the error about relative symbols. Differential revision: https://reviews.llvm.org/D59763 llvm-svn: 357017
* [llvm-exegesis] Allow the target to disable the selection of some registers.Clement Courbet2019-03-263-2/+23
| | | | | | | | | | | | | | | | | | | | Summary: This prevents "Cannot encode high byte register in REX-prefixed instruction" from happening on instructions that require REX encoding when AH & co get selected. On the down side, these 4 registers can no longer be selected automatically, but this avoids having to expose all the X86 encoding complexity. Reviewers: gchatelet Subscribers: tschuett, jdoerfert, llvm-commits, bdb Tags: #llvm Differential Revision: https://reviews.llvm.org/D59821 llvm-svn: 357003
* [MCA] Correctly update the UsedResourceGroups mask in the InstrBuilder.Andrea Di Biagio2019-03-262-7/+4
| | | | | | | | Found by inspection when looking at the debug output of MCA. This problem was latent, and none of the upstream models were affected by it. No functional change intended. llvm-svn: 357000
* [llvm-objcopy]Preserve data in segments not covered by sectionsJames Henderson2019-03-252-5/+47
| | | | | | | | | | | | | | | | llvm-objcopy previously knew nothing about data in segments that wasn't covered by section headers, meaning that it wrote zeroes instead of what was there. As it is possible for this data to be useful to the loader, this patch causes llvm-objcopy to start preserving this data. Data in sections that are explicitly removed continues to be written as zeroes. This fixes https://bugs.llvm.org/show_bug.cgi?id=41005. Reviewed by: jakehehrlich, rupprecht Differential Revision: https://reviews.llvm.org/D59483 llvm-svn: 356919
* Revert 356905Serge Guelton2019-03-251-12/+6
| | | | | | Commited from wrong directory... llvm-svn: 356907
* Python 2/3 compat: queue vs QueueSerge Guelton2019-03-251-6/+12
| | | | | | Differential Revision: https://reviews.llvm.org/D59590 llvm-svn: 356905
* [llvm-objcopy] - Refactor the code. NFC.George Rimar2019-03-251-96/+106
| | | | | | | | | | The idea of the patch is about to move out the code to a new helper static functions (to reduce the size of 'handleArgs' and to isolate the parts of it's logic). Differential revision: https://reviews.llvm.org/D59762 llvm-svn: 356889
* [llvm-readobj] Separate `Symbol Version` dumpers into `LLVM style` and `GNU ↵Xing GUO2019-03-251-137/+183
| | | | | | | | | | | | | | | | | | | | style` Summary: Currently, llvm-readobj can dump symbol version sections only in LLVM style. In this patch, I would like to separate these dumpers into GNU style and LLVM style for future implementation. Reviewers: grimar, jhenderson, mattd, rupprecht Reviewed By: jhenderson, rupprecht Subscribers: ormris, dyung, RKSimon, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59186 llvm-svn: 356881
* Recommit r356738 "[llvm-objcopy] - Implement replaceSectionReferences for ↵George Rimar2019-03-242-0/+9
| | | | | | | | | | | | | | | | | | | GroupSection class." Fix: r356853 + set AddressAlign to 4 in Inputs/compress-debug-sections.yaml for the new group section introduced. Original commit message: Currently, llvm-objcopy incorrectly handles compression and decompression of the sections from COMDAT groups, because we do not implement the replaceSectionReferences for this type of the sections. The patch does that. Differential revision: https://reviews.llvm.org/D59638 llvm-svn: 356856
* [llvm-objcopy] - Report SHT_GROUP sections with invalid alignment.George Rimar2019-03-241-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes the reason of ubsan failure (UB detected) happened after landing the D59638 (I had to revert it). http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-ubsan/builds/11760/steps/check-llvm%20ubsan/logs/stdio) Problem is the following. Our implementation of GroupSection assumes that its address is 4 bytes aligned when writes it: template <class ELFT> void ELFSectionWriter<ELFT>::visit(const GroupSection &Sec) { ELF::Elf32_Word *Buf = reinterpret_cast<ELF::Elf32_Word *>(Out.getBufferStart() + Sec.Offset); ... But the test case for D59638 did not set AddressAlign in YAML. So address was not 4 bytes aligned since Sec.Offset was odd. That triggered the issue. This patch teaches llvm-objcopy to report an error for such sections (which should not met in reality), what is better than having UB. Differential revision: https://reviews.llvm.org/D59695 llvm-svn: 356853
* [DebugInfo] follow up for "add SectionedAddress to DebugInfo interfaces"Alexey Lapshin2019-03-231-49/+8
| | | | | | | | | | | | | | | | | | | | | | | [Symbolizer] Add getModuleSectionIndexForAddress() helper routine The https://reviews.llvm.org/D58194 patch changed symbolizer interface. Particularily it requires not only Address but SectionIndex also. Note object::SectionedAddress parameter: Expected<DILineInfo> symbolizeCode(const std::string &ModuleName, object::SectionedAddress ModuleOffset, StringRef DWPName = ""); There are callers of symbolizer which do not know particular section index. That patch creates getModuleSectionIndexForAddress() routine which will detect section index for the specified address. Thus if caller set ModuleOffset.SectionIndex into object::SectionedAddress::UndefSection state then symbolizer would detect section index using getModuleSectionIndexForAddress routine. Differential Revision: https://reviews.llvm.org/D58848 llvm-svn: 356829
* [pdb] Add -type-stats and sort stats by descending sizeReid Kleckner2019-03-224-9/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: It prints this on chromium browser_tests.exe.pdb: Types Total: 5647475 entries ( 371,897,512 bytes, 65.85 avg) -------------------------------------------------------------------------- LF_CLASS: 397894 entries ( 119,537,780 bytes, 300.43 avg) LF_STRUCTURE: 236351 entries ( 83,208,084 bytes, 352.05 avg) LF_FIELDLIST: 291003 entries ( 66,087,920 bytes, 227.10 avg) LF_MFUNCTION: 1884176 entries ( 52,756,928 bytes, 28.00 avg) LF_POINTER: 1149030 entries ( 13,877,344 bytes, 12.08 avg) LF_ARGLIST: 789980 entries ( 12,436,752 bytes, 15.74 avg) LF_METHODLIST: 361498 entries ( 8,351,008 bytes, 23.10 avg) LF_ENUM: 16069 entries ( 6,108,340 bytes, 380.13 avg) LF_PROCEDURE: 269374 entries ( 4,309,984 bytes, 16.00 avg) LF_MODIFIER: 235602 entries ( 2,827,224 bytes, 12.00 avg) LF_UNION: 9131 entries ( 2,072,168 bytes, 226.94 avg) LF_VFTABLE: 323 entries ( 207,784 bytes, 643.29 avg) LF_ARRAY: 6639 entries ( 106,380 bytes, 16.02 avg) LF_VTSHAPE: 126 entries ( 6,472 bytes, 51.37 avg) LF_BITFIELD: 278 entries ( 3,336 bytes, 12.00 avg) LF_LABEL: 1 entries ( 8 bytes, 8.00 avg) The PDB is overall 1.9GB, so the LF_CLASS and LF_STRUCTURE declarations account for about 10% of the overall file size. I was surprised to find that on average LF_FIELDLIST records are short. Maybe this is because there are many more types with short member lists than there are instantiations with lots of members, like std::vector. Reviewers: aganea, zturner Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59672 llvm-svn: 356813
* [llvm-readobj] Revert bad changesXing GUO2019-03-221-175/+101
| | | | llvm-svn: 356777
* [llvm-readobj] Separate `Symbol Version` dumpers into `LLVM style` and `GNU ↵Xing GUO2019-03-221-101/+175
| | | | | | | | | | | | | | | | | | | | style` Summary: Currently, llvm-readobj can dump symbol version sections only in LLVM style. In this patch, I would like to separate these dumpers into GNU style and LLVM style for future implementation. Reviewers: grimar, jhenderson, mattd, rupprecht Reviewed By: rupprecht Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59186 llvm-svn: 356764
* [ObjectYAML] Add basic minidump generation supportPavel Labath2019-03-224-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds the ability to read a yaml form of a minidump file and write it out as binary. Apart from the minidump header and the stream directory, only three basic stream kinds are supported: - Text: This kind is used for streams which contain textual data. This is typically the contents of a /proc file on linux (e.g. /proc/PID/maps). In this case, we just put the raw stream contents into the yaml. - SystemInfo: This stream contains various bits of information about the host system in binary form. We expose the data in a structured form. - Raw: This kind is used as a fallback when we don't have any special knowledge about the stream. In this case, we just print the stream contents in hex. For this code to be really useful, more stream kinds will need to be added (particularly for things like lists of memory regions and loaded modules). However, these can be added incrementally. Reviewers: jhenderson, zturner, clayborg, aprantl Subscribers: mgorny, lemo, llvm-commits, lldb-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59482 llvm-svn: 356753
* Revert r356738 "[llvm-objcopy] - Implement replaceSectionReferences for ↵George Rimar2019-03-222-9/+0
| | | | | | | | | GroupSection class." Seems this broke ubsan bot: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-ubsan/builds/11760 llvm-svn: 356745
* [llvm-objcopy] - Implement replaceSectionReferences for GroupSection class.George Rimar2019-03-222-0/+9
| | | | | | | | | | | | Currently, llvm-objcopy incorrectly handles compression and decompression of the sections from COMDAT groups, because we do not implement the replaceSectionReferences for this type of the sections. The patch does that. Differential revision: https://reviews.llvm.org/D59638 llvm-svn: 356738
* [llvm-objcopy]Add support for *-freebsd output formatsJames Henderson2019-03-223-16/+24
| | | | | | | | | | | | | | GNU objcopy can support output formats like elf32-i386-freebsd and elf64-x86-64-freebsd. The only difference from their regular non-freebsd counterparts that I have observed is that the freebsd versions set the OS/ABI field to ELFOSABI_FREEBSD. This patch sets the OS/ABI field according based on the format whenever --output-format is specified. Reviewed by: rupprecht, grimar Differential Revision: https://reviews.llvm.org/D59645 llvm-svn: 356737
* [llvm-objdump] Support arg grouping for -j and -M (e.g. llvm-objdump -sj.foo ↵Jordan Rupprecht2019-03-211-2/+3
| | | | | | | | | | | | | | | | | | | | | | | -dMreg-names-raw) Summary: r354375 added support for most objdump groupings, but didn't add support for -j|--sections, because that wasn't possible. r354870 added --disassembler options, but grouping still wasn't available. r355185 supported values for grouped options. This just puts the three of them together. This supports -j in modes like `-s -j .foo`, `-sj .foo`, `-sj=.foo`, or `-sj.foo`, and similar for `-M`. Reviewers: ormris, jhenderson, ikudrin Reviewed By: jhenderson, ikudrin Subscribers: javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59618 llvm-svn: 356697
* [llvm-pdbutil] Add -type-ref-stats to help find unused type infoReid Kleckner2019-03-219-19/+317
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This considers module symbol streams and the global symbol stream to be roots. Most types that this considers "unreferenced" are referenced by LF_UDT_MOD_SRC_LINE id records, which VC seems to always include. Essentially, they are types that the user can only find in the debugger if they call them by name, they cannot be found by traversing a symbol. In practice, around 80% of type information in a PDB is referenced by a symbol. That seems like a reasonable number. I don't really plan to do anything with this tool. It mostly just exists for informational purposes, and to confirm that we probably don't need to implement type reference tracking in LLD. We can continue to merge all types as we do today without wasting space. Reviewers: zturner, aganea Subscribers: mgorny, hiraditya, arphaman, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59620 llvm-svn: 356692
* [llvm-readobj] Format codes. NFC.Xing GUO2019-03-211-8/+8
| | | | llvm-svn: 356664
* [WebAssembly] Target features sectionThomas Lively2019-03-202-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Implements a new target features section in assembly and object files that records what features are used, required, and disallowed in WebAssembly objects. The linker uses this information to ensure that all objects participating in a link are feature-compatible and records the set of used features in the output binary for use by optimizers and other tools later in the toolchain. The "atomics" feature is always required or disallowed to prevent linking code with stripped atomics into multithreaded binaries. Other features are marked used if they are enabled globally or on any function in a module. Future CLs will add linker flags for ignoring feature compatibility checks and for specifying the set of allowed features, implement using the presence of the "atomics" feature to control the type of memory and segments in the linked binary, and add front-end flags for relaxing the linkage policy for atomics. Reviewers: aheejin, sbc100, dschuff Subscribers: jgravelle-google, hiraditya, sunfish, mgrang, jfb, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59173 llvm-svn: 356610
* [AMDGPU] Factored PAL metadata handling out into its own classTim Renouf2019-03-201-11/+0
| | | | | | | | | | | | | | | | | | | | | | Summary: This commit introduces a new AMDGPUPALMetadata class that: * is inside the AMDGPU target; * keeps an in-memory representation of PAL metadata; * provides a method to read the frontend-supplied metadata from LLVM IR; * provides methods for the asm printer to set metadata items; * provides methods to write the metadata as a binary blob to put in a .note record or as an asm directive; * provides a method to read the metadata as a binary blob from a .note record. Because llvm-readobj cannot call directly into a target, I had to remove llvm-readobj's ability to dump PAL metadata, pending a resolution to https://reviews.llvm.org/D52821 Differential Revision: https://reviews.llvm.org/D57027 Change-Id: I756dc830894fcb6850324cdcfa87c0120eb2cf64 llvm-svn: 356582
* [llvm-objcopy] - Use replaceSectionReferences to update the sections for ↵George Rimar2019-03-202-6/+9
| | | | | | | | | | | symbols in symbol table. If the compression was used and we had a symbol not involved in relocation, we never updated its section and it was silently removed from the output. Differential revision: https://reviews.llvm.org/D59542 llvm-svn: 356554
* Reland "[Remarks] Add a new Remark / RemarkParser abstraction"Francis Visoiu Mistrih2019-03-192-38/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-192-55/+38
| | | | | | | | | 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-192-38/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [llvm-ar] Support N [count] modifierJordan Rupprecht2019-03-191-8/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: GNU ar supports the 'N' count modifier for the extract (x) and delete (d) operations. When an archive contains multiple members with the same name, this can be used to extract (or delete) them individually. For example: ``` $ llvm-ar t archive.a foo foo $ llvm-ar x archive.a -> Writes foo twice, overwriting it the second time :( :( $ llvm-ar xN 1 archive.a foo && mv foo foo.1 $ llvm-ar xN 2 archive.a foo && mv foo foo.2 -> Write foo twice, renaming it in between invocations to preserve all versions ``` Reviewers: ruiu, MaskRay Reviewed By: ruiu, MaskRay Subscribers: jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59503 llvm-svn: 356466
* Use response file when generating LLVM-C.dllSerge Guelton2019-03-192-3/+36
| | | | | | | | | | | As discovered in D56774 the command line gets to long, so use a response file to give the script the libs. This change has been tested and is confirmed working for me. Commited on behalf of Jakob Bornecrantz. Differential Revision: https://reviews.llvm.org/D56781 llvm-svn: 356443
* [llvm-objcopy] Make .build-id linking atomicJake Ehrlich2019-03-181-9/+43
| | | | | | | | This change makes linking into .build-id atomic and safe to use. Some users under particular workflows are reporting that this races more than half the time under particular conditions. llvm-svn: 356404
* [llvm-objcopy] - Calculate the string table section sizes correctly.George Rimar2019-03-182-12/+12
| | | | | | | | | | | | | | This fixes the https://bugs.llvm.org/show_bug.cgi?id=40980. Previously if string optimization occurred as a result of StringTableBuilder's finalize() method, the size wasn't updated. This hopefully also makes the interaction between sections during finalization processes a bit more clear. Differential revision: https://reviews.llvm.org/D59488 llvm-svn: 356371
* [llvm-exegesis] Separate tool options into three categories.Roman Lebedev2019-03-181-18/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Results in much nicer -help output: ``` $ ./bin/llvm-exegesis -help USAGE: llvm-exegesis [options] OPTIONS: Color Options: -color - Use colors in output (default=autodetect) General options: -enable-cse-in-irtranslator - Should enable CSE in irtranslator -enable-cse-in-legalizer - Should enable CSE in Legalizer Generic Options: -help - Display available options (-help-hidden for more) -help-list - Display list of available options (-help-list-hidden for more) -version - Display the version of this program llvm-exegesis analysis options: -analysis-clustering-epsilon=<number> - dbscan epsilon for benchmark point clustering -analysis-clusters-output-file=<string> - -analysis-display-unstable-clusters - if there is more than one benchmark for an opcode, said benchmarks may end up not being clustered into the same cluster if the measured performance characteristics are different. by default all such opcodes are filtered out. this flag will instead show only such unstable opcodes -analysis-inconsistencies-output-file=<string> - -analysis-inconsistency-epsilon=<number> - epsilon for detection of when the cluster is different from the LLVM schedule profile values -analysis-numpoints=<uint> - minimum number of points in an analysis cluster llvm-exegesis benchmark options: -ignore-invalid-sched-class - ignore instructions that do not define a sched class -mode=<value> - the mode to run =latency - Instruction Latency =inverse_throughput - Instruction Inverse Throughput =uops - Uop Decomposition =analysis - Analysis -num-repetitions=<uint> - number of time to repeat the asm snippet -opcode-index=<int> - opcode to measure, by index -opcode-name=<string> - comma-separated list of opcodes to measure, by name -snippets-file=<string> - code snippets to measure llvm-exegesis options: -benchmarks-file=<string> - File to read (analysis mode) or write (latency/uops/inverse_throughput modes) benchmark results. “-” uses stdin/stdout. -mcpu=<string> - cpu name to use for pfm counters, leave empty to autodetect ``` llvm-svn: 356364
* [llvm-profdata] Deleted unused Cutoffs added by D16005Fangrui Song2019-03-151-2/+0
| | | | llvm-svn: 356248
* [yaml2obj]Allow explicit setting of p_filesz, p_memsz, and p_offsetJames Henderson2019-03-151-34/+48
| | | | | | | | | | | | | | yaml2obj currently derives the p_filesz, p_memsz, and p_offset values of program headers from their sections. This makes writing tests for certain formats more complex, and sometimes impossible. This patch allows setting these fields explicitly, overriding the default value, when relevant. Reviewed by: jakehehrlich, Higuoxing Differential Revision: https://reviews.llvm.org/D59372 llvm-svn: 356247
* [llvm-readobj] Delete unused variable. NFCFangrui Song2019-03-151-1/+0
| | | | llvm-svn: 356246
* [llvm-objcopy] Delete unused parameter from replaceDebugSections. NFCFangrui Song2019-03-151-3/+3
| | | | llvm-svn: 356245
* [llvm-objcopy] Don't use {}; NFCFangrui Song2019-03-151-1/+1
| | | | llvm-svn: 356244
* [llvm-strip] Hook up (unimplemented) --only-keep-debugJordan Rupprecht2019-03-143-1/+10
| | | | | | | | For ELF, we accept but ignore --only-keep-debug. Do the same for llvm-strip. COFF does implement this, so update the test that it is supported. llvm-svn: 356207
* Speeding up llvm-cov export with multithreaded renderFiles implementation.Max Moroz2019-03-143-13/+64
| | | | | | | | | | | | | | | | | | | | | Summary: CoverageExporterJson::renderFiles accounts for most of the execution time given a large profdata file with multiple binaries. Proposed solution is to generate JSON for each file in parallel and sort at the end to preserve deterministic output. Also added flags to skip generating parts of the output to trim the output size. Patch by Sajjad Mirza (@sajjadm). Reviewers: Dor1s, vsk Reviewed By: Dor1s, vsk Subscribers: liaoyuke, mgrang, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59277 llvm-svn: 356178
* [llvm-objcopy]Don't implicitly strip sections in segmentsJames Henderson2019-03-143-15/+17
| | | | | | | | | | | | | | | | | | | | | | | | | This patch changes llvm-objcopy's behaviour to not strip sections that are in segments, if they otherwise would be due to a stripping operation (--strip-all, --strip-sections, --strip-non-alloc). This preserves the segment contents. It does not change the behaviour of --strip-all-gnu (although we could choose to do so), because GNU objcopy's behaviour in this case seems to be to strip the section, nor does it prevent removing of sections in segments with --remove-section (if a user REALLY wants to remove a section, we should probably let them, although I could be persuaded that warning might be appropriate). Tests have been added to show this latter behaviour. This fixes https://bugs.llvm.org/show_bug.cgi?id=41006. Reviewed by: grimar, rupprecht, jakehehrlich Differential Revision: https://reviews.llvm.org/D59293 This is a reland of r356129, attempting to fix greendragon failures due to a suspected compatibility issue with od on the greendragon bots versus other versions. llvm-svn: 356136
* Revert r356129 due to greendragon bot failuresJames Henderson2019-03-143-17/+15
| | | | llvm-svn: 356133
* [llvm-objcopy]Don't implicitly strip sections in segmentsJames Henderson2019-03-143-15/+17
| | | | | | | | | | | | | | | | | | | | | This patch changes llvm-objcopy's behaviour to not strip sections that are in segments, if they otherwise would be due to a stripping operation (--strip-all, --strip-sections, --strip-non-alloc). This preserves the segment contents. It does not change the behaviour of --strip-all-gnu (although we could choose to do so), because GNU objcopy's behaviour in this case seems to be to strip the section, nor does it prevent removing of sections in segments with --remove-section (if a user REALLY wants to remove a section, we should probably let them, although I could be persuaded that warning might be appropriate). Tests have been added to show this latter behaviour. This fixes https://bugs.llvm.org/show_bug.cgi?id=41006. Reviewed by: grimar, rupprecht, jakehehrlich Differential Revision: https://reviews.llvm.org/D59293 llvm-svn: 356129
* [llvm-objcopy][NFC] Remove unnecessary llvm-objcopy.h #includesJordan Rupprecht2019-03-135-5/+0
| | | | llvm-svn: 356109
* [llvm-objcopy] Cleanup errors from CopyConfig and remove llvm-objcopy.h ↵Jordan Rupprecht2019-03-131-14/+24
| | | | | | | | | | dependency error() was previously cleaned up from CopyConfig, but new uses were introduced. This also tweaks the error message for --add-symbol to report all invalid flags. llvm-svn: 356105
* [AMDGPU] Switched HSA metadata to use MsgPackDocumentTim Renouf2019-03-131-11/+6
| | | | | | | | | | | | Summary: MsgPackDocument is the lighter-weight replacement for MsgPackTypes. This commit switches AMDGPU HSA metadata processing to use MsgPackDocument instead of MsgPackTypes. Differential Revision: https://reviews.llvm.org/D57024 Change-Id: I0751668013abe8c87db01db1170831a76079b3a6 llvm-svn: 356081
OpenPOWER on IntegriCloud