search for: runtin

On 4 February 2016 at 22:48, Morten Brodersen via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi Rafael, > > Not easily (llc). > > Is there a way to make MCJit not use the large code model when JIT'ing? > I think Davide started adding support for the small code model. Cheers, Rafael

...<llvm-dev at lists.llvm.org> >>> To: "Morten Brodersen" <Morten.Brodersen at constrainttec.com> >>> Cc: "llvm-dev" <llvm-dev at lists.llvm.org> >>> Sent: Thursday, February 4, 2016 6:05:29 PM >>> Subject: Re: [llvm-dev] MCJit Runtine Performance >>> >>> >>> >>> Yes, unfortunately, this is very much known. Over in the julia >>> project, we've recently gone through this and taken the hit (after >>> doing some work to fix the very extreme corner cases that we were >>...

Hi All, We recently upgraded a number of applications from LLVM 3.5.2 (old JIT) to LLVM 3.7.1 (MCJit). We made the minimum changes needed for the switch (no changes to the IR generated or the IR optimizations applied). The resulting code pass all tests (8000+). However the runtime performance dropped significantly: 30% to 40% for all applications. The applications I am talking about

...Keno Fischer via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Morten Brodersen" <Morten.Brodersen at constrainttec.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, February 4, 2016 6:05:29 PM > Subject: Re: [llvm-dev] MCJit Runtine Performance > > > > Yes, unfortunately, this is very much known. Over in the julia > project, we've recently gone through this and taken the hit (after > doing some work to fix the very extreme corner cases that we were > hitting). We're not entirely sure why the sl...

...ec.com > <mailto:Morten.Brodersen at constrainttec.com>> > > Cc: "llvm-dev" <llvm-dev at lists.llvm.org > <mailto:llvm-dev at lists.llvm.org>> > > Sent: Thursday, February 4, 2016 6:05:29 PM > > Subject: Re: [llvm-dev] MCJit Runtine Performance > > > > > > > > Yes, unfortunately, this is very much known. Over in the julia > > project, we've recently gone through this and taken the hit (after > > doing some work to fix the very extreme corner cases that we were &g...

Hi Keno, I am talking about runtime. The performance of the generated machine code. Not the time it takes to lower the IR to machine code. We typically only JIT once (taking a few secs) and then run the generated machine code for hours. So the JIT time (IR -> machine code) doesn't impact us. Cheers Morten On 05/02/16 15:58, Keno Fischer wrote: > Actually, reading over all of this

Hi Lang, > That suggests an optimization quality issue, rather than compile-time overhead Yes that makes sense. The long running applications (6+ hours) JIT the rules once (taking a few seconds) and then run the generated machine code for hours. With no additional JIT'ing. > if we can configure the CodeGen pipeline properly we can get the performance back to the same level as

Hi Keno, Thanks for the fast ISel suggestion. Here are the results (for a small but representational run): LLVM 3.5.2 (old JIT): 4m44s LLVM 3.7.1 (MCJit) no fast ISel: 7m31s LLVM 3.7.1 (MCJit) fast ISel: 7m39s So not much of a difference unfortunately. On 05/02/16 11:05, Keno Fischer wrote: > Yes, unfortunately, this is very much known. Over in the julia > project, we've recently

Hi Morten, Something else just occurred to me: can you share your EngineBuilder configuration lines? (http://llvm.org/docs/doxygen/html/classllvm_1_1EngineBuilder.html) In particular - are you explicitly setting the optimization level? The old JIT may have had a different default. - Lang. Sent from my iPad > On Feb 4, 2016, at 10:54 PM, Jim Grosbach via llvm-dev <llvm-dev at

...>> simplifications that don't exploit no-overflow, inbounds or exact > > Why? Can you provide an example using nsw, inbounds, etc.? I think the same case as the general UB applies: void foo(int n) available_externally { if (n s< (n +nsw 1)) abort(); } void bar() { if (< runtine cond always false>) foo(INT_SMAX); } Now foo() can be simplified to "ret void" using the nsw, and the call to foo(INT_SMAX) can be hoisted. This is a problem if we link to an unrefined @foo. -- Sanjoy

----- Original Message ----- > From: "Sanjoy Das" <sanjoy at playingwithpointers.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chandler Carruth" <chandlerc at google.com>, "llvm-dev" <llvm-dev at lists.llvm.org>, "Philip Reames" > <listmail at philipreames.com>, "Duncan P. N. Exon Smith"

On Wed, Feb 24, 2016 at 11:18 PM, Hal Finkel <hfinkel at anl.gov> wrote: > It might be much more challenging, but let's try. This is not an > issue we need to fix by the end of the month, and the potential > optimization regressions are significant. Our deductions of > readonly/readnone/nocapture/etc. are really important for enabling > other optimizations. Given that all