search for: noframepointerelim

...frame-pointer-elim-non-leaf"="true" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "unsafe-fp-math"="false" "use-soft-float"="false" } I've tried to add options. I've tracked the code to: NoFramePointerElim I've seen the description of: ./lib/Target/TargetMachine.cpp RESET_OPTION(NoFramePointerElim, "no-frame-pointer-elim"); RESET_OPTION(NoFramePointerElimNonLeaf, "no-frame-pointer-elim-non-leaf"); RESET_OPTION(LessPreciseFPMADOption, "less-precise-fpmad");...

Hi - attached is a patch to enable building DragonEgg (x86_64) for LLVM3.3 and LLVM3.4. That is, add these changes to the 3.3 release, and it becomes possible to build DragonEgg against a llvm3.4 compiler. Regards, Richard Gorton Cognitive Electronics rcgorton at cog-e.com ---------- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name:

I run some code in JIT on x86-64 architecture. Even though llvm::NoFramePointerElim is set to true, I still see weird stack in gdb, see below. 800b485a4 is the current rip register where gdb stopped. Then many others values aren't valid. Then there is value that looks ok again. Why gdb can't determine stack? Yuri -- stack -- #0 0x0000000800b485a4 in ?? () #1 0x0000...

...Result->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; targetOptions.GuaranteedTailCallOpt = true; builder.setTargetOptions(targetOptions); TargetMachine* tm = bui...

...gement stuff and some of our code, with some dynamically-generated code higher in the stack. Our application can run reliably for hours, and runs correctly in Valgrind AFAWK, as long as we avoid the cases where dynamically generated code invokes window management functions. We have tried with both NoFramePointerElim set and cleared, it doesn't seem to make a difference. Has anybody else run into a similar stack trace? I have not found much through Google, but there's a MacRuby ticket with a very similar stack trace : http://www.macruby.org/trac/ticket/427. This was closed as "worksforme", bu...

...ff and some of our code, with some dynamically-generated code higher in the stack. Our application can run reliably for hours, and runs correctly in Valgrind AFAWK, as long as we avoid the cases where dynamically generated code invokes window management functions. > > We have tried with both NoFramePointerElim set and cleared, it doesn't seem to make a difference. > > Has anybody else run into a similar stack trace? I have not found much through Google, but there's a MacRuby ticket with a very similar stack trace : http://www.macruby.org/trac/ticket/427. This was closed as "worksforme...

...er.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; > targetOptions.GuaranteedTailCallOpt = true; > > builder.setTargetOptions(targetOptions)...

...std::unique_ptr<llvm::Module> Mod = llvm::parseIRFile("test.ll", Err, Context); std::string triple = llvm::sys::getProcessTriple(); Mod->setTargetTriple(triple); llvm::Function* f = Mod->getFunction("exec"); llvm::TargetOptions Opts; Opts.NoFramePointerElim = true; // Build engine with JIT std::unique_ptr<llvm::RTDyldMemoryManager> MemMgr(new llvm::SectionMemoryManager()); std::string err; llvm::EngineBuilder factory(std::move(Mod)); factory.setErrorStr(&err); factory.setEngineKind(llvm::EngineKind::JIT);...

...s you can assume that the frames on the stack are using a standard rbp type call frame and walk the stack reliably. But frame 0 can be tricky when you're guessing like this. J On Oct 15, 2010, at 5:58 PM, Yuri wrote: > I run some code in JIT on x86-64 architecture. > Even though llvm::NoFramePointerElim is set to true, I still see weird > stack in gdb, see below. > 800b485a4 is the current rip register where gdb stopped. Then many > others values aren't valid. Then there is value that looks ok again. > > Why gdb can't determine stack? > > Yuri > > > -- s...

...pt::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; >> targetOptions.GuaranteedTailCallOpt = true; >> >> builder.setTarge...

Hey guys, Is there a way to force the LLVM JIT compiler to omit the frame pointer in its generated i386/amd64 code? I've got a complex situation in which the stack can potentially be moved around so I'd prefer that the base pointer doesn't get pushed there. Félix

I have this problem: google-perftools fails to detect stack for the code run under JIT called through C++ api from my program. It shows in profile like all program is one block with the name _init. I clearly do set the option NoFramePointerElim and I do see how it makes a difference in stack frame under gdb. When running some code in JIT in lli (with option -disable-fp-elim) google perftools is able to detect stack and build the correct profile. Problem only exists in linux/i386. On FreeBSD/amd64 google perftools detects stack fine f...

.... I asked a gdb developer about it two summers ago when I was working on this, but he seemed dismissive about teaching gdb how to get this right. Reid On Fri, Oct 15, 2010 at 8:58 PM, Yuri <yuri at rawbw.com> wrote: > I run some code in JIT on x86-64 architecture. > Even though llvm::NoFramePointerElim is set to true, I still see weird > stack in gdb, see below. > 800b485a4 is the current rip register where gdb stopped. Then many > others values aren't valid. Then there is value that looks ok again. > > Why gdb can't determine stack? > > Yuri > > > -- stack -...

> exactly Well, in general, there is no connection between the performance on x86 and on ARM. You can try to profile your code and find what causes the speedup on x86 and figure out the slowdowns on ARM. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

...pt::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; >> targetOptions.GuaranteedTailCallOpt = true; >> >> builder.setTarge...

Hello, I am using Ubuntu 11.10 64-bit. Following the instructions on the VMKit website I grabbed llvm, clang, and vmkit via svn (and GNU Classpath via the link of the page). Compilation of llvm, clang and classpath went fine. I had problems compiling vmkit, which seem to be related to a TargetOptions being required as a parameter when creating a TargetMachine in LLVM. This led to a couple other

...6::GR32RegClass () from /usr/local/llvm/svn-r128446/lib/libLLVM-3.0svn.so Problem occurs when I am attempting to run a large module in JIT, from ExecutionEngine::runFunction, after static constructors have succeeded. EngineKind=1, OptLevel=3. When I change OptLevel to 0 problem disappears. llvm::NoFramePointerElim is true. When I change this to false problem disappears. I can't supply the whole module in a test case, it depends on many external functions and contains a lot of irrelevant information. My question is somewhat vague. Can anyone identify the problem by just looking at the code in and aro...

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

...on(-) diff --git a/include/llvm/Target/TargetOptions.h b/include/llvm/Target/TargetOptions.h index f7df921..e20fc36 100644 --- a/include/llvm/Target/TargetOptions.h +++ b/include/llvm/Target/TargetOptions.h @@ -62,7 +62,7 @@ namespace llvm { TargetOptions() : PrintMachineCode(false), NoFramePointerElim(false), LessPreciseFPMADOption(false), UnsafeFPMath(false), - NoInfsFPMath(false), NoNaNsFPMath(false), + NoInfsFPMath(false), NoNaNsFPMath(false), HonorFPExceptions(false), HonorSignDependentRoundingFPMathOption(false), UseSoftFloat(false), NoZero...