[llvm-dev] MCJit Runtine Performance
Paweł Bylica via llvm-dev
llvm-dev at lists.llvm.org
Mon Feb 8 01:37:43 PST 2016
Hi all,
Can someone also explain how to configure MCJIT to generate code for native
target (like clang's -march=native)?
Thanks,
Paweł
On Mon, Feb 8, 2016 at 2:01 AM Morten Brodersen via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi Lang,
>
>
> > can you share your EngineBuilder configuration lines?
>
> Sure.
>
> The 3.5.2 version use:
>
> llvm::ExecutionEngine* ee =
> llvm::EngineBuilder(module)
> .setEngineKind(llvm::EngineKind::JIT)
> .setOptLevel(llvm::CodeGenOpt::Aggressive)
> .create();
>
> module->setDataLayout(ee->getTargetMachine()->getDataLayout());
>
> And the 3.7.1 version use:
>
> llvm::EngineBuilder builder(move(modulePtr));
>
> builder.setEngineKind(llvm::EngineKind::JIT);
> builder.setErrorStr(&error);
> builder.setOptLevel(llvm::CodeGenOpt::Aggressive);
>
> llvm::ExecutionEngine* ee = builder.create();
>
> module->setDataLayout(*ee->getTargetMachine()->getDataLayout());
>
> Cheers
>
> Morten
>
>
> On 05/02/16 19:13, Lang Hames wrote:
>
> 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 lists.llvm.org> wrote:
>
> I agree with Lang and Keno here. This is both unexpected and very
> interesting. Given the differences in defaults between the two, 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) 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 again, I realize I may have made the
> wrong statement. The runtime regressions we see in julia are actually
> regressions in how long LLVM itself takes to do the compilation (but since
> it happens at run time in the JIT case, I think of it as a regression in
> our running time). We have only noticed occasional regressions in the
> performance of the generated code (which we are in the process of fixing).
> Which kind of regression 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
> > wrote:
>
>> 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 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
>
>
> _______________________________________________
> 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/20160208/1d71de45/attachment.html>
More information about the llvm-dev
mailing list