similar to: LLJIT global constants string becomes invalid in generated code

Hello, I recently noticed a performance issue of JIT execution vs native code of the following simple logic which computes the Fibonacci sequence: uint64_t fib(int n) { if (n <= 2) { return 1; } else { return fib(n-1) + fib(n-2); } } When compiled natively using clang++ with -O3, it took 0.17s to compute fib(40). However, when executing using LLJIT, fed with the IR output of "clang++

Hello, I recently hit an issue when JIT'ing my generated IR using llvm::orc::LLJIT. My IR contains the following definition of a global variable: > $_ZZ23TestStaticVarInFunctionbE1x = comdat any > @_ZZ23TestStaticVarInFunctionbE1x = linkonce_odr dso_local global i32 123, > comdat, align 4 > And in my host process, there exists the same symbol. I would expect LLJIT to resolve the

Thank you so much David! After thinking a bit more I agree with you that attempting to add 'target-features' to my functions seem to be the safest approach of all. I noticed that if I mark the clang++ function as 'AlwaysInline', the inlining is performed normally. Is this a potential bug, given what you said that LLVM may accidentally move code using advanced cpu features outside

On Thu, Aug 13, 2020 at 6:11 PM Haoran Xu <haoranxu510 at gmail.com> wrote: > > Thanks for the insights David! > > For your first 3 points, is it correct to understand it as following: the external function prototypes are missing reliable information on whether the function throws and what exceptions it may throw (due to C++'s design failures and that it is impractical to

Hi David, Thanks for your quick response! I now understand the reason that inlining cannot be done on functions with different target-attributes. Thanks for your explanation! However, I think I didn't fully understand your solution; it would be nice if you would like to elaborate a bit more. Here's a bit more info on my current workflow: (1) The clang++ compiler builds C++ source file

On Thu, Aug 13, 2020 at 6:35 PM Haoran Xu <haoranxu510 at gmail.com> wrote: > > Thanks for the reply. > >> Sorry, yes. No difference between explicit error handling and >> exceptions. The difference is in all the functions that don't have >> explicit error handling but (in the exception-using equivalent code) >> aren't marked nothrow (where, without

On Thu, Aug 13, 2020 at 4:38 PM Haoran Xu <haoranxu510 at gmail.com> wrote: > > Hello David and Sterling, thanks for the reply! > > I have no intention to heat up the discussion, please pardon me if I asked questions that might sound silly to you -- it's just that I truly didn't understand since I'm not expert in llvm or optimizer or exception handling at all. >

There is a fair amount of dispute and detail here, and real benchmarks can be difficult to write, because you often end up in arguments about whether or not the two styles of coding are equivalent or not. But I agree with Dave--exceptions generally inhibit optimization. One way to think about this is that, generally speaking, the less the compiler can prove about a program, the less aggressive

Hello, when building code with -Ofast -ffinite-math-only -ffast-math, clang generates calls to "finite" variants of math functions. This has been the source of a fair amount of issues in a "normal", non-JIT pipeline, which seem to have been fixed over time - a simple fix being recompiling the target app against the new glibc. - https://bugs.llvm.org/show_bug.cgi?id=44842 -

I am in the process of porting our ORC code to ORC v2 and LLJIT. Now that I have worked around a problem getting global constructors to be called, everything seems to work unless a module declares a static thread-local variable. In that case I get a "JIT session error" saying that the symbol __ emutls_v.xyz was not found (substitute the mangled variable name for "xyz"). Does

Hi, We are using the new LLJIT class in our compiler. We have not been successful using the parallel JIT feature. When we tried it previously on multiple modules, our compile-time increased significantly. I don't know if we are using it incorrectly, or that we miss out on optimizations we get when running on a single merged module, but it hasn't worked for us yet. We are pretty far behind

Hello, Right now I am just using a Generator to look for symbols in my process (which links dynamically against libc / libm). It seems to have no trouble finding every other libc / libm / libc++ / ... symbol so I assumed that it was not necessary to specifically link against libm where these __finite symbols reside: $ nm -D /usr/lib/libm.so.6 | grep finite 0000000000050540 T

Argh. Thanks for the info. We're on Linux. On Fri, Dec 20, 2019 at 3:46 PM Praveen Velliengiri < praveenvelliengiri at gmail.com> wrote: > Hi Geoff, > Gathering from past, I remember that the ORCv2 doesn't support thread > local variable but not sure what is the current status now. What platform > you are on? > CC'ed (Lang hames) he knows exactly what is the

And yet the same C++ code using thread-local variables works fine (or seems to) when compiled with Orc v1. Does the change to the Orc API really make thread-local storage more difficult? On Fri, Dec 20, 2019 at 3:52 PM Praveen Velliengiri < praveenvelliengiri at gmail.com> wrote: > Oh, I think Linux don't have support for TLS. > > On Fri, 20 Dec 2019 at 20:19, Geoff Levner

This had also came up at llvm-devmtg briefly at the JIT roundtable. One of the collaborators on my project had started a patch years ago to implement some of it https://reviews.llvm.org/D8815, but then we went a different direction with TLS in our frontend and it became unnecessary. On Fri, Dec 20, 2019 at 12:36 PM David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > +Lang

Hello, here is a repro which runs in a docker image. https://we.tl/t-O1EhIAOeOF To see the issue, run repro.sh It will first download a (big, sorry) centos:7 docker image with my build of LLVM-11 and build a simple lljit-based example. This example is called with some trivial .cpp which calls `cos`. When ran from *within the container* it works. When the same example, with the same bitcode

Yes, I confirm. Le ven. 20 déc. 2019 à 19:12, Praveen Velliengiri < praveenvelliengiri at gmail.com> a écrit : > Hi, > Orc v2 is different from the internal structure then Orc v1 not just in > API level. > TLS support is not in ORC for a long time at least I'm aware of , Could > you please confirm that ORC v1 actually compiles and run the code with > Thread locals?

I don't think it's especially hard, but just not specifically unimplemented because nobody's had a strong need for it. There's probably some combinations of code models and machines that does happen to work (e.g. emutls+linux+large-code+large-data+no-PIC). Julia has some support for thread locals, but as a JIT in control of the language we currently try to generate better code than

Hi Lang, Thank you for your answer! This helped me again a lot!! Also that ResourceTracker is a really neat feature! Looking forward to it! :3 I changed the title cause… there is another issue I have (sorry about that…) I’m finally allowed to investigate the ORC JIT for integration into our system, which meant I got a few days to actually play around with it. However, another problem arise

Hey Lang, I would be really happy to only have one LLJIT instance and using multiple JITDylibs. However… it seems like that I don’t know enough to use them. So I wonder… 1. When I add Module A to JITDylib A and Module B to JITDylib B – where will those look for undefined symbols? Will Module A for example: will it only search itself and the MainDylib? Or would it also search in JITDylib B?