similar to: [LLVMdev] Null pointer dereference

Hi Yury, No need for the "{" "}" since it's a single statement in the compound statement. Other than that minor style detail, this looks fine assuming it applies cleanly to trunk. Do you have commit access? Regards, -Jim On May 9, 2012, at 3:40 PM, Yury Mikhaylov wrote: > Hi all, > > Writing my own LLVM client I've noticed a potential null pointer

Thank you for your response Jim. As of revision 153342 it applies properly to trunk. No, unfortunately I don't have access, would you please commit it for me? Thanks, Yury On Wed, May 9, 2012 at 4:37 PM, Jim Grosbach <grosbach at apple.com> wrote: > Hi Yury, > > No need for the "{" "}" since it's a single statement in the compound > statement.

Hi edaqa, You might need to set your TargetOptions before calling selectTarget. E.g. builder.setTargetOptions(Opts).selectTarget(...); Or you could just let EngineBuilder call selectTarget for you (which is what the no-argument version of EngineBuilder::create does): llvm::ExecutionEngine * ee = builder. setErrorStr( &errStr ). setEngineKind( llvm::EngineKind::JIT ).

On Wed, Nov 2, 2016 at 9:41 AM, Jonas Wagner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello, > > I think this should be added by Clang itself. > > > I don't think so. There are several sources online that indicate that > developers need to *manually* specify std::nothrow. If they don't, > operator new will throw an exception even if code is

Hi, I am using LLVM 3.1, and wants to print the machine code of JIT IR I try the following method EngineBuilder builder(&ctx.getModule()); builder.setEngineKind(EngineKind::JIT); * TargetMachine * tm = builder.selectTarget(); tm->Options.PrintMachineCode = true;* engine = builder.create(); and somewhere in my code, I use runJITonFunction(); Another question is that I am

I don't know if I'm setting the triple of my execution engine correctly.  This is leading to an issue where a struct `{i8,i64}` is not getting the same layout as the ABI expects. I setup my engine/module like this:      llvm::SmallVector<std::string,2> mattrs;      llvm::EngineBuilder builder{ unique_ptr<llvm::Module>(module) };      llvm::ExecutionEngine * ee = builder.    

Taking one step back, I'm not clear I'm even setting the triple/DataLayout on the module correctly:     module = new llvm::Module( "test", *llvm_context );     module->setTargetTriple( platform::target->triple ); Is that enough to create an appropriate DataLayout for the module?  I don't see anyway to convert a triple to a DataLayout, so I can't call

Hi, Our DSL LLVM IR emitted code (optimized with -O3 kind of IR ==> IR passes) runs slower when executed with the LLVM 3.3 JIT, compared to what we had with LLVM 3.1. What could be the reason? I tried to play with TargetOptions without any success… Here is the kind of code we use to allocate the JIT: EngineBuilder builder(fResult->fModule);

I'm trying to add static code generation capabilities to my MCJIT compiler on LLVM 3.4. To that extent I have: targetMachine = engineBuilder.selectTarget(); // ... targetMachine->addPassesToEmitFile(<...>); At first glance this appears to work, but when linking the object file I get the warning: ld: warning: PIE disabled. Absolute addressing (perhaps

Andy, Yes, it was wrong, as long as RemoteTarget is available for the target. If you would revert it, please consider then; - non-MCJIT stuff - Running different environment on the JIT e.g.) --build=--host=i686-linux --target=x86_64-linux - Host-incapable target on the JIT e.g.) --build=--host=x86_64-linux ---target=i686-mingw32 If JIT is unavailable for the default target, tests

On Thu, Jul 18, 2013 at 9:07 AM, Stéphane Letz <letz at grame.fr> wrote: > Hi, > > Our DSL LLVM IR emitted code (optimized with -O3 kind of IR ==> IR passes) runs slower when executed with the LLVM 3.3 JIT, compared to what we had with LLVM 3.1. What could be the reason? > > I tried to play with TargetOptions without any success… > > Here is the kind of code we use to

I get a segfault with this code when setting the data layout: int main(int argc, char** argv) { llvm::InitializeNativeTarget(); llvm::LLVMContext TheContext; unique_ptr<Module> Mod(new Module("A",TheContext)); llvm::EngineBuilder engineBuilder(std::move(Mod)); std::string mcjit_error; engineBuilder.setMCPU(llvm::sys::getHostCPUName());

hi all, I'm trying to write an LLVM-based interpreter for a small DSL that we have. The language is very simple (essentially a calculator), but I'd like it to execute efficiently. I've been following the tutorial, and have the following code for instantiating an ExecutionEngine: #include <LLVM\ExecutionEngine\JIT.h> #include

Le 18 juil. 2013 à 19:07, Eli Friedman <eli.friedman at gmail.com> a écrit : > On Thu, Jul 18, 2013 at 9:07 AM, Stéphane Letz <letz at grame.fr> wrote: >> Hi, >> >> Our DSL LLVM IR emitted code (optimized with -O3 kind of IR ==> IR passes) runs slower when executed with the LLVM 3.3 JIT, compared to what we had with LLVM 3.1. What could be the reason? >>

Hi Chia Lun Liu, On 12/21/12 7:47 AM, ChiaLun wrote: > I am using LLVM 3.1, and wants to print the machine code of JIT IR > > I try the following method > > EngineBuilder builder(&ctx.getModule()); > builder.setEngineKind(EngineKind::JIT); > * > TargetMachine * tm = builder.selectTarget(); > tm->Options.PrintMachineCode = true;* > engine =

Ok. I can make a copy of the unique_ptr before moving it into the builder's constructor and use the copy later on. It is confusing to require a unique_ptr. Frank On 09/14/2016 12:11 PM, Frank Winter via llvm-dev wrote: > I am constructing the engine builder in the following way: > > llvm::SMDiagnostic Err; > unique_ptr<Module> Mod = getLazyIRFileModule("f.ll",

I am currently trying to use LLVM (version 3.2) to generate code for a cluster where each node in the cluster will be running a 64-bit X86 chip, but *not* necessarily the same version of the X86 chip throughout the cluster. I am specifying that I want Position-Independent Code produced because the generated machine code may get moved (before it is executed) to a different logical address that

With LLVM 3.8 the JIT compiler engine generates an AVX512 instruction although I target an 'avx2' CPU (intel Core I7). I just downloaded the most recent 3.8 and still it happens. It happens with this input module: target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" define void @module_cFFEMJ(i64 %lo, i64 %hi, i64 %myId, i1 %ordered, i64 %start, i32* noalias align 32

When using ORC JIT, I'm having trouble with external function resolution (that is, of a function defined in the app, with C linkage). I add a declaration for the function to my IR, and when I use MCJIT, it finds it and all is well, But when I use ORC JIT (I *think* correctly, at least it closely matches what I see in the tutorial), I get an LLVM error, "Program used external function

Hi, I'm currently working my way through the tutorial with LLVM 3.9.1 on Windows (finished chapter 4) and stumbled over a few things which could be improved: - "LLVMContext" does not exist as a variable -> "TheContext" - Chapter 3: 5 times - Chapter 4: 1 time - Chapter 5: 4 times - Chapter 6: 2 times - Chapter 7: 2 times 3.4. Function Code