search for: brodersen

...t;llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > ----- Original Message ----- > > From: "Keno Fischer via llvm-dev" <llvm-dev at lists.llvm.org > <mailto:llvm-dev at lists.llvm.org>> > > To: "Morten Brodersen" <Morten.Brodersen at constrainttec.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 &g...

----- Original Message ----- > From: "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 th...

Can you build the code with llc? Try with the large code model. I think that is the default for MCJIT and can be less efficient. Cheers, Rafael On 4 February 2016 at 22:26, Morten Brodersen via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi Hal, > > We are using the default register allocator. I assume the greedy one is > default? > > As for other target machine optimizations: > > I have tried: > > llvm::TargetMachine* tm = ...; > > tm->...

...o, I would have expected the new JIT to have better performance but longer compile times. That you are seeing the opposite implies there is something very wrong and I'm very interested to help figure out what it is. > > Sent from my iPad > >> On Feb 4, 2016, at 9:12 PM, Morten Brodersen via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> 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) a...

...a good sign that the MC > and linking overhead aren't a big deal either, and if we can configure > the CodeGen pipeline properly we can get the performance back to the > same level as the legacy JIT. > > Cheers, > Lang. > > > On Thu, Feb 4, 2016 at 6:41 PM, Morten Brodersen via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > 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 >...

...ion are you > talking about, time taken by LLVM or time taken by the LLVM-generated > code? > > On Thu, Feb 4, 2016 at 11:44 PM, Rafael Espíndola > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > On 4 February 2016 at 22:48, Morten Brodersen via llvm-dev > <llvm-dev at lists.llvm.org <mailto: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? >...

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

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

...t in our case, profiling didn't reveal any remaining low > hanging fruits that are responsible. One thing you can potentially try > if you haven't yet is to enable fast ISel and see if that brings you > closer to the old runtimes. > > On Thu, Feb 4, 2016 at 7:00 PM, Morten Brodersen via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > 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...

...has a whole bunch of patches up for review. Chandler Carruth has responded with a [detail description of his concerns about the current design](http://lists.llvm.org/pipermail/llvm-dev/2016-February/094916.html), and his proposed alternative seems to be getting a lot of positive feedback. * Morten Brodersen has recently upgraded a number of applications from the old JIT to the new MCJIT under LLVM 3.7.1 but has [found significant performance regressions](http://lists.llvm.org/pipermail/llvm-dev/2016-February/094908.html). Some other respondents have seen similar issues, either in compilation time or i...