summaryrefslogtreecommitdiffstats
path: root/llvm/tools
Commit message (Collapse)AuthorAgeFilesLines
...
* [llvm-readobj/llvm-readelf] - Report a warning instead of a error when ↵George Rimar2019-07-112-2/+7
| | | | | | | | | | | | dumping a broken dynamic section. It does not make sence to stop dumping the object if the broken dynamic section was found. In this patch I changed the behavior from "report an error" to "report a warning". This matches GNU. Differential revision: https://reviews.llvm.org/D64472 llvm-svn: 365762
* [llvm-objcopy] Don't change permissions of non-regular output filesFangrui Song2019-07-111-2/+13
| | | | | | | | | | | | | | | | | | | | | | There is currently an EPERM error when a regular user executes `llvm-objcopy a.o /dev/null`. Worse, root can even change the mode bits of /dev/null. Fix it by checking if the output file is special. A new overload of llvm::sys::fs::setPermissions with FD as the parameter is added. Users should provide `perm & ~umask` as the parameter if they intend to respect umask. The existing overload of llvm::sys::fs::setPermissions may be deleted if we can find an implementation of fchmod() on Windows. fchmod() is usually better than chmod() because it saves syscalls and can avoid race condition. Reviewed By: jakehehrlich, jhenderson Differential Revision: https://reviews.llvm.org/D64236 llvm-svn: 365753
* Revert [llvm-objcopy] Allow strip symtab from executables and DSOsJordan Rupprecht2019-07-103-25/+1
| | | | | | | | | | | | | This reverts r365193 (git commit 194f16b3548bcb23a7f0fd638778ed72edd18d37) This patch doesn't work with binaries built w/ `--emit-relocs`, e.g. ``` $ echo 'int main() { return 0; }' | clang -Wl,--emit-relocs -x c - -o foo && llvm-objcopy --strip-unneeded foo llvm-objcopy: error: 'foo': not stripping symbol '__gmon_start__' because it is named in a relocation ``` llvm-svn: 365712
* [Support] Move llvm::MemoryBuffer to sys::fs::file_tReid Kleckner2019-07-101-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: On Windows, Posix integer file descriptors are a compatibility layer over native file handles provided by the C runtime. There is a hard limit on the maximum number of file descriptors that a process can open, and the limit is 8192. LLD typically doesn't run into this limit because it opens input files, maps them into memory, and then immediately closes the file descriptor. This prevents it from running out of FDs. For various reasons, I'd like to open handles to every input file and keep them open during linking. That requires migrating MemoryBuffer over to taking open native file handles instead of integer FDs. Reviewers: aganea, Bigcheese Reviewed By: aganea Subscribers: smeenai, silvas, mehdi_amini, hiraditya, steven_wu, dexonsmith, dang, llvm-commits, zturner Tags: #llvm Differential Revision: https://reviews.llvm.org/D63453 llvm-svn: 365588
* [llvm-objdump] Keep warning for --disassemble-functions in correct order.Yuanfang Chen2019-07-091-1/+5
| | | | | | | | | | | | | | relative to normal output when dumping archive files. prepare for PR35351. Reviewers: jhenderson, grimar, MaskRay, rupprecht Reviewed by: MaskRay, jhenderson Differential Revision: https://reviews.llvm.org/D64165 llvm-svn: 365564
* [AMDGPU] gfx908 targetStanislav Mekhanoshin2019-07-091-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D64429 llvm-svn: 365525
* [Object][XCOFF] Add support for 64-bit file header and section header dumping.Sean Fertile2019-07-092-19/+91
| | | | | | | | | | | Adds a readobj dumper for 32-bit and 64-bit section header tables, and extend support for the file-header dumping to include 64-bit object files. Also refactors the binary file parsing to be done in a helper function in an attempt to cleanup error handeling. Differential Revision: https://reviews.llvm.org/D63843 llvm-svn: 365524
* [DwarfDebug] Dump call site debug infoDjordje Todorovic2019-07-091-4/+16
| | | | | | | | | | | | | | | | | | | Dump the DWARF information about call sites and call site parameters into debug info sections. The patch also provides an interface for the interpretation of instructions that could load values of a call site parameters in order to generate DWARF about the call site parameters. ([13/13] Introduce the debug entry values.) Co-authored-by: Ananth Sowda <asowda@cisco.com> Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com> Co-authored-by: Ivan Baev <ibaev@cisco.com> Differential Revision: https://reviews.llvm.org/D60716 llvm-svn: 365467
* llvm-profdata] Handle the cases of overlapping input file and output fileRong Xu2019-07-081-11/+17
| | | | | | | | | | | | | | | | | | | | Currently llvm-profdata does not expect the same file name for the input profile and the output profile. >llvm-profdata merge A.profraw B.profraw -o B.profraw The above command runs successfully but the resulted B.profraw is not correct. This patch fixes the issue by moving the initialization of writer after loading the profile. For the show command, the following will report a confusing error of "Empty raw profile file": >llvm-profdata show B.profraw -o B.profraw It's harder to fix as we need to output something before loading the input profile. I don't think that a fix for this is worth the effort. I just make the error explicit for the show command. Differential Revision: https://reviews.llvm.org/D64360 llvm-svn: 365386
* Teach the symbolizer lib symbolize objects directly.Yuanfang Chen2019-07-081-2/+1
| | | | | | | | | | | | | | Currently, the symbolizer lib can only symbolize a file on disk. This patch teaches the symbolizer lib to symbolize objects. llvm-objdump needs this to support archive disassembly with source info. https://bugs.llvm.org/show_bug.cgi?id=41871 Reviewed by: jhenderson, grimar, MaskRay Differential Revision: https://reviews.llvm.org/D63521 llvm-svn: 365376
* [llvm-bcanalyzer] Refactor and move to libLLVMBitReaderFrancis Visoiu Mistrih2019-07-081-991/+44
| | | | | | | | | | | | | This allows us to use the analyzer from unit tests. * Refactor the interface to use proper error handling for most functions after JF's work. * Move everything into a BitstreamAnalyzer class. * Move that to Bitcode/BitcodeAnalyzer.h. Differential Revision: https://reviews.llvm.org/D64116 llvm-svn: 365286
* [llvm-objcopy] Allow strip symtab from executables and DSOsEugene Leviant2019-07-053-1/+25
| | | | | | Differential revision: https://reviews.llvm.org/D61672 llvm-svn: 365193
* [llvm-objcopy][NFC] Refactor output target parsing v2Seiya Nuta2019-07-054-36/+90
| | | | | | | | | | | | | | | | | | | | | Summary: Use an enum instead of string to hold the output file format in Config.InputFormat and Config.OutputFormat. It's essential to support other output file formats other than ELF. This patch originally has been submitted as D63239. However, there was an use-of-uninitialized-value bug and reverted in r364379 (git commit 4ee933c). This patch includes the fix for the bug by setting Config.InputFormat/Config.OutputFormat in parseStripOptions. Reviewers: espindola, alexshap, rupprecht, jhenderson Reviewed By: jhenderson Subscribers: emaste, arichardson, jakehehrlich, MaskRay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64170 llvm-svn: 365173
* Fix patch not passing test casesAlex Brachet2019-07-051-1/+2
| | | | llvm-svn: 365170
* [llvm-objcopy] Change handling of output file permissionsAlex Brachet2019-07-041-10/+26
| | | | | | | | | | | | | | | | Summary: Address bug [[ https://bugs.llvm.org/show_bug.cgi?id=42082 | 42082 ]] where files were always outputted with 0775 permissions. Now, the output file is given either 0666 or 0777 if the object is executable. Reviewers: espindola, alexshap, rupprecht, jhenderson, jakehehrlich, MaskRay Reviewed By: rupprecht, jhenderson, jakehehrlich, MaskRay Subscribers: emaste, arichardson, jakehehrlich, MaskRay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62718 llvm-svn: 365162
* llvm-c-test avoid calling malloc(0)Andus Yu2019-07-041-6/+12
| | | | | | | | | | | | | | | | | | | Summary: As explained in D63668, malloc(0) could return a null pointer. llvm-c-test does not handle this case correctly. Instead of calling malloc(0), avoid the operation altogether. Authored By: andusy Reviewers: hubert.reinterpretcast, xingxue, jasonliu, daltenty, cebowleratibm Reviewed By: hubert.reinterpretcast Subscribers: mehdi_amini, dexonsmith, jsji, llvm-commits Tags: LLVM Differential Revision: https://reviews.llvm.org/D63788 llvm-svn: 365144
* [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
* [MachO] Add valid architecture functionShoaib Meenai2019-07-041-2/+9
| | | | | | | | | | | Added array of valid architectures and function returning array. Modified llvm-lipo to include list of valid architectures in error message for invalid arch. Patch by Anusha Basana <anusha.basana@gmail.com> Differential Revision: https://reviews.llvm.org/D63735 llvm-svn: 365099
* [JITLink][ORC] Add EHFrameRegistrar interface, use in EHFrameRegistrationPlugin.Lang Hames2019-07-041-1/+3
| | | | | | | | Replaces direct calls to eh-frame registration with calls to methods on an EHFrameRegistrar instance. This allows clients to substitute a registrar that registers frames in a remote process via IPC/RPC. llvm-svn: 365098
* [Bitcode] Move Bitstream to a separate libraryFrancis Visoiu Mistrih2019-07-033-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | This moves Bitcode/Bitstream*, Bitcode/BitCodes.h to Bitstream/. This is needed to avoid a circular dependency when using the bitstream code for parsing optimization remarks. Since Bitcode uses Core for the IR part: libLLVMRemarks -> Bitcode -> Core and Core uses libLLVMRemarks to generate remarks (see IR/RemarkStreamer.cpp): Core -> libLLVMRemarks we need to separate the Bitstream and Bitcode part. For clang-doc, it seems that it doesn't need the whole bitcode layer, so I updated the CMake to only use the bitstream part. Differential Revision: https://reviews.llvm.org/D63899 llvm-svn: 365091
* [ThinLTO] Add summary entries for index-based WPDTeresa Johnson2019-07-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If LTOUnit splitting is disabled, the module summary analysis computes the summary information necessary to perform single implementation devirtualization during the thin link with the index and no IR. The information collected from the regular LTO IR in the current hybrid WPD algorithm is summarized, including: 1) For vtable definitions, record the function pointers and their offset within the vtable initializer (subsumes the information collected from IR by tryFindVirtualCallTargets). 2) A record for each type metadata summarizing the vtable definitions decorated with that metadata (subsumes the TypeIdentiferMap collected from IR). Also added are the necessary bitcode records, and the corresponding assembly support. The follow-on index-based WPD patch is D55153. Depends on D53890. Reviewers: pcc Subscribers: mehdi_amini, Prazek, inglorion, eraman, steven_wu, dexonsmith, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54815 llvm-svn: 364960
* [lli] Fix a typo in a header.Lang Hames2019-07-021-1/+1
| | | | llvm-svn: 364956
* [llvm-objdump] Warn if no user specified sections (-j) are not found.Yuanfang Chen2019-07-021-3/+26
| | | | | | | | | | | | | | Match GNU objdump. https://bugs.llvm.org/show_bug.cgi?id=41898 Reviewers: jhenderson, grimar, MaskRay, rupprecht Reviewed by: jhenderson, grimar, MaskRay Differential Revision: https://reviews.llvm.org/D63779 llvm-svn: 364955
* [yaml2obj] - Allow overriding sh_offset field from the YAML.George Rimar2019-07-022-0/+11
| | | | | | | | | | | Some of our test cases are using objects which has sections with a broken sh_offset field. There was no way to set it from YAML until this patch. Differential revision: https://reviews.llvm.org/D63879 llvm-svn: 364898
* Cleanup: llvm::bsearch -> llvm::partition_point after r364719Fangrui Song2019-06-302-19/+20
| | | | llvm-svn: 364720
* [llvm-ar] Document response file support in --helpSam Clegg2019-06-281-0/+1
| | | | | | | | Also a test for this. Differential Revision: https://reviews.llvm.org/D63836 llvm-svn: 364673
* [llvm-cov[ Fix lcov coverage report contains functions from other ↵Max Moroz2019-06-281-1/+1
| | | | | | | | | | | | | | | | | | compilation units. Summary: Patch by Chuan Qiu (@eagleonhill). Reviewers: Dor1s Reviewed By: Dor1s Subscribers: lebedev.ri, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63571 llvm-svn: 364653
* [llvm-nm] Fix for BZ41711 - Class character for a symbol with undefinedChris Jackson2019-06-271-1/+6
| | | | | | | | | | binding does not match class assigned by GNU nm Bugzilla: https://bugs.llvm.org/show_bug.cgi?id=41711 Differential Revision: https://reviews.llvm.org/D63340 llvm-svn: 364559
* [yaml2obj] - Allow overriding e_shentsize, e_shoff, e_shnum and e_shstrndx ↵George Rimar2019-06-272-5/+13
| | | | | | | | | | | | fields in the YAML. This allows setting different values for e_shentsize, e_shoff, e_shnum and e_shstrndx fields and is useful for producing broken inputs for various test cases. Differential revision: https://reviews.llvm.org/D63771 llvm-svn: 364517
* BitStream reader: propagate errorsJF Bastien2019-06-261-38/+93
| | | | | | | | | | | | | | | | | | | | | | The bitstream reader handles errors poorly. This has two effects: * Bugs in file handling (especially modules) manifest as an "unexpected end of file" crash * Users of clang as a library end up aborting because the code unconditionally calls `report_fatal_error` The bitstream reader should be more resilient and return Expected / Error as soon as an error is encountered, not way late like it does now. This patch starts doing so and adopting the error handling where I think it makes sense. There's plenty more to do: this patch propagates errors to be minimally useful, and follow-ups will propagate them further and improve diagnostics. https://bugs.llvm.org/show_bug.cgi?id=42311 <rdar://problem/33159405> Differential Revision: https://reviews.llvm.org/D63518 llvm-svn: 364464
* llvm-objcopy: silence warning introduced in r364296Nicolai Haehnle2019-06-262-2/+6
| | | | | Change-Id: I306e866d497e55945fb3b471eb0727b63ad9e4b9 llvm-svn: 364460
* [xray] Remove usage of procid_tAlexandre Ganea2019-06-262-12/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D61946 llvm-svn: 364439
* Revert "r364412 [ExpandMemCmp][MergeICmps] Move passes out of CodeGen into ↵Clement Courbet2019-06-261-0/+1
| | | | | | | | | | | | | | opt pipeline." Breaks sanitizers: libFuzzer :: cxxstring.test libFuzzer :: memcmp.test libFuzzer :: recommended-dictionary.test libFuzzer :: strcmp.test libFuzzer :: value-profile-mem.test libFuzzer :: value-profile-strcmp.test llvm-svn: 364416
* [ExpandMemCmp][MergeICmps] Move passes out of CodeGen into opt pipeline.Clement Courbet2019-06-261-1/+0
| | | | | | | | | This allows later passes (in particular InstCombine) to optimize more cases. One that's important to us is `memcmp(p, q, constant) < 0` and memcmp(p, q, constant) > 0. llvm-svn: 364412
* Revert [llvm-objcopy][NFC] Refactor output target parsingRumeet Dhindsa2019-06-264-86/+36
| | | | | | | | | | | | | | | | This reverts r364254 (git commit 545f001d1b9a7b58a68d75e70bfc36c841de8999) This change causes some llvm-obcopy tests to fail with valgrind. Following is the output for basic-keep.test Command Output (stderr): -- ==107406== Conditional jump or move depends on uninitialised value(s) ==107406== at 0x1A30DD: executeObjcopy(llvm::objcopy::CopyConfig const&) (llvm-objcopy.cpp:235) ==107406== by 0x1A3935: main (llvm-objcopy.cpp:294) llvm-svn: 364379
* Revert [llvm-objcopy][NFCI] Fix build failure with GCCRumeet Dhindsa2019-06-261-2/+0
| | | | | | | | | | | | This reverts r364263 (git commit 81eb82840524818ec0ec14285c866c09b9634df0) This commit is related to r364254 which is causing some llvm-objcopy tests to fail with valgrind. Error: Conditional jump or move depends on uninitialised value(s) llvm-svn: 364378
* [llvm-shlib] Do not use version script when building with MinGWPirama Arumuga Nainar2019-06-251-1/+1
| | | | | | | | | | | | | | | | Summary: The MinGW driver for lld does not support the --version-script option. For GNU ld, it's a no-op since LLVM.dll exports all symbols. Reviewers: srhines, mstorsjo Subscribers: mgorny, fedor.sergeev, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63743 llvm-svn: 364343
* [llvm-objcopy][llvm-strip] Fix help text typo for --allow-broken-linksJames Henderson2019-06-252-2/+2
| | | | llvm-svn: 364307
* AMDGPU/MC: Add .amdgpu_lds directiveNicolai Haehnle2019-06-252-13/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The directive defines a symbol as an group/local memory (LDS) symbol. LDS symbols behave similar to common symbols for the purposes of ELF, using the processor-specific SHN_AMDGPU_LDS as section index. It is the linker and/or runtime loader's job to "instantiate" LDS symbols and resolve relocations that reference them. It is not possible to initialize LDS memory (not even zero-initialize as for .bss). We want to be able to link together objects -- starting with relocatable objects, but possible expanding to shared objects in the future -- that access LDS memory in a flexible way. LDS memory is in an address space that is entirely separate from the address space that contains the program image (code and normal data), so having program segments for it doesn't really make sense. Furthermore, we want to be able to compile multiple kernels in a compilation unit which have disjoint use of LDS memory. In that case, we may want to place LDS symbols differently for different kernels to save memory (LDS memory is very limited and physically private to each kernel invocation), so we can't simply place LDS symbols in a .lds section. Hence this solution where LDS symbols always stay undefined. Change-Id: I08cbc37a7c0c32f53f7b6123aa0afc91dbc1748f Reviewers: arsenm, rampitec, t-tye, b-sumner, jsjodin Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61493 llvm-svn: 364296
* [yaml2obj/obj2yaml] - Allow having the symbols and sections with duplicated ↵George Rimar2019-06-252-33/+70
| | | | | | | | | | | | names. The patch teaches yaml2obj/obj2yaml to support parsing/dumping the sections and symbols with the same name. A special suffix is added to a name to make it unique. Differential revision: https://reviews.llvm.org/D63596 llvm-svn: 364282
* [llvm-objcopy][NFCI] Fix build failure with GCCSeiya Nuta2019-06-251-0/+2
| | | | | | Here is unreachable since the switch statement above is exhaustive. llvm-svn: 364263
* [llvm-objcopy][NFC] Refactor output target parsingSeiya Nuta2019-06-254-36/+86
| | | | | | | | | | | | | | | | | Summary: Use an enum instead of string to hold the output file format in Config.InputFormat and Config.OutputFormat. It's essential to support other output file formats other than ELF. Reviewers: espindola, alexshap, rupprecht, jhenderson Reviewed By: rupprecht, jhenderson Subscribers: jyknight, compnerd, emaste, arichardson, fedor.sergeev, jakehehrlich, MaskRay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63239 llvm-svn: 364254
* [llvm-objcopy][MachO] Fix strict-aliasing warning. NFCISeiya Nuta2019-06-241-3/+1
| | | | | | | | | | | | | | | | | | | Summary: Use MachOObjectFile::isRelocationScattered instead of reinterpret_cast. Fixes https://bugs.llvm.org/show_bug.cgi?id=42360 Reviewers: alexshap, rupprecht, jhenderson Reviewed By: alexshap Subscribers: dendibakh, bjope, uabelho, jakehehrlich, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63699 llvm-svn: 364252
* llvm-symbolizer: Add a FRAME command.Peter Collingbourne2019-06-241-7/+24
| | | | | | | | | | | | | | | | | | | This command prints a description of the referenced function's stack frame. For each formal parameter and local variable, the tool prints: - function name - variable name - file/line of declaration - FP-relative variable location (if available) - size in bytes - HWASAN tag offset This information will be used by the HWASAN runtime to identify local variables in UAR reports. Differential Revision: https://reviews.llvm.org/D63468 llvm-svn: 364225
* [llvm-objdump] Match GNU objdump on symbol types shown in disassemblyYuanfang Chen2019-06-241-6/+13
| | | | | | | | | | | | output. STT_OBJECT and STT_COMMON are dumped as data, not disassembled. https://bugs.llvm.org/show_bug.cgi?id=41947 Differential Revision: https://reviews.llvm.org/D62964 llvm-svn: 364211
* [sancov] Avoid unnecessary unique_ptrFangrui Song2019-06-241-12/+10
| | | | llvm-svn: 364175
* [llvm-objdump] Allow --disassemble-functions to take demangled namesYuanfang Chen2019-06-221-9/+10
| | | | | | | | | | | | | The --disassemble-functions switch takes demangled names when --demangle is specified, otherwise the switch takes mangled names. https://bugs.llvm.org/show_bug.cgi?id=41908 Reviewers: jhenderson, grimar, MaskRay, rupprecht Differential Revision: https://reviews.llvm.org/D63524 llvm-svn: 364121
* [llvm-objdump] Move --start-address >= --stop-address check out of theYuanfang Chen2019-06-221-3/+3
| | | | | | | | | | | | | | | | | | | | -d code. Summary: Move it into `main` function so the checking is effective for all actions user may do with llvm-objdump; notably, -r and -s in addition to existing -d. Match GNU behavior. Reviewers: jhenderson, grimar, MaskRay, rupprecht Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63631 llvm-svn: 364118
* [llvm-lipo] Implement -thinShoaib Meenai2019-06-212-4/+85
| | | | | | | | | | Creates thin output file of specified arch_type from the fat input file. Patch by Anusha Basana <anushabasana@fb.com> Differential Revision: https://reviews.llvm.org/D63341 llvm-svn: 364107
* [MCA][Bottleneck Analysis] Teach how to compute a critical sequence of ↵Andrea Di Biagio2019-06-212-39/+355
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | instructions based on the simulation. This patch teaches the bottleneck analysis how to identify and print the most expensive sequence of instructions according to the simulation. Fixes PR37494. The goal is to help users identify the sequence of instruction which is most critical for performance. A dependency graph is internally used by the bottleneck analysis to describe data dependencies and processor resource interferences between instructions. There is one node in the graph for every instruction in the input assembly sequence. The number of nodes in the graph is independent from the number of iterations simulated by the tool. It means that a single node of the graph represents all the possible instances of a same instruction contributed by the simulated iterations. Edges are dynamically "discovered" by the bottleneck analysis by observing instruction state transitions and "backend pressure increase" events generated by the Execute stage. Information from the events is used to identify critical dependencies, and materialize edges in the graph. A dependency edge is uniquely identified by a pair of node identifiers plus an instance of struct DependencyEdge::Dependency (which provides more details about the actual dependency kind). The bottleneck analysis internally ranks dependency edges based on their impact on the runtime (see field DependencyEdge::Dependency::Cost). To this end, each edge of the graph has an associated cost. By default, the cost of an edge is a function of its latency (in cycles). In practice, the cost of an edge is also a function of the number of cycles where the dependency has been seen as 'contributing to backend pressure increases'. The idea is that the higher the cost of an edge, the higher is the impact of the dependency on performance. To put it in another way, the cost of an edge is a measure of criticality for performance. Note how a same edge may be found in multiple iteration of the simulated loop. The logic that adds new edges to the graph checks if an equivalent dependency already exists (duplicate edges are not allowed). If an equivalent dependency edge is found, field DependencyEdge::Frequency of that edge is incremented by one, and the new cost is cumulatively added to the existing edge cost. At the end of simulation, costs are propagated to nodes through the edges of the graph. The goal is to identify a critical sequence from a node of the root-set (composed by node of the graph with no predecessors) to a 'sink node' with no successors. Note that the graph is intentionally kept acyclic to minimize the complexity of the critical sequence computation algorithm (complexity is currently linear in the number of nodes in the graph). The critical path is finally computed as a sequence of dependency edges. For edges describing processor resource interferences, the view also prints a so-called "interference probability" value (by dividing field DependencyEdge::Frequency by the total number of iterations). Examples of critical sequence computations can be found in tests added/modified by this patch. On output streams that support colored output, instructions from the critical sequence are rendered with a different color. Strictly speaking the analysis conducted by the bottleneck analysis view is not a critical path analysis. The cost of an edge doesn't only depend on the dependency latency. More importantly, the cost of a same edge may be computed differently by different iterations. The number of dependencies is discovered dynamically based on the events generated by the simulator. However, their number is not fixed. This is especially true for edges that model processor resource interferences; an interference may not occur in every iteration. For that reason, it makes sense to also print out a "probability of interference". By construction, the accuracy of this analysis (as always) is strongly dependent on the simulation (and therefore the quality of the information available in the scheduling model). That being said, the critical sequence effectively identifies a performance criticality. Instructions from that sequence are expected to have a very big impact on performance. So, users can take advantage of this information to focus their attention on specific interactions between instructions. In my experience, it works quite well in practice, and produces useful output (in a reasonable amount time). Differential Revision: https://reviews.llvm.org/D63543 llvm-svn: 364045
OpenPOWER on IntegriCloud