similar to: Renaming passes

On 6/24/20 11:21 AM, Matt Arsenault via llvm-dev wrote: > > >> On Jun 24, 2020, at 14:13, Arthur Eubanks via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi, >> >> As part of new pass manager work, I've been trying to get something >> like `opt -foo` working under the NPM, where `foo` is

> On Jun 24, 2020, at 19:17, Arthur Eubanks <aeubanks at google.com> wrote: > > > > On Wed, Jun 24, 2020 at 12:23 PM Philip Reames <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > > > On 6/24/20 11:21 AM, Matt Arsenault via llvm-dev wrote: >> >> >>> On Jun 24, 2020, at 14:13, Arthur Eubanks via

After talking with some NPM people, I believe the ultimate goal after NPM is enabled by default is to only support `-passes=`, and remove support for `-foo-pass`. However, until NPM is enabled by default, we still want tests using opt to use the legacy PM by default. We could attempt to make `-passes=` work with the legacy PM and have a legacy vs new PM flag, but given the design/syntax of

On Thu, Jun 25, 2020 at 9:59 AM Roman Lebedev <lebedev.ri at gmail.com> wrote: > On Thu, Jun 25, 2020 at 7:48 PM Arthur Eubanks via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > After talking with some NPM people, I believe the ultimate goal after > NPM is enabled by default is to only support `-passes=`, and remove support > for `-foo-pass`. > Hm,

On Wed, Jan 2, 2019 at 1:34 AM Markus Lavin <markus.lavin at ericsson.com> wrote: > To be more specific I am trying to use LVI from inside BasicAA to improve > some cases that turned out to be relevant for our downstream target. > > > > The code is in https://reviews.llvm.org/D55107 and I have problems with a > failing assert in the LazyValueInfoWrapperPass destructor

Hi, Looking at the output of e.g. llc -mtriple=x86_64-unknown-linux-gnu test/CodeGen/X86/pre-coalesce.ll -debug-pass=Executions Why is it that 'Basic Alias Analysis (stateless AA impl)' is freed much earlier than 'Function Alias Analysis Results' even though the latter depends on the former (at least AFAICT by looking at lib/Analysis/AliasAnalysis.cpp)? Thanks! -Markus

The management of passes in the legacy PM is ... highly confusing. Do you have a specific problem you're trying to solve or a specific question? On Thu, Dec 27, 2018 at 6:47 AM Markus Lavin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > > Looking at the output of e.g. > > > llc -mtriple=x86_64-unknown-linux-gnu test/CodeGen/X86/pre-coalesce.ll >

Hmm it looks like getting NPM to work with opt is non-trivial. Only a small portion of the opt functionality works with NPM :( On Mon, Jun 8, 2020 at 3:36 PM Robinson, Paul <paul.robinson at sony.com> wrote: > Maybe you could change the default PM in opt and see what fails? > > --paulr > > > > *From:* Arthur Eubanks <aeubanks at google.com> > *Sent:* Monday,

On Mon, Jun 8, 2020 at 7:11 AM Robinson, Paul <paul.robinson at sony.com> wrote: > When the optnone design was being discussed, Chandler specifically > rejected having the pass manager involved in the decision (which was the > original proposed design). Assuming he still feels the same way now, if > the existing `skipFunction` calls aren’t being executed under the new pass >

-Yuanfang > -----Original Message----- > From: Arthur Eubanks <aeubanks at google.com> > Sent: Monday, July 13, 2020 12:49 PM > To: Chen, Yuanfang <Yuanfang.Chen at sony.com> > Cc: LLVM Developers' List <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] [RFC] Introducing classes for the codegen driven by > new pass manager > > While we're

Hi all, I wanted to give a quick update on the status of NPM for the IR optimization pipeline and ask some questions. In the past I believe there were thoughts that NPM was basically ready because all of check-llvm and check-clang passed when -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=ON was specified. But that CMake flag did not apply to opt and any tests running something like `opt -foo-pass

(NPM: new pass manager; LPM: legacy pass manager) In a first quick experiment today I compared code-size of the LMP vs. the NMP for the CSiBE benchmark (and some other), and this shows code-size increases with the NPM that would probably be unacceptable for us. So, now I am wondering how/if we need to mitigate this, and have a bunch of questions. As I've noticed quite some activity around

FWIW I'm in favor of this direction while making sure that we keep focus on removing the vestiges of the old pass manager for the code health impact to the project. -eric On Wed, Jul 22, 2020 at 3:15 PM Philip Reames via llvm-dev < llvm-dev at lists.llvm.org> wrote: > (I'm probably going to derail your thread, sorry about that.) > > I think at this point, we should just

Hi all, The current plan is to prioritize enabling the NPM as soon as possible, and that includes addressing any blockers that are known or arise. This means prioritizing those blockers over other LLVM work. The current umbrella bug is PR46649 <https://bugs.llvm.org/show_bug.cgi?id=46649>. Philip's point is spot on that we are deficient now in the testing of the LegacyPassManager,

Looking through some of the remaining test failures under the new pass manager, I've narrowed down one of the failures in GWPAsan(!) to the fact that the new pass manager doesn't properly skip passes like the old pass manager. For example, when a function is marked optnone, or when using https://llvm.org/docs/OptBisect.html. Lots of passes (e.g. SROA) will do the following under the

Does LLVM have loop multiversioning ? it seems it does not with clang++ -O3 -mllvm -debug-pass=Arguments program.c -c bash-4.1$ clang++ -O3 -mllvm -debug-pass=Arguments fast_algorithms.c -c clang-3.6: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated Pass Arguments: -datalayout -notti -basictti -x86tti -targetlibinfo -no-aa -tbaa -scoped-noalias

(NPM: new pass manager; LPM: legacy pass manager) Hello, community While we're still working towards using NPM for optimizer pipeline by default, we still don't have a machine pass interface and the corresponding machine pass manager using NPM. The potential benefits using NPM aside, this inhibits us from making any progress on deprecating LPM for the codegen pipeline which blocks

On Fri, Jul 24, 2020 at 12:54 PM Sjoerd Meijer <Sjoerd.Meijer at arm.com> wrote: > Hi Alina, > > I think this is an excellent direction, this is the direction we should > take here. Just a somewhat irrelevant disagreement on this though: > > > Philip's point is spot on that we are deficient now in the testing of > the LegacyPassManager, > > I disagree

add -basicaa to your command line :) On Mon, May 11, 2015 at 7:15 AM, Willy WOLFF <willy.mh.wolff at gmail.com> wrote: > I play a bit more with MemoryDependenceAnalysis by wrapping my pass, and > call explicitely BasicAliasAnalysis. Its still using No Alias Analysis. > > How can I let MemoryDependenceAnalysis use BasicAliasAnalysis? > > Please, find attached my pass. >

I'm attempting to add some support for hoisting/sinking of memory-using intrinsics in loops, and so I want to use MemoryDependenceAnalysis in LICM, but when I modify getAnalysisUsge to include this : virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesCFG(); AU.addRequired<DominatorTree>(); AU.addRequired<LoopInfo>();