similar to: NPM and code-size

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,

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

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

(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

-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

I have a small program that I am broadcasting out on port 36 and attempting to receive information back. Using "tcpdump port 36" I can see 2 devices responding to me but I get no data. The response my program gets is: Size IP Address Subnet MAC Address ID 20 0.0.0.0 0.0.0.0 00-00-00-00-00-00 Does someone know what I might not be doing

I'd just note that not every pass you can run with "opt" is actually part of the optimization pipeline. There are a few important IR-level passes that only run in the codegen pipeline, but are still nameable with opt to run individually for testing purposes. Switching over doesn't need to block on these passes being migrated. So I'm not sure this method of determining

Hi, I have built successfully all the dependent packages of nodejs010 and npm. I have used following command:- *rpmbuild --define 'scl nodejs010' --bb SPEC/name_of_spec.spec* Following is the list of RPMs cloned and built from GIT:- nodejs010-2.1-5.el7.centos.x86_64.rpm nodejs010-http-parser-2.0-6.20121128gitcd01361.el7.centos.x86_64.rpm

Hi, I would like to give a quick update on what my current design and implementation go like. Basically, the `FunctionToLoopPassAdaptor` is now modified to a generic version `FunctionToLoopUnitPassAdaptor`, which allows re-using the existing codes to implement `FunctionToLoopNestPassAdaptor`, with the help of additional metadata associated with `Loop` and `LoopNest`. Both

Hi, I have built dependent packages of nodejs010 and npm successfully using mock and copy these RPMS to our ISO, anaconada installer fails to install due to dependency errors: nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.noarch requires nodejs010-npm(readable-stream) < 2 nodejs010-nodejs-cmd-shim-2.0.0-2.el7.centos.noarch requires nodejs010-npm(graceful-fs) < 4

Hello LLVM community, I was trying to port a target specific loop transformation pass (HexagonVectorLoopCarriedReusePass) to the New Pass Manager. However, I could not figure out a way to register this pass with opt. I can see that llvm/lib/Passes/PassRegistry.def is the registry for target independent passes. Can anyone point me to an example/API which can help me in registering this pass so

Hi, Thanks for your help! I've checked the sources that you mentioned. Currently, I think that I would need to implement a FunctionToLoopNestPassAdaptor which is essentially the same as the FunctionToLoopPassAdaptor but operates only on LI.getTopLevelLoops(). We might also need a LNPMUpdater (LoopNestPassManagerUpdater) which disallows adding inner-loops back into the pipeline, and

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

Hi Florian, Following up on D86967, I missed that all the timings were using the legacy pass manager. Did you do any testing on the compile and run time impact for the new pass manager? Thank you, Alina On Tue, Aug 25, 2020 at 12:51 PM Florian Hahn <florian_hahn at apple.com> wrote: > Hi, > > Thanks for all the responses! > > My understanding is that there were no

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,

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 the name of a pass. In the past there's been no reason to keep the names of passes consistent between NPM and legacy PM. But now there is a reason to make them match, so that we don't have to touch every single test that uses `opt`. There are a couple of

FWIW, the flags like -print-after, -printer-after-all don't work well with the new pass manager last time I checked. On Mon, Jul 8, 2019 at 12:20 PM Stephen Hines via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The Android platform build (AOSP) has also switched to the new pass manager recently. We do have a few bugs that we are chasing (hence opt-outs), but it is working

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,

I had a chance to try -print-after-all with NPM. It seems like there's still no output for the passes before objc-arc-contract (which is basically what I saw before.) Does anyone else see this? Are we talking about the same thing? *** IR Dump After ObjC ARC contraction *** *** IR Dump After Pre-ISel Intrinsic Lowering *** *** IR Dump After Expand Atomic instructions *** *** IR Dump After