similar to: [LLVMdev] Clang/LLVM 3.3 unwanted attributes being added: NoFramePointerElim

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

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

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

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:

Hi again, It's partially done. My concern is that it won't be accepted as is because of adding the flag parameter in a lot of places. I'd like to show what it looks like (here, not on llvm-commit yet), maybe someone could suggest a better way. There are two sources of the flag: field of TargetOptions and function attribute. I had to add the later one for InstCombine pass. Still

I understand you to mean that you have isolated the actual execution time as your point of comparison, as opposed to including runtime loading and so on. Is this correct? One thing that changed between 3.1 and 3.3 is that MCJIT no longer compiles the module during the engine creation process but instead waits until either a function pointer is requested or finalizeObject is called. I would

Sent from my Verizon Wireless 4G LTE DROID On Nov 17, 2016 5:53 PM, Mehdi Amini <mehdi.amini at apple.com<mailto:mehdi.amini at apple.com>> wrote: > > >> On Nov 17, 2016, at 4:33 PM, Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote: >> >> >> ________________________________ >>> >>> From: "Warren

----- Original Message ----- > From: "Sanjay Patel" <spatel at rotateright.com> > To: "Hal J. Finkel" <hfinkel at anl.gov> > Cc: "Mehdi Amini" <mehdi.amini at apple.com>, "llvm-dev" > <llvm-dev at lists.llvm.org>, "cfe-dev" <cfe-dev at lists.llvm.org>, > "andrew kaylor" <andrew.kaylor at

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 0x000000000000005f in

Hello, We have been investigating a crash in our application that may be related to how stack frames are generated by the JIT. We observe it with LLVM 2.9, but not with LLVM 2.8, everything else being the same. The crash occurs when dynamically generated code calls code that tries to unwind the stack. Here is what the stack trace looks like on MacOSX 10.6 : 0 libSystem.B.dylib

This may be bogus, but do you have: llvm::JITExceptionHandling = true; for the code that generates the dynamic code? It has been a while, but I don't recall what will happen when dynamic code, generated with jit exception handling turned off, invokes libraries which in turn try to unwind the stack via the libunwind api. However given that you say the code works with 2.8, my concern

When gdb is stopped in a function with no known start address, it has to make a guess about how to get the caller's rip. Either we assume that the saved rip is at rsp+8, or we assume that the saved rip is found via the rbp register. But it's a guess either way - gdb can't find the start of the function so it can't know which is the correct method. It would be nice if it could

Hi, I am trying to implement a scenario similar to running ExceptionDemo.cpp with parameter -1 (where the JITed code calls the C++ function which throws an exception) Different from the given example I am using IRParser instead of IRBuilder. I can successfully catch the exception in Linux but the program crashes in Mac and Windows. The code is similar to as follows: ### The test.cpp :

Hello everyone, I'd like to propose the attached patch to form FMA intrinsics aggressively, but in order to do so I need some clarification on the intended semantics for the various FP precision-related TargetOptions. I've summarized the three relevant ones below: UnsafeFPMath - Defaults to off, enables "less precise" results than permitted by IEEE754. Comments specifically

> On Dec 6, 2017, at 02:28, Haidl, Michael <michael.haidl at uni-muenster.de> wrote: > > The IR goes through a backend agnostic preparation phase that brings it into SSA from and changes the AS from 0 to 1. This sounds possibly problematic to me. The IR should be created with the correct address space to begin with. Changing this in the middle sounds suspect. > After this

Hi Owen, Having looked into this due to Clang failing PlumHall with it recently I can give an opinion... I think !NoExcessFPPrecision covers FMA completely. There are indeed some algorithms which give incorrect results when FMA is enabled, examples being those that do floating point comparisons such as: a * b + c - d. If c == d, it is still possible for that result not to equal a*b, as "+c

On Feb 8, 2012, at 10:44 AM, James Molloy wrote: > Hi Owen, > > Having looked into this due to Clang failing PlumHall with it recently I can give an opinion... > > I think !NoExcessFPPrecision covers FMA completely. There are indeed some algorithms which give incorrect results when FMA is enabled, examples being those that do floating point comparisons such as: a * b + c - d. If

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