summaryrefslogtreecommitdiffstats
path: root/llvm/test/Other
Commit message (Collapse)AuthorAgeFilesLines
* [HotColdSplit] Move splitting after instrumented PGO useTeresa Johnson2019-02-063-0/+19
| | | | | | | | | | | | | | | | | | | | | Summary: Follow up to D57082 which moved splitting earlier in the pipeline, in order to perform it before inlining. However, it was moved too early, before the IR is annotated with instrumented PGO data. This caused the splitting to incorrectly determine cold functions. Move it to just after PGO annotation (still before inlining), in both pass managers. Reviewers: vsk, hiraditya, sebpop Subscribers: mehdi_amini, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57805 llvm-svn: 353270
* [SamplePGO] More pipeline changes when flattened profile used in ThinLTO ↵Teresa Johnson2019-02-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | postlink Summary: Follow on to D54819/r351476. We also don't need to perform extra InstCombine pass when we aren't loading the sample profile in the ThinLTO backend because we have a flattened sample profile. Additionally, for consistency and clarity, when we aren't reloading the sample profile, perform ICP in the same location as non-sample PGO backends. To this end I have moved the ICP invocation for non-SamplePGO ThinLTO down into buildModuleSimplificationPipeline (partly addresses the FIXME where we were previously setting this up). Reviewers: wmi Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57705 llvm-svn: 353135
* Add a 'dynamic' parameter to the objectsize intrinsicErik Pilkington2019-01-301-2/+2
| | | | | | | | | | | | | | This is meant to be used with clang's __builtin_dynamic_object_size. When 'true' is passed to this parameter, the intrinsic has the potential to be folded into instructions that will be evaluated at run time. When 'false', the objectsize intrinsic behaviour is unchanged. rdar://32212419 Differential revision: https://reviews.llvm.org/D56761 llvm-svn: 352664
* Try to address Windows bot failure after r352080Vedant Kumar2019-01-251-4/+2
| | | | | | | | | See the bot error message reported in https://reviews.llvm.org/D57082. Avoid trying to match full class names in -debug-pass-manager output, because they aren't portable. llvm-svn: 352138
* [HotColdSplit] Move splitting earlier in the pipelineVedant Kumar2019-01-243-298/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Performing splitting early has several advantages: - Inhibiting inlining of cold code early improves code size. Compared to scheduling splitting at the end of the pipeline, this cuts code size growth in half within the iOS shared cache (0.69% to 0.34%). - Inhibiting inlining of cold code improves compile time. There's no need to inline split cold functions, or to inline as much *within* those split functions as they are marked `minsize`. - During LTO, extra work is only done in the pre-link step. Less code must be inlined during cross-module inlining. An additional motivation here is that the most common cold regions identified by the static/conservative splitting heuristic can (a) be found before inlining and (b) do not grow after inlining. E.g. __assert_fail, os_log_error. The disadvantages are: - Some opportunities for splitting out cold code may be missed. This gap can potentially be narrowed by adding a worklist algorithm to the splitting pass. - Some opportunities to reduce code size may be lost (e.g. store sinking, when one side of the CFG diamond is split). This does not outweigh the code size benefits of splitting earlier. On net, splitting early in the pipeline has substantial code size benefits, and no major effects on memory locality or performance. We measured memory locality using ktrace data, and consistently found that 10% fewer pages were needed to capture 95% of text page faults in key iOS benchmarks. We measured performance on frequency-stabilized iOS devices using LNT+externals. This reverses course on the decision made to schedule splitting late in r344869 (D53437). Differential Revision: https://reviews.llvm.org/D57082 llvm-svn: 352080
* [PGO] Make pgo related options in opt more consistent.Wei Mi2019-01-161-5/+5
| | | | | | | | | | | | | | | Currently we have pgo options defined in PassManagerBuilder.cpp only for instrument pgo, but not for sample pgo. We also have pgo options defined in NewPMDriver.cpp in opt only for new pass manager and for all kinds of pgo. They have some inconsistency. To make the options more consistent and make tests writing easier, the patch let old pass manager to share the same pgo options with new pass manager in opt, and removes the options in PassManagerBuilder.cpp. Differential Revision: https://reviews.llvm.org/D56749 llvm-svn: 351392
* Python compat - print statementSerge Guelton2019-01-031-0/+2
| | | | | | | | | Make sure all print statements are compatible with Python 2 and Python3 using the `from __future__ import print_function` statement. Differential Revision: https://reviews.llvm.org/D56249 llvm-svn: 350307
* [NewPM] -print-module-scope -print-after now prints module even after ↵Fedor Sergeev2018-12-212-1/+5
| | | | | | | | | | | | | | | | | | | invalidated Loop/SCC -print-after IR printing generally can not print the IR unit (Loop or SCC) which has just been invalidated by the pass. However, when working in -print-module-scope mode even if Loop was invalidated there is still a valid module that we can print. Since we can not access invalidated IR unit from AfterPassInvalidated instrumentation point we can remember the module to be printed *before* pass. This change introduces BeforePass instrumentation that stores all the information required for module printing into the stack and then after pass (in AfterPassInvalidated) just print whatever has been placed on stack. Reviewed By: philip.pfaffe Differential Revision: https://reviews.llvm.org/D55278 llvm-svn: 349896
* [Unroll/UnrollAndJam/Vectorizer/Distribute] Add followup loop attributes.Michael Kruse2018-12-126-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When multiple loop transformation are defined in a loop's metadata, their order of execution is defined by the order of their respective passes in the pass pipeline. For instance, e.g. #pragma clang loop unroll_and_jam(enable) #pragma clang loop distribute(enable) is the same as #pragma clang loop distribute(enable) #pragma clang loop unroll_and_jam(enable) and will try to loop-distribute before Unroll-And-Jam because the LoopDistribute pass is scheduled after UnrollAndJam pass. UnrollAndJamPass only supports one inner loop, i.e. it will necessarily fail after loop distribution. It is not possible to specify another execution order. Also,t the order of passes in the pipeline is subject to change between versions of LLVM, optimization options and which pass manager is used. This patch adds 'followup' attributes to various loop transformation passes. These attributes define which attributes the resulting loop of a transformation should have. For instance, !0 = !{!0, !1, !2} !1 = !{!"llvm.loop.unroll_and_jam.enable"} !2 = !{!"llvm.loop.unroll_and_jam.followup_inner", !3} !3 = !{!"llvm.loop.distribute.enable"} defines a loop ID (!0) to be unrolled-and-jammed (!1) and then the attribute !3 to be added to the jammed inner loop, which contains the instruction to distribute the inner loop. Currently, in both pass managers, pass execution is in a fixed order and UnrollAndJamPass will not execute again after LoopDistribute. We hope to fix this in the future by allowing pass managers to run passes until a fixpoint is reached, use Polly to perform these transformations, or add a loop transformation pass which takes the order issue into account. For mandatory/forced transformations (e.g. by having been declared by #pragma omp simd), the user must be notified when a transformation could not be performed. It is not possible that the responsible pass emits such a warning because the transformation might be 'hidden' in a followup attribute when it is executed, or it is not present in the pipeline at all. For this reason, this patche introduces a WarnMissedTransformations pass, to warn about orphaned transformations. Since this changes the user-visible diagnostic message when a transformation is applied, two test cases in the clang repository need to be updated. To ensure that no other transformation is executed before the intended one, the attribute `llvm.loop.disable_nonforced` can be added which should disable transformation heuristics before the intended transformation is applied. E.g. it would be surprising if a loop is distributed before a #pragma unroll_and_jam is applied. With more supported code transformations (loop fusion, interchange, stripmining, offloading, etc.), transformations can be used as building blocks for more complex transformations (e.g. stripmining+stripmining+interchange -> tiling). Reviewed By: hfinkel, dmgreen Differential Revision: https://reviews.llvm.org/D49281 Differential Revision: https://reviews.llvm.org/D55288 llvm-svn: 348944
* [NewPM] fixing asserts on deleted loop in -print-after-allFedor Sergeev2018-12-112-0/+49
| | | | | | | | | | | IR-printing AfterPass instrumentation might be called on a loop that has just been invalidated. We should skip printing it to avoid spurious asserts. Reviewed By: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D54740 llvm-svn: 348887
* Fixing -print-module-scope for legacy SCC passesFedor Sergeev2018-12-031-0/+7
| | | | | | | | | | It appears that print-module-scope was not implemented for legacy SCC passes. Fixed to print a whole module instead of just current SCC. Reviewed By: mkazantsev Differential Revision: https://reviews.llvm.org/D54793 llvm-svn: 348144
* Print newline after banner for ModulePassSven van Haastregt2018-11-141-0/+2
| | | | | | | | | | Before this commit, `llc -print-after-all` would print something like: *** IR Dump After Pre-ISel Intrinsic Lowering ***; ModuleID = ... Emit a newline such that ModuleID appears on a line by its own. llvm-svn: 346844
* Recommit r346483: [CallSiteSplitting] Only record conditions up to the ↵Florian Hahn2018-11-142-2/+3
| | | | | | | | | IDom(call site). The underlying problem causing the expensive-check failure was fixed in rL346769. llvm-svn: 346843
* Add an OptimizerLast EPPhilip Pfaffe2018-11-121-0/+6
| | | | | | | | | | | | | | | | | Summary: It turns out that we need an OptimizerLast PassBuilder extension point after all. I missed the relevance of this EP the first time. By legacy PM magic, function passes added at this EP get added to the last _Function_ PM, which is a feature we lost when dropping this EP for the new PM. A key difference between this and the legacy PassManager's OptimizerLast callback is that this extension point is not triggered at O0. Extensions to the O0 pipeline should append their passes to the end of the overall pipeline. Differential Revision: https://reviews.llvm.org/D54374 llvm-svn: 346645
* Revert r346483: [CallSiteSplitting] Only record conditions up to the ↵Florian Hahn2018-11-092-3/+2
| | | | | | | | IDom(call site). This cause a failure with EXPENSIVE_CHECKS llvm-svn: 346492
* [CallSiteSplitting] Only record conditions up to the IDom(call site).Florian Hahn2018-11-092-2/+3
| | | | | | | | | | | | | | | | | | | | | | | We can stop recording conditions once we reached the immediate dominator for the block containing the call site. Conditions in predecessors of the that node will be the same for all paths to the call site and splitting is not beneficial. This patch makes CallSiteSplitting dependent on the DT anlysis. because the immediate dominators seem to be the easiest way of finding the node to stop at. I had to update some exiting tests, because they were checking for conditions that were true/false on all paths to the call site. Those should now be handled by instcombine/ipsccp. Reviewers: davide, junbuml Reviewed By: junbuml Differential Revision: https://reviews.llvm.org/D44627 llvm-svn: 346483
* [hot-cold-split] Only perform splitting in ThinLTO backend post-linkTeresa Johnson2018-10-231-0/+4
| | | | | | | | | | | | | | | | | Summary: Fix the new PM to only perform hot cold splitting once during ThinLTO, by skipping it in the pre-link phase. This was already fixed in the old PM by the move of the hot cold split pass later (after the early return when PrepareForThinLTO) by r344869. Reviewers: vsk, sebpop, hiraditya Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D53611 llvm-svn: 345096
* Actually fix test from r345085 REQUIRE: assertsFangrui Song2018-10-231-1/+1
| | | | llvm-svn: 345090
* Fix test after r345085Fangrui Song2018-10-231-0/+2
| | | | llvm-svn: 345089
* Print out DebugCounter info with -print-debug-counterZhizhou Yang2018-10-231-0/+30
| | | | | | | | | | | | | | | | | | | Summary: This patch will print out {Counter, Skip, StopAfter} info of all passes which have DebugCounter set at destruction. It can be used to monitor how many times does certain transformation happen in a pass, and also help check if -debug-counter option is set correctly. Please refer to this [[ http://lists.llvm.org/pipermail/llvm-dev/2018-July/124722.html | thread ]] for motivation. Reviewers: george.burgess.iv, davide, greened Reviewed By: greened Subscribers: kristina, llozano, mgorny, llvm-commits, mgrang Differential Revision: https://reviews.llvm.org/D50031 llvm-svn: 345085
* [test] Relax test/Other/opt-hot-cold-split.llVedant Kumar2018-10-221-2/+2
| | | | | | | | | | | On some ARM bots, 'Target Pass Configuration' does not run after 'Target Transform Info'. Relax this pipeline test to allow that. This is the same fix as in r328167. Bot URL: http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/4611 llvm-svn: 344919
* Schedule Hot Cold Splitting pass after most optimization passesAditya Kumar2018-10-211-0/+292
| | | | | | | | | | | | | | | | Summary: In the new+old pass manager, hot cold splitting was schedule too early. Thanks to Vedant for pointing this out. Reviewers: sebpop, vsk Reviewed By: sebpop, vsk Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D53437 llvm-svn: 344869
* [NewPM] Fixing test failure on Windows - removed opt binary name from patternFedor Sergeev2018-10-171-4/+4
| | | | llvm-svn: 344686
* [NewPM] teach -passes= to emit meaningful error messagesFedor Sergeev2018-10-171-17/+66
| | | | | | | | | | | | | | All the PassBuilder::parse interfaces now return descriptive StringError instead of a plain bool. It allows to make -passes/aa-pipeline parsing errors context-specific and thus less confusing. TODO: ideally we should also make suggestions for misspelled pass names, but that requires some extensions to PassBuilder. Reviewed By: philip.pfaffe, chandlerc Differential Revision: https://reviews.llvm.org/D53246 llvm-svn: 344685
* Revert "[NewPM] teach -passes= to emit meaningful error messages"Fedor Sergeev2018-10-151-66/+17
| | | | | | This reverts r344519 due to failures in pipeline-parsing test. llvm-svn: 344524
* [NewPM] teach -passes= to emit meaningful error messagesFedor Sergeev2018-10-151-17/+66
| | | | | | | | | | | | | | | Summary: All the PassBuilder::parse interfaces now return descriptive StringError instead of a plain bool. It allows to make -passes/aa-pipeline parsing errors context-specific and thus less confusing. TODO: ideally we should also make suggestions for misspelled pass names, but that requires some extensions to PassBuilder. Reviewed By: philip.pfaffe, chandlerc Differential Revision: https://reviews.llvm.org/D53246 llvm-svn: 344519
* [NewPM] implement SCC printing for -print-before-all/-print-after-allFedor Sergeev2018-10-151-0/+49
| | | | | | | | | | | | Removing deficiency of initial implementation of -print-before-all/-after-all - it was effectively skipping IR printing for all the SCC passes. Now LazyCallGraph:SCC gets its IR printed. Reviewed By: skatkov Differential Revision: https://reviews.llvm.org/D53270 llvm-svn: 344505
* Make YAML quote forward slashes.Zachary Turner2018-10-121-2/+2
| | | | | | | | | | | | | | | | | If you have the string /usr/bin, prior to this patch it would not be quoted by our YAML serializer. But a string like C:\src would be, due to the presence of a backslash. This makes the quoting rules of basically every single file path different depending on the path syntax (posix vs. Windows). While technically not required by the YAML specification to quote forward slashes, when the behavior of paths is inconsistent it makes it difficult to portably write FileCheck lines that will work with either kind of path. Differential Revision: https://reviews.llvm.org/D53169 llvm-svn: 344359
* Revert "Make YAML quote forward slashes."Zachary Turner2018-10-121-2/+2
| | | | | | | | | | This reverts commit b86c16ad8c97dadc1f529da72a5bb74e9eaed344. This is being reverted because I forgot to write a useful commit message, so I'm going to resubmit it with an actual commit message. llvm-svn: 344358
* Make YAML quote forward slashes.Zachary Turner2018-10-121-2/+2
| | | | llvm-svn: 344357
* [CFG Printer] Add support for writing the dot files with a customChandler Carruth2018-10-091-2/+2
| | | | | | | | | | prefix. Use this to direct these files to a specific location in the test suite so that we don't write files out to random directories (or fail if the working directory isn't writable). llvm-svn: 344014
* Fix incorrect Twine usage in CFGPrinterKristina Brooks2018-10-081-0/+19
| | | | | | | | | | | | | | | | CFGPrinter (-view-cfg, -dot-cfg) invokes an undefined behaviour (dangling pointer to rvalue) on IR files with branch weights. This patch fixes the problem caused by Twine initialization and string conversion split into two statements. This change fixes the bug 37019. A similar patch to this problem was provided in the llvmlite project Patch by mcopik (Marcin Copik). Differential Revision: https://reviews.llvm.org/D52933 llvm-svn: 343984
* [New PM][PassTiming] implement -time-passes for the new pass managerFedor Sergeev2018-10-051-2/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enable time-passes functionality through PassInstrumentation callbacks for passes and analyses. TimePassesHandler class keeps all the callbacks, the timing data as it is being collected as well as the stack of currently active timers. Parts of the fix that might be somewhat unobvious: - mapping of passes into Timer (TimingData) can not be done per-instance. PassID name provided into the callback is common for all the pass invocations. Thus the only way to get a timing with reasonable granularity is to collect timing data per pass invocation, getting a new timer for each BeforePass. Hence the key for TimingData uses a pair of <StringRef/unsigned count> to uniquely identify a pass invocation. - consequently, this new-pass-manager implementation performs no aggregation of timing data, reporting timings for each pass invocation separately. In that it differs from legacy-pass-manager time-passes implementation that reports timing data aggregated per pass instance. - pass managers and adaptors are not tracked, similar to how pass managers are not tracked in legacy time-passes. - TimerStack tracks timers that are active, each BeforePass pushes the new timer on stack, each AfterPass pops active timer from stack and stops it. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D51276 llvm-svn: 343898
* Temporarily revert "[GVNHoist] Re-enable GVNHoist by default"Eric Christopher2018-10-015-26/+22
| | | | | | | | | This reverts commit r342387 as it's showing significant performance regressions in a number of benchmarks. Followed up with the committer and original thread with an example and will get performance numbers before recommitting. llvm-svn: 343522
* [CodeGen] fix broken successor probability in MBB dumpHiroshi Inoue2018-09-281-0/+25
| | | | | | | | | | When printing successor probabilities for a MBB, a human readable value is sometimes shown as 200.0%. The human readable output is based on getProbabilityIterator, which returns 0xFFFFFFFF for getNumerator() and 0x80000000 for getDenominator() for unknown BranchProbability. By using getSuccProbability as we do for the non-human readable part, we can avoid this problem. Differential Revision: https://reviews.llvm.org/D52605 llvm-svn: 343297
* [New PM][PassInstrumentation] IR printing support for New Pass ManagerFedor Sergeev2018-09-243-18/+44
| | | | | | | | | | | | | | | | Implementing -print-before-all/-print-after-all/-filter-print-func support through PassInstrumentation callbacks. - PrintIR routines implement printing callbacks. - StandardInstrumentations class provides a central place to manage all the "standard" in-tree pass instrumentations. Currently it registers PrintIR callbacks. Reviewers: chandlerc, paquette, philip.pfaffe Differential Revision: https://reviews.llvm.org/D50923 llvm-svn: 342896
* [New PM][PassInstrumentation] Adding PassInstrumentation to the ↵Fedor Sergeev2018-09-212-1/+4
| | | | | | | | | | | | | | | AnalysisManager runs As a prerequisite to time-passes implementation which needs to time both passes and analyses, adding instrumentation points to the Analysis Manager. The are two functional differences between Pass and Analysis instrumentation: - the latter does not increment pass execution counter - it does not provide ability to skip execution of the corresponding analysis Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D51275 llvm-svn: 342778
* [New PM] Introducing PassInstrumentation frameworkFedor Sergeev2018-09-205-3/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pass Execution Instrumentation interface enables customizable instrumentation of pass execution, as per "RFC: Pass Execution Instrumentation interface" posted 06/07/2018 on llvm-dev@ The intent is to provide a common machinery to implement all the pass-execution-debugging features like print-before/after, opt-bisect, time-passes etc. Here we get a basic implementation consisting of: * PassInstrumentationCallbacks class that handles registration of callbacks and access to them. * PassInstrumentation class that handles instrumentation-point interfaces that call into PassInstrumentationCallbacks. * Callbacks accept StringRef which is just a name of the Pass right now. There were some ideas to pass an opaque wrapper for the pointer to pass instance, however it appears that pointer does not actually identify the instance (adaptors and managers might have the same address with the pass they govern). Hence it was decided to go simple for now and then later decide on what the proper mental model of identifying a "pass in a phase of pipeline" is. * Callbacks accept llvm::Any serving as a wrapper for const IRUnit*, to remove direct dependencies on different IRUnits (e.g. Analyses). * PassInstrumentationAnalysis analysis is explicitly requested from PassManager through usual AnalysisManager::getResult. All pass managers were updated to run that to get PassInstrumentation object for instrumentation calls. * Using tuples/index_sequence getAnalysisResult helper to extract generic AnalysisManager's extra args out of a generic PassManager's extra args. This is the only way I was able to explicitly run getResult for PassInstrumentationAnalysis out of a generic code like PassManager::run or RepeatedPass::run. TODO: Upon lengthy discussions we agreed to accept this as an initial implementation and then get rid of getAnalysisResult by improving RepeatedPass implementation. * PassBuilder takes PassInstrumentationCallbacks object to pass it further into PassInstrumentationAnalysis. Callbacks registration should be performed directly through PassInstrumentationCallbacks. * new-pm tests updated to account for PassInstrumentationAnalysis being run * Added PassInstrumentation tests to PassBuilderCallbacks unit tests. Other unit tests updated with registration of the now-required PassInstrumentationAnalysis. Made getName helper to return std::string (instead of StringRef initially) to fix asan builtbot failures on CGSCC tests. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D47858 llvm-svn: 342664
* Temporarily Revert "[New PM] Introducing PassInstrumentation framework"Eric Christopher2018-09-205-36/+3
| | | | | | | | as it was causing failures in the asan buildbot. This reverts commit r342597. llvm-svn: 342616
* [New PM] Introducing PassInstrumentation frameworkFedor Sergeev2018-09-195-3/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pass Execution Instrumentation interface enables customizable instrumentation of pass execution, as per "RFC: Pass Execution Instrumentation interface" posted 06/07/2018 on llvm-dev@ The intent is to provide a common machinery to implement all the pass-execution-debugging features like print-before/after, opt-bisect, time-passes etc. Here we get a basic implementation consisting of: * PassInstrumentationCallbacks class that handles registration of callbacks and access to them. * PassInstrumentation class that handles instrumentation-point interfaces that call into PassInstrumentationCallbacks. * Callbacks accept StringRef which is just a name of the Pass right now. There were some ideas to pass an opaque wrapper for the pointer to pass instance, however it appears that pointer does not actually identify the instance (adaptors and managers might have the same address with the pass they govern). Hence it was decided to go simple for now and then later decide on what the proper mental model of identifying a "pass in a phase of pipeline" is. * Callbacks accept llvm::Any serving as a wrapper for const IRUnit*, to remove direct dependencies on different IRUnits (e.g. Analyses). * PassInstrumentationAnalysis analysis is explicitly requested from PassManager through usual AnalysisManager::getResult. All pass managers were updated to run that to get PassInstrumentation object for instrumentation calls. * Using tuples/index_sequence getAnalysisResult helper to extract generic AnalysisManager's extra args out of a generic PassManager's extra args. This is the only way I was able to explicitly run getResult for PassInstrumentationAnalysis out of a generic code like PassManager::run or RepeatedPass::run. TODO: Upon lengthy discussions we agreed to accept this as an initial implementation and then get rid of getAnalysisResult by improving RepeatedPass implementation. * PassBuilder takes PassInstrumentationCallbacks object to pass it further into PassInstrumentationAnalysis. Callbacks registration should be performed directly through PassInstrumentationCallbacks. * new-pm tests updated to account for PassInstrumentationAnalysis being run * Added PassInstrumentation tests to PassBuilderCallbacks unit tests. Other unit tests updated with registration of the now-required PassInstrumentationAnalysis. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D47858 llvm-svn: 342597
* Revert rL342544: [New PM] Introducing PassInstrumentation frameworkFedor Sergeev2018-09-195-36/+3
| | | | | | A bunch of bots fail to compile unittests. Reverting. llvm-svn: 342552
* [New PM] Introducing PassInstrumentation frameworkFedor Sergeev2018-09-195-3/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Pass Execution Instrumentation interface enables customizable instrumentation of pass execution, as per "RFC: Pass Execution Instrumentation interface" posted 06/07/2018 on llvm-dev@ The intent is to provide a common machinery to implement all the pass-execution-debugging features like print-before/after, opt-bisect, time-passes etc. Here we get a basic implementation consisting of: * PassInstrumentationCallbacks class that handles registration of callbacks and access to them. * PassInstrumentation class that handles instrumentation-point interfaces that call into PassInstrumentationCallbacks. * Callbacks accept StringRef which is just a name of the Pass right now. There were some ideas to pass an opaque wrapper for the pointer to pass instance, however it appears that pointer does not actually identify the instance (adaptors and managers might have the same address with the pass they govern). Hence it was decided to go simple for now and then later decide on what the proper mental model of identifying a "pass in a phase of pipeline" is. * Callbacks accept llvm::Any serving as a wrapper for const IRUnit*, to remove direct dependencies on different IRUnits (e.g. Analyses). * PassInstrumentationAnalysis analysis is explicitly requested from PassManager through usual AnalysisManager::getResult. All pass managers were updated to run that to get PassInstrumentation object for instrumentation calls. * Using tuples/index_sequence getAnalysisResult helper to extract generic AnalysisManager's extra args out of a generic PassManager's extra args. This is the only way I was able to explicitly run getResult for PassInstrumentationAnalysis out of a generic code like PassManager::run or RepeatedPass::run. TODO: Upon lengthy discussions we agreed to accept this as an initial implementation and then get rid of getAnalysisResult by improving RepeatedPass implementation. * PassBuilder takes PassInstrumentationCallbacks object to pass it further into PassInstrumentationAnalysis. Callbacks registration should be performed directly through PassInstrumentationCallbacks. * new-pm tests updated to account for PassInstrumentationAnalysis being run * Added PassInstrumentation tests to PassBuilderCallbacks unit tests. Other unit tests updated with registration of the now-required PassInstrumentationAnalysis. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D47858 llvm-svn: 342544
* [GVNHoist] Re-enable GVNHoist by defaultAlexandros Lamprineas2018-09-175-22/+26
| | | | | | | | | | | | Rebase rL341954 since https://bugs.llvm.org/show_bug.cgi?id=38912 has been fixed by rL342055. Precommit testing performed: * Overnight runs of csmith comparing the output between programs compiled with gvn-hoist enabled/disabled. * Bootstrap builds of clang with UbSan/ASan configurations. llvm-svn: 342387
* test/Other/can-execute.txt: delete %t after the testFangrui Song2018-09-141-0/+1
| | | | | | This test constructs a non-readable file of mode 0111, which lingers in the test output directory and will cause EACCES to various tools (rg, rsync, ...) llvm-svn: 342279
* [PartiallyInlineLibCalls] Add DebugCounter supportGeorge Burgess IV2018-09-131-0/+44
| | | | | | | | | | | This adds DebugCounter support to the PartiallyInlineLibCalls pass, which should make debugging/automated bisection easier in the future. Patch by Zhizhou Yang! Differential Revision: https://reviews.llvm.org/D50093 llvm-svn: 342172
* [DCE] Add DebugCounter supportGeorge Burgess IV2018-09-131-0/+20
| | | | | | | | Patch by Zhizhou Yang! Differential Revision: https://reviews.llvm.org/D50092 llvm-svn: 342170
* Revert "[GVNHoist] Re-enable GVNHoist by default"Alexandros Lamprineas2018-09-115-26/+22
| | | | | | | | | | | | | | This reverts rL341954. The builder `sanitizer-x86_64-linux-bootstrap-ubsan` has been failing with timeouts at stage2 clang/ubsan: [3065/3073] Linking CXX executable bin/lld command timed out: 1200 seconds without output running python ../sanitizer_buildbot/sanitizers/buildbot_selector.py, attempting to kill llvm-svn: 342001
* [GVNHoist] Re-enable GVNHoist by defaultAlexandros Lamprineas2018-09-115-22/+26
| | | | | | | Rebase rL340922 since https://bugs.llvm.org/show_bug.cgi?id=38807 has been fixed by rL341947. llvm-svn: 341954
* Prevent Constant Folding From Optimizing inrange GEPPeter Collingbourne2018-09-111-0/+18
| | | | | | | | | | | | | | | This patch does the following things: 1. update SymbolicallyEvaluateGEP so that it bails out if it cannot preserve inrange arribute; 2. update llvm/test/Analysis/ConstantFolding/gep.ll to remove UB in it; 3. remove inaccurate comment above ConstantFoldInstOperandsImpl in llvm/lib/Analysis/ConstantFolding.cpp; 4. add a new regression test that makes sure that no optimizations change an inrange GEP in an unexpected way. Patch by Zhaomo Yang! Differential Revision: https://reviews.llvm.org/D51698 llvm-svn: 341888
* Add REQUIRES line to machine-size-remarksJessica Paquette2018-09-101-0/+1
| | | | | | | | Just was made aware that this is necessary for tests outside of the X86 subdirectory. Add a REQUIRES line to make sure bots that don't enable x86 are happy. llvm-svn: 341885
OpenPOWER on IntegriCloud