search for: aeubanks

...mations you run the more UB you can also "loose" as it is defined to something by the transformation. Lifetime markers are an example. Once removed, which is generally legal in IR, you cannot argue accesses after the end are UB. > On Wed, May 13, 2020 at 1:04 PM Arthur Eubanks <aeubanks at google.com> wrote: > >> Just tested it out, that test does indeed fail under the old PM at -O3 and >> even at -O2. >> >> If the ASan pass runs after optimizations and is designed to detect >> undefined behavior at runtime, I don't see how it can be super r...

...ot;loose" as it is defined to something by the > transformation. > > Lifetime markers are an example. Once removed, which is generally > legal in IR, you cannot argue accesses after the end are UB. > > >> On Wed, May 13, 2020 at 1:04 PM Arthur Eubanks<aeubanks at google.com> <mailto:aeubanks at google.com> wrote: >> >>> Just tested it out, that test does indeed fail under the old PM at -O3 and >>> even at -O2. >>> >>> If the ASan pass runs after optimizations and is designed to detect >&...

...cleanup the stack. On Thu, Apr 16, 2020 at 1:40 PM Eli Friedman <efriedma at quicinc.com> wrote: > > > *From:* Reid Kleckner <rnk at google.com> > *Sent:* Thursday, April 16, 2020 1:06 PM > *To:* Eli Friedman <efriedma at quicinc.com> > *Cc:* Arthur Eubanks <aeubanks at google.com>; llvm-dev < > llvm-dev at lists.llvm.org> > *Subject:* [EXT] Re: [llvm-dev] [RFC] Replacing inalloca with > llvm.call.setup and preallocated > > > > On Sat, Mar 28, 2020 at 2:20 PM Eli Friedman <efriedma at quicinc.com> wrote: > > This would...

...on-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, June 8, 2020 5:52 PM > *To:* Robinson, Paul <paul.robinson at sony.com> > *Cc:* Chandler Carruth <chandlerc at gmail.com>; llvm-dev at lists.llvm.org > *Subject:* Re: [llvm-dev] optnone/skipping passes in the new pass manager > > &gt...

Should ConstantProp.cpp also be removed? It doesn't look like it's been worked on in over 10 years, and aside from check-llvm lit tests, the only use is in llvm/unittests/ExecutionEngine/MCJIT/MCJITAPITest.cpp via LLVMAddConstantPropagationPass. (it hasn't been ported to the new pass manager which is why I'm asking) On Mon, Jul 27, 2020 at 6:01 PM Chris Lattner via llvm-dev <

> 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,...

...defined to something by the transformation. >>> >>> Lifetime markers are an example. Once removed, which is generally legal >>> in IR, you cannot argue accesses after the end are UB. >>> >>> >>> On Wed, May 13, 2020 at 1:04 PM Arthur Eubanks <aeubanks at google.com> <aeubanks at google.com> wrote: >>> >>> >>> Just tested it out, that test does indeed fail under the old PM at -O3 and >>> even at -O2. >>> >>> If the ASan pass runs after optimizations and is designed to detect >>&...

Just tested it out, that test does indeed fail under the old PM at -O3 and even at -O2. If the ASan pass runs after optimizations and is designed to detect undefined behavior at runtime, I don't see how it can be super reliable at higher optimization levels. On Wed, May 13, 2020 at 12:39 PM David Blaikie <dblaikie at gmail.com> wrote: > +some sanitizer/new pass manager folks >

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,

-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 > &g...

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 >

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, Is there a mechanism in place to use the new pass manager with target-specific passes added (at the moment) via addIRPasses in TargetPassConfig? I did see any code related to that, did I miss something? Is it in plan? -- Krzysztof Parzyszek kparzysz at quicinc.com AI tools development

On Sat, Mar 28, 2020 at 2:20 PM Eli Friedman <efriedma at quicinc.com> wrote: > This would specifically be for cases where we try to rewrite the > signature? I would assume we should forbid rewriting the signature of a > call with an operand bundle. And once some optimization drops the bundle > and preallocated marking, to allow such rewriting, the signature doesn’t > need

(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

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

...work is required for the optimizer pipeline NPM switch. > > On Mon, Jul 13, 2020 at 6:23 PM Chen, Yuanfang <Yuanfang.Chen at sony.com> > wrote: > >> >> >> >> -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 >...

Sorry for the delay. Arthur Eubanks has started working on the design here: https://reviews.llvm.org/D74651 I felt I should follow up here about that. On Mon, Jan 27, 2020 at 6:47 PM Eli Friedman <efriedma at quicinc.com> wrote: > It doesn’t seem like multiple call sites should be a problem if they’re > sufficiently similar? If the argument layout for each callsite is the > same,

(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