search for: triple_str

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 ).

Hi, Could you share how you compile IR and which version of JIT you use (Orc, MCJIT)? Could it be that you are using interpreter instead of actual JIT? Cheers, Alex. > On 5. May 2018, at 08:04, edA-qa mort-ora-y via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'm having issues of my compiler, and JIT execution, of LLVM IR being > rather slow. It's accounting for

What exactly is your alignment settings in your LLVM struct? Something like this would tell you the alignment of "something". const llvm::DataLayout dl(theModule); size_t size = dl.getPrefTypeAlignment(something); IIn "my" compiler, I don't do anything special to align structs, so it's plausibly your specific data-layout that says that i64 only needs aligning to

..._cpu_args = ZigLLVMGetHostCPUName(); target_specific_features = ZigLLVMGetNativeFeatures(); } else { target_specific_cpu_args = ""; target_specific_features = ""; } g->target_machine = LLVMCreateTargetMachine(target_ref, buf_ptr(&g->triple_str), target_specific_cpu_args, target_specific_features, opt_level, reloc_mode, LLVMCodeModelDefault); char *ZigLLVMGetHostCPUName(void) { std::string str = sys::getHostCPUName(); return strdup(str.c_str()); } char *ZigLLVMGetNativeFeatures(void) { SubtargetFeatures feature...

I think I see a potential issue. My ExecutionEngine setup may not be using the same target as my object code emitting, and in this test case I'm running in the ExecutionEngine.  I'll go over this code to ensure I'm creating the same triple and see if that helps -- I'm assuming it will, since I can't imagine the exact same triple with clang would produce a different layout. On

I'm having issues of my compiler, and JIT execution, of LLVM IR being rather slow. It's accounting for the vast majority of my full compilation time.  I'm trying to figure out why this is happening, since it's becoming an impediment.  (Note: by slow I mean about 3s of time for only about 2K of my front-end code, 65K lines of LLVM-IR) Using valgrind I see some functions which seem

...t; target_specific_features = ZigLLVMGetNativeFeatures(); > } else { > target_specific_cpu_args = ""; > target_specific_features = ""; > } > > g->target_machine = LLVMCreateTargetMachine(target_ref, > buf_ptr(&g->triple_str), > target_specific_cpu_args, target_specific_features, opt_level, > reloc_mode, LLVMCodeModelDefault); > > > > char *ZigLLVMGetHostCPUName(void) { > std::string str = sys::getHostCPUName(); > return strdup(str.c_str()); > } > > char *ZigLLVMGetN...

...atures(); >>> } else { >>> target_specific_cpu_args = ""; >>> target_specific_features = ""; >>> } >>> >>> g->target_machine = LLVMCreateTargetMachine(target_ref, >>> buf_ptr(&g->triple_str), >>> target_specific_cpu_args, target_specific_features, >>> opt_level, reloc_mode, LLVMCodeModelDefault); >>> >>> >>> >>> char *ZigLLVMGetHostCPUName(void) { >>> std::string str = sys::getHostCPUName(); >>>...

...blerLLVMC::DisassemblerLLVMC(const ArchSpec &arch, const char > *flavor_string)”, > > which I couldn’t find if it’s doing correct. Is there a place that > explains the “flavor” and > > “features_str” variables used at DisassemblerLLVMC.cpp:1163 > > (“newLLVMCDisassembler(triple_str, cpu, features_str.c_str(), flavor, > *this)”)? > > > > Another question that I have is, how can I compare the data it gets with > the real instructions? > > I found the file “PPCGenDisassemblerTables.inc”, where the table is > declared, and where the it > > is deco...

The `isBranch` flag is already set on the branch instructions. Furthermore, we do use the `isBranch()` query in a few places in the PPC back end, so this does work. Perhaps there's something specific about the lldb usage? Is it somehow possible that the `isBranch()` query is called on the wrong instruction? Would you be able to provide a test case that reproduces the issue? On Thu, Nov 30,