similar to: Module::createRNG() and new PassManager

Overall seems fine to me. On 3/11/19 8:12 PM, Hiroshi Yamauchi wrote: > Here's a revised approach based on the discussion: > > - Cache PSI right after the profile summary in the IR is written in > the pass pipeline. This would avoid the need to insert > RequireAnalysisPass for PSI before each non-module pass that needs it. > PSI can be technically invalidated but unlikely

I searched source code of LLVM/Clang 4.0.0 for 'random_seed' with grep. It seems the -frandom-seed option is not supported. The -rng-seed option appears to be defined in ./lib/Support/RandomNumberGenerator.cpp, which is source code for class RandomNumberGenerator. The constructor of class RandomNumberGenerator is private and is only called by Module::createRNG (defined in

On 3/14/19 2:04 AM, Hiroshi Yamauchi wrote: > > > On Wed, Mar 13, 2019 at 2:37 PM Fedor Sergeev <fedor.sergeev at azul.com > <mailto:fedor.sergeev at azul.com>> wrote: > >> >> - Add a new proxy ModuleAnalysisManagerLoopProxy for a loop pass >> to be able to get to the ModuleAnalysisManager in one step and >> PSI through it. >

Hi Chandler, I am now working on a bisecting tool to find mis-optimization on LLVM. I found OptBisect a very useful option and hope to make it work on the new pass manager. I have several questions about it. 1. Any plans to apply codegen stage with new pass manager? IIUC, new pass manager only works for opt stage. However the OptBisect option tries to accumulate pass counts through opt stage

On 3/4/19 10:49 PM, Hiroshi Yamauchi wrote: > > > On Mon, Mar 4, 2019 at 10:55 AM Hiroshi Yamauchi <yamauchi at google.com > <mailto:yamauchi at google.com>> wrote: > > > > On Sat, Mar 2, 2019 at 12:58 AM Fedor Sergeev > <fedor.sergeev at azul.com <mailto:fedor.sergeev at azul.com>> wrote: > > > > On 3/2/19 2:38 AM,

On Sat, Mar 2, 2019 at 12:58 AM Fedor Sergeev <fedor.sergeev at azul.com> wrote: > > > On 3/2/19 2:38 AM, Hiroshi Yamauchi wrote: > > Here's a sketch of the proposed approach for just one pass (but imagine > more) > > https://reviews.llvm.org/D58845 > > On Fri, Mar 1, 2019 at 12:54 PM Fedor Sergeev via llvm-dev < > llvm-dev at lists.llvm.org>

Here's a sketch of the proposed approach for just one pass (but imagine more) https://reviews.llvm.org/D58845 On Fri, Mar 1, 2019 at 12:54 PM Fedor Sergeev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 2/28/19 12:47 AM, Hiroshi Yamauchi via llvm-dev wrote: > > Hi all, > > To implement more profile-guided optimizations, we’d like to use > ProfileSummaryInfo

Hi all, To implement more profile-guided optimizations, we’d like to use ProfileSummaryInfo (PSI) and BlockFrequencyInfo (BFI) from more passes of various types, under the new pass manager. The following is what we came up with. Would appreciate feedback. Thanks. Issue It’s not obvious (to me) how to best do this, given that we cannot request an outer-scope analysis result from an inner-scope

Hi all, I'm trying to build passes with the PassBuilder to optimize the result of MCJIT (I assume, this is a requirement for performance). So I do this: llvm::PassBuilder passBuilder; llvm::ModulePassManager modulePassManager = passBuilder.buildPerModuleDefaultPipeline(llvm::PassBuilder::OptimizationLevel::O3); llvm::ModuleAnalysisManager moduleAnalysisManager;

On 06/07/2018 06:11 PM, Chandler Carruth wrote: > We had already talked about this, so unsurprisingly I'm generally in > favor of the direction. Some comments below. > > On Thu, Jun 7, 2018 at 2:00 AM Fedor Sergeev <fedor.sergeev at azul.com > <mailto:fedor.sergeev at azul.com>> wrote: > >    - access through LLVM Context (allows to control life-time and

Is there a reason for why `-asan` and `-asan-module` can be mixed but Function passes and Module passes with the new PM can't be mixed? - Leo On Thu, Sep 27, 2018 at 3:21 AM Fedor Sergeev <fedor.sergeev at azul.com> wrote: > > On 09/27/2018 12:25 PM, Philip Pfaffe wrote: >> >> `opt < %s -passed='asan' -asan-module -S` > > asan-module is another

On Wed, Nov 28, 2018 at 6:25 PM Chris Lattner via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Generally no IMO, because the cases that produce optional are not obvious. > Just to say, +1 from me too. > > > * Can we use auto in c++14 lambda arguments with llvm::find_if(C, > [](const auto& i) { ... }) for example? > > * We need to use auto for structured

Hi, I notice that there are several different methods called inside getAnalysisUsage(). The parameters of addRequiredID and addPreservedID are passID. What is the difference between Required and Preserved? There are also function named addRequired<PassName>() called. What is the difference between addRequired<PassName>() and addRequiredID(PassID)? Thanks a lot! Best,

Hi Leonard, Fedor, while it's true that RegisterPass is not applicable for new-pm passes, PassRegistry.def is not the whole story. Passes in PassRegistry are available for the opt tool. The sanitizers are passes that usually get added to the pipeline by the frontend. There, you need to use PassBuilder's callbacks mechanism to hook the sanitizer into the optimizer. Assuming you're

Hi all, I'm attempting to move the AddressSanitizer pass from the legacy PassManager to the new one because the new one has various benefits over legacy and wanted to clarify on something. Does creating the static RegisterPass struct register the pass with the new PassManager? It seems that RegisterPass does the same things that the INITIALIZE_PASS_* macros do but it registers the pass with

Frontends _are_ using PassBuilder, but they need to hook into the default pipeline creation to insert the sanitizer passes. On Tue, Sep 25, 2018 at 12:15 PM Fedor Sergeev <fedor.sergeev at azul.com> wrote: > Hmm... frontends should be using PassBuilder anyway. > And if they are using PassBuilder then they are using PassRegistry.def as > well - all the >

Hi, I am trying to implement Available Expressions data flow analysis. I created the following class (I am giving here code snippet.): namespace { typedef DenseMap<Expression, uint32_t> DMTy; //Expression is a class I defined. struct DataFlowValue { DMTy ExprMap; llvm::BitVector* DFV; // Functions operating on the data // bool operator==(const DataFlowValue V) const;

I'm not advocating AAA. However this is a proposal for more modern thinking regarding the permissiveness of auto in LLVM codebases. Currently the rule on the use of auto is here: https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable It is quite strict. It allows the use of auto for * lambdas * iterators because they are long to type * casts to

> > `opt < %s -passed='asan' -asan-module -S` > asan-module is another ModulePass, not a commandline option. You can't mix that like this. Cheers, Philip > doesn't produce the same IR as > > `opt < %s -asan -asan-module -S` > > More specifically, the only thing missing seems to be the > `asan.module_ctor` that should get added to the global

I have seen INITIALIZE_PASS(LiveVariables, "livevars", "Live Variable Analysis", false, false); in the llvm/lib/codegen/LiveVariables.cpp, where LiveVariables is a subclass of MachineFunctionPass, and #define INITIALIZE_PASS(passName, arg, name, cfg, analysis) \ static RegisterPass<passName> passName ## _info(arg, name, cfg, analysis) in PassSupport.h Is this code used