search for: jitdefault

...h TargetOptions without any success… Here is the kind of code we use to allocate the JIT: EngineBuilder builder(fResult->fModule); builder.setOptLevel(CodeGenOpt::Aggressive); builder.setEngineKind(EngineKind::JIT); builder.setUseMCJIT(true); builder.setCodeModel(CodeModel::JITDefault); builder.setMCPU(llvm::sys::getHostCPUName()); TargetOptions targetOptions; targetOptions.NoFramePointerElim = true; targetOptions.LessPreciseFPMADOption = true; targetOptions.UnsafeFPMath = true; targetOptions.NoInfsFPMath = true; targetOptions.NoNaNsFPMath = true...

...t; gave me the following advice: > - Use ELF > - Using this results in another issue about comdat sections, see here: > https://root.cern.ch/phpBB3/viewtopic.php?t=19808 > - Stick with COFF, but use the large code model > - No observed difference, seems to be the case because JITDefault is > being used in the same way as Large, which would make sense > - According to the clang developers I spoke to, Lang and Andy might > have an interest in fixing this (would seem likely, as they’re the two > commenters on the first issue I linked), since it’s better to use COFF on...

...gt; > Here is the kind of code we use to allocate the JIT: > > EngineBuilder builder(fResult->fModule); > builder.setOptLevel(CodeGenOpt::Aggressive); > builder.setEngineKind(EngineKind::JIT); > builder.setUseMCJIT(true); > builder.setCodeModel(CodeModel::JITDefault); > builder.setMCPU(llvm::sys::getHostCPUName()); > > TargetOptions targetOptions; > targetOptions.NoFramePointerElim = true; > targetOptions.LessPreciseFPMADOption = true; > targetOptions.UnsafeFPMath = true; > targetOptions.NoInfsFPMath = true; >...

...kind of code we use to allocate the JIT: >> >> EngineBuilder builder(fResult->fModule); >> builder.setOptLevel(CodeGenOpt::Aggressive); >> builder.setEngineKind(EngineKind::JIT); >> builder.setUseMCJIT(true); >> builder.setCodeModel(CodeModel::JITDefault); >> builder.setMCPU(llvm::sys::getHostCPUName()); >> >> TargetOptions targetOptions; >> targetOptions.NoFramePointerElim = true; >> targetOptions.LessPreciseFPMADOption = true; >> targetOptions.UnsafeFPMath = true; >> targetOptions.NoInf...

...gt;> - Use ELF >>> - Using this results in another issue about comdat sections, see here: >>> https://root.cern.ch/phpBB3/viewtopic.php?t=19808 >>> - Stick with COFF, but use the large code model >>> - No observed difference, seems to be the case because JITDefault is >>> being used in the same way as Large, which would make sense >>> - According to the clang developers I spoke to, Lang and Andy might >>> have an interest in fixing this (would seem likely, as they’re the two >>> commenters on the first issue I linked), s...

Hi Elena, > (2) Proposal > Define one more Code Model, let's say "LargeNearConst", which will allow to put constants in .text. Isn't that a little heavy-handed? The large model only requires the less efficient access for symbols we can't control, and in fact x86 still uses pc-relative conditional branches within a function so it can't pretend to support a single

...std::vector<std::string>(), // ExtraArchives > false, // EnableCacheManager > std::string(), // ObjectCacheDir > std::string(), // FakeArgv0 > false, // DisableCoreFiles > false, // NoLazyCompilation > Reloc::PIC_, // RelocModel > CodeModel::JITDefault, // CMModel > true, // GenerateSoftFloatCalls > FloatABI::Soft, // FloatABIForCalls > false, // EmitJitDebugInfo > false // EmitJitDebugInfoToDisk > ); > > I'm getting the next error text: > *error creating EE: target does not support JIT code genera...

...68aad7ca4c98ee1f08d2cb024bf8%7c72f988bf86f141a >>>> f91ab2d7cd011db47%7c1&sdata=DxCUHFZFW7SxfN6pHlHDfT3yY4DrE5DZTyLCVDWv >>>> 3Yw%3d >>>> - Stick with COFF, but use the large code model >>>> - No observed difference, seems to be the case because JITDefault >>>> is being used in the same way as Large, which would make sense >>>> - According to the clang developers I spoke to, Lang and Andy >>>> might have an interest in fixing this (would seem likely, as they’re >>>> the two commenters on the first...

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

...nstants should be in a special read-only section, and this section may be far from the text section. I'm working with JIT model or with only one object file. The code model, when all constants are near, we can call "LargeJIT". (Is it sounds better then LargeNearConst?) For X86 target JITDefault will be translated CodeModel::LargeJIT for x64 and CodeModel::Small for 32-bit. And the TargetLoweringObjectFile already has CodeModel inside. So the code will look like : const MCSection * TargetLoweringObjectFile::getSectionForConstant(SectionKind Kind) const { if (getCodeModel() == CodeModel...

Both Clang/LLVM 3.4 -> Clang/LLVM 3.5 And i will also try using MCJIT. 2014-09-17 18:56 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>: > Hi, Tim. > > I've used Clang 3.4 final release and now i'm going to test it with 3.5 > release (since i've read about arm64 improvements). > I will report my results. > > BTW, is it possible to get smth like

...kind of code we use to allocate the JIT: >> >> EngineBuilder builder(fResult->fModule); >> builder.setOptLevel(CodeGenOpt::Aggressive); >> builder.setEngineKind(EngineKind::JIT); >> builder.setUseMCJIT(true); >> builder.setCodeModel(CodeModel::JITDefault); >> builder.setMCPU(llvm::sys::getHostCPUName()); >> >> TargetOptions targetOptions; >> targetOptions.NoFramePointerElim = true; >> targetOptions.LessPreciseFPMADOption = true; >> targetOptions.UnsafeFPMath = true; >> targetOptions.NoInf...

Hi all, I analyzed more and ready (1) to describe the problem and (2) I have a proposal. (1) Problem description: In X86_64 target the Code Model is "Large". It means that address is 64-bit and IP-relative memory operand can't be used in this case. (Because in IP-relative memory operand the displacement is 32-bit). In order to load constant, we use 2 instructions. movabsq

...c72f988bf86f141a >>>>>> f91ab2d7cd011db47%7c1&sdata=DxCUHFZFW7SxfN6pHlHDfT3yY4DrE5DZTyLCVDWv >>>>>> 3Yw%3d >>>>>> - Stick with COFF, but use the large code model >>>>>> - No observed difference, seems to be the case because JITDefault >>>>>> is being used in the same way as Large, which would make sense >>>>>> - According to the clang developers I spoke to, Lang and Andy >>>>>> might have an interest in fixing this (would seem likely, as they’re >>>>>> th...

...t;>> false, // EnableCacheManager >>> std::string(), // ObjectCacheDir >>> std::string(), // FakeArgv0 >>> false, // DisableCoreFiles >>> false, // NoLazyCompilation >>> Reloc::PIC_, // RelocModel >>> CodeModel::JITDefault, // CMModel >>> true, // GenerateSoftFloatCalls >>> FloatABI::Soft, // FloatABIForCalls >>> false, // EmitJitDebugInfo >>> false // EmitJitDebugInfoToDisk >>> ); >>> >>> I'm getting the next error text: >>...

...;> >> f91ab2d7cd011db47%7c1&sdata=DxCUHFZFW7SxfN6pHlHDfT3yY4DrE5DZTyLCVDWv >> >>>>>> 3Yw%3d >> >>>>>> - Stick with COFF, but use the large code model >> >>>>>> - No observed difference, seems to be the case because JITDefault >> >>>>>> is being used in the same way as Large, which would make sense >> >>>>>> - According to the clang developers I spoke to, Lang and Andy >> >>>>>> might have an interest in fixing this (would seem likely, as >> th...

...>>>> std::string(), // ObjectCacheDir >>>>> std::string(), // FakeArgv0 >>>>> false, // DisableCoreFiles >>>>> false, // NoLazyCompilation >>>>> Reloc::PIC_, // RelocModel >>>>> CodeModel::JITDefault, // CMModel >>>>> true, // GenerateSoftFloatCalls >>>>> FloatABI::Soft, // FloatABIForCalls >>>>> false, // EmitJitDebugInfo >>>>> false // EmitJitDebugInfoToDisk >>>>> ); >>>>> >>&g...

Hi, I recently updated to current llvm svn and fixed-up the minor compiler errors I encountered. However, at run-time even my Hello world programs crash with a segmentation fault. A concrete program that crashes on my Linux x86_64 Fedora box is: declare void @__ot_runtime_print_int(i8*, i32) define void @main() { entry: call void @__ot_runtime_print_int(i8* null, i32 12) br label %return

...t;>>> f91ab2d7cd011db47%7c1&sdata=DxCUHFZFW7SxfN6pHlHDfT3yY4DrE5DZTyLCVDWv >> >>>>>> 3Yw%3d >> >>>>>> - Stick with COFF, but use the large code model >> >>>>>> - No observed difference, seems to be the case because JITDefault >> >>>>>> is being used in the same way as Large, which would make sense >> >>>>>> - According to the clang developers I spoke to, Lang and Andy >> >>>>>> might have an interest in fixing this (would seem likely, as they’re &gt...