----- 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 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 slowdown is this > noticable, but at least 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.And maybe the register allocator? Are you using the greedy one or the linear one? Are there any other MI-level optimizations running? -Hal> > > On Thu, Feb 4, 2016 at 7:00 PM, Morten Brodersen via llvm-dev < > 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 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 optimize airline rosters and > pairings. LLVM is used for compiling high level business rules to > efficient machine code. > > A typical optimization run takes 6 to 8 hours. So a 30% to 40% > reduction in speed has real impact (=> we can't upgrade from 3.5.2). > > We have triple checked and reviewed the changes we made from old JIT > to MCJIt. We also tried different ways to optimize the IR. > > However all results indicate that the performance drop happens in the > (black box) IR to machine code stage. > > So my question is if the runtime performance reduction is > known/expected for MCJit vs. old JIT? Or if we might be doing > something wrong? > > If you need more information, in order to understand the issue, > please tell us so that we can provide you with more details. > > Thanks > Morten > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
These are some pretty extreme slowdowns. The legacy JIT shared the code generator with MCJIT, and as far as I'm aware there were really only three main differences: 1) The legacy JIT used a custom instruction encoder, whereas MCJIT uses MC. 2) (Related to 1) MCJIT needs to perform runtime linking of the object files produced by MC. 3) MCJIT does not compile lazily (though it sounds like that's not an issue here?) Keno - did you ever look at the codegen pipeline construction for the legacy JIT vs MCJIT? Are we choosing different passes? Morten - Can you share any test cases that demonstrate the slowdown. I'd love to take a look at this. Cheers, Lang. On Thu, Feb 4, 2016 at 4:16 PM, Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote:> ----- 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 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 slowdown is this > > noticable, but at least 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. > > And maybe the register allocator? Are you using the greedy one or the > linear one? Are there any other MI-level optimizations running? > > -Hal > > > > > > > On Thu, Feb 4, 2016 at 7:00 PM, Morten Brodersen via llvm-dev < > > 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 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 optimize airline rosters and > > pairings. LLVM is used for compiling high level business rules to > > efficient machine code. > > > > A typical optimization run takes 6 to 8 hours. So a 30% to 40% > > reduction in speed has real impact (=> we can't upgrade from 3.5.2). > > > > We have triple checked and reviewed the changes we made from old JIT > > to MCJIt. We also tried different ways to optimize the IR. > > > > However all results indicate that the performance drop happens in the > > (black box) IR to machine code stage. > > > > So my question is if the runtime performance reduction is > > known/expected for MCJit vs. old JIT? Or if we might be doing > > something wrong? > > > > If you need more information, in order to understand the issue, > > please tell us so that we can provide you with more details. > > > > Thanks > > Morten > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160204/401e845c/attachment.html>
We are using the same IR passes. We did not look at the the backend passes other than fast isel, because I didn't realize we had a choice there, do we? In our profiling, nothing in MCJIT specifically (relocations, etc.) are taking any significant amount of time. As far as we could tell most of the slow down was in ISel, with a couple additional percent in various IR passes. On Thu, Feb 4, 2016 at 7:52 PM, Lang Hames <lhames at gmail.com> wrote:> These are some pretty extreme slowdowns. The legacy JIT shared the code > generator with MCJIT, and as far as I'm aware there were really only three > main differences: > > 1) The legacy JIT used a custom instruction encoder, whereas MCJIT uses MC. > 2) (Related to 1) MCJIT needs to perform runtime linking of the object > files produced by MC. > 3) MCJIT does not compile lazily (though it sounds like that's not an > issue here?) > > Keno - did you ever look at the codegen pipeline construction for the > legacy JIT vs MCJIT? Are we choosing different passes? > > Morten - Can you share any test cases that demonstrate the slowdown. I'd > love to take a look at this. > > Cheers, > Lang. > > On Thu, Feb 4, 2016 at 4:16 PM, Hal Finkel via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> ----- 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 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 slowdown is this >> > noticable, but at least 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. >> >> And maybe the register allocator? Are you using the greedy one or the >> linear one? Are there any other MI-level optimizations running? >> >> -Hal >> >> > >> > >> > On Thu, Feb 4, 2016 at 7:00 PM, Morten Brodersen via llvm-dev < >> > 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 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 optimize airline rosters and >> > pairings. LLVM is used for compiling high level business rules to >> > efficient machine code. >> > >> > A typical optimization run takes 6 to 8 hours. So a 30% to 40% >> > reduction in speed has real impact (=> we can't upgrade from 3.5.2). >> > >> > We have triple checked and reviewed the changes we made from old JIT >> > to MCJIt. We also tried different ways to optimize the IR. >> > >> > However all results indicate that the performance drop happens in the >> > (black box) IR to machine code stage. >> > >> > So my question is if the runtime performance reduction is >> > known/expected for MCJit vs. old JIT? Or if we might be doing >> > something wrong? >> > >> > If you need more information, in order to understand the issue, >> > please tell us so that we can provide you with more details. >> > >> > Thanks >> > Morten >> > >> > _______________________________________________ >> > LLVM Developers mailing list >> > llvm-dev at lists.llvm.org >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > >> > >> > _______________________________________________ >> > LLVM Developers mailing list >> > llvm-dev at lists.llvm.org >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > >> >> -- >> Hal Finkel >> Assistant Computational Scientist >> Leadership Computing Facility >> Argonne National Laboratory >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160204/67b0ee97/attachment.html>
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->setOptLevel(llvm::CodeGenOpt::Aggressive); And it doesn't make much of a difference. And also: tm->setFastISel(true); (previous email). Is there anything else I can try? On 05/02/16 11:16, Hal Finkel wrote:> ----- 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 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 slowdown is this >> noticable, but at least 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. > And maybe the register allocator? Are you using the greedy one or the linear one? Are there any other MI-level optimizations running? > > -Hal > >> >> On Thu, Feb 4, 2016 at 7:00 PM, Morten Brodersen via llvm-dev < >> 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 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 optimize airline rosters and >> pairings. LLVM is used for compiling high level business rules to >> efficient machine code. >> >> A typical optimization run takes 6 to 8 hours. So a 30% to 40% >> reduction in speed has real impact (=> we can't upgrade from 3.5.2). >> >> We have triple checked and reviewed the changes we made from old JIT >> to MCJIt. We also tried different ways to optimize the IR. >> >> However all results indicate that the performance drop happens in the >> (black box) IR to machine code stage. >> >> So my question is if the runtime performance reduction is >> known/expected for MCJit vs. old JIT? Or if we might be doing >> something wrong? >> >> If you need more information, in order to understand the issue, >> please tell us so that we can provide you with more details. >> >> Thanks >> Morten >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>
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->setOptLevel(llvm::CodeGenOpt::Aggressive); > > And it doesn't make much of a difference. > > And also: > > tm->setFastISel(true); > > (previous email). > > Is there anything else I can try? > > > On 05/02/16 11:16, Hal Finkel wrote: >> >> ----- 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 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 slowdown is this >>> noticable, but at least 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. >> >> And maybe the register allocator? Are you using the greedy one or the >> linear one? Are there any other MI-level optimizations running? >> >> -Hal >> >>> >>> On Thu, Feb 4, 2016 at 7:00 PM, Morten Brodersen via llvm-dev < >>> 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 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 optimize airline rosters and >>> pairings. LLVM is used for compiling high level business rules to >>> efficient machine code. >>> >>> A typical optimization run takes 6 to 8 hours. So a 30% to 40% >>> reduction in speed has real impact (=> we can't upgrade from 3.5.2). >>> >>> We have triple checked and reviewed the changes we made from old JIT >>> to MCJIt. We also tried different ways to optimize the IR. >>> >>> However all results indicate that the performance drop happens in the >>> (black box) IR to machine code stage. >>> >>> So my question is if the runtime performance reduction is >>> known/expected for MCJit vs. old JIT? Or if we might be doing >>> something wrong? >>> >>> If you need more information, in order to understand the issue, >>> please tell us so that we can provide you with more details. >>> >>> Thanks >>> Morten >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
----- Original Message -----> From: "Morten Brodersen via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, February 4, 2016 9:26:51 PM > Subject: Re: [llvm-dev] MCJit Runtine Performance > > 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->setOptLevel(llvm::CodeGenOpt::Aggressive); > > And it doesn't make much of a difference. > > And also: > > tm->setFastISel(true); > > (previous email). > > Is there anything else I can try?>From your previous e-mail, it seems like this is a case of too little optimization, not too much, right?Are you creating a TargetTransformInfo object for your target? CodeGenPasses->add( createTargetTransformInfoWrapperPass(TM->getTargetIRAnalysis()) I assume you're dominated by integer computation, not floating-point, is that correct? -Hal> > On 05/02/16 11:16, Hal Finkel wrote: > > ----- 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 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 slowdown is this > >> noticable, but at least 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. > > And maybe the register allocator? Are you using the greedy one or > > the linear one? Are there any other MI-level optimizations > > running? > > > > -Hal > > > >> > >> On Thu, Feb 4, 2016 at 7:00 PM, Morten Brodersen via llvm-dev < > >> 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 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 optimize airline rosters and > >> pairings. LLVM is used for compiling high level business rules to > >> efficient machine code. > >> > >> A typical optimization run takes 6 to 8 hours. So a 30% to 40% > >> reduction in speed has real impact (=> we can't upgrade from > >> 3.5.2). > >> > >> We have triple checked and reviewed the changes we made from old > >> JIT > >> to MCJIt. We also tried different ways to optimize the IR. > >> > >> However all results indicate that the performance drop happens in > >> the > >> (black box) IR to machine code stage. > >> > >> So my question is if the runtime performance reduction is > >> known/expected for MCJit vs. old JIT? Or if we might be doing > >> something wrong? > >> > >> If you need more information, in order to understand the issue, > >> please tell us so that we can provide you with more details. > >> > >> Thanks > >> Morten > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
Hi Lang, > MCJIT does not compile lazily (though it sounds like that's not an issue here?) That is not an issue here since the code JIT's once (a few secs) and then run the generated machine code for hours. > Morten - Can you share any test cases that demonstrate the slowdown. I'd love to take a look at this. The code is massive so not practical. However I will try and extract an example function that demonstrates the difference (as per previous email). On 05/02/16 11:52, Lang Hames wrote:> These are some pretty extreme slowdowns. The legacy JIT shared the > code generator with MCJIT, and as far as I'm aware there were really > only three main differences: > > 1) The legacy JIT used a custom instruction encoder, whereas MCJIT > uses MC. > 2) (Related to 1) MCJIT needs to perform runtime linking of the object > files produced by MC. > 3) MCJIT does not compile lazily (though it sounds like that's not an > issue here?) > > Keno - did you ever look at the codegen pipeline construction for the > legacy JIT vs MCJIT? Are we choosing different passes? > > Morten - Can you share any test cases that demonstrate the slowdown. > I'd love to take a look at this. > > Cheers, > Lang. > > On Thu, Feb 4, 2016 at 4:16 PM, Hal Finkel via llvm-dev > <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 > > 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 slowdown is this > > noticable, but at least 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. > > And maybe the register allocator? Are you using the greedy one or > the linear one? Are there any other MI-level optimizations running? > > -Hal > > > > > > > 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 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 optimize airline rosters and > > pairings. LLVM is used for compiling high level business rules to > > efficient machine code. > > > > A typical optimization run takes 6 to 8 hours. So a 30% to 40% > > reduction in speed has real impact (=> we can't upgrade from 3.5.2). > > > > We have triple checked and reviewed the changes we made from old JIT > > to MCJIt. We also tried different ways to optimize the IR. > > > > However all results indicate that the performance drop happens > in the > > (black box) IR to machine code stage. > > > > So my question is if the runtime performance reduction is > > known/expected for MCJit vs. old JIT? Or if we might be doing > > something wrong? > > > > If you need more information, in order to understand the issue, > > please tell us so that we can provide you with more details. > > > > Thanks > > Morten > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160205/a37dc981/attachment.html>