search for: jit'ed

I am having problems JIT'ing 2 functions where one of them calls the other. (I am using the old JIT interface). Here is the setup: define void @func1() { entrypoint: call void @func2(void) ret void } define void @func2(void) { entrypoint: ret void } (I omit the arguments and function bodies for simplicity...

I'm trying to figure out the best way to handle signals raised during the execution of LLVM's optimization passes or the JIT'ing of code prior to running it. In particular, LLVM throws unix signals instead of C++ exceptions while the header ErrorHandling.h contains the following warning (the last paragraph in particular): /// llvm_instal_error_handler - Installs a new error handler to be used /// whenever a ser...

Hi, I’m wondering if it’s possible to debug code JIT’ed with the newer ORC JIT. The LLVM documentation has a page at llvm.org/docs/DebuggingJITedCode.html <http://llvm.org/docs/DebuggingJITedCode.html> showing an example of using gdb to debug MCJIT’ed code, but has no mention of ORC JIT. From searching around online I’ve gotten the impre...

...inish faster, and if it crashes, I might go back and turn them on. Reid On Fri, Jun 18, 2010 at 6:33 AM, Curtis Faith <curtis at curtisfaith.com> wrote: > I'm trying to figure out the best way to handle signals raised during the > execution of LLVM's optimization passes or the JIT'ing of code prior to > running it. > In particular, LLVM throws unix signals instead of C++ exceptions while the > header ErrorHandling.h contains the following warning (the last paragraph in > particular): >   /// llvm_instal_error_handler - Installs a new error handler to be us...

I'm not sure I have a clear picture of what you're JIT'ing. If any of the JIT'ed functions call other JIT'ed functions, it may be difficult to find all the dependencies of a functions and recreate them correctly on a subsequent load. Even if the JIT'ed functions only call non-JIT'ed functions, I think you'd need some confidenc...

It seems one can only put constant global statements _before_ any functions are defined, not after. I would like to produce eg. "hello world!" functions in a JIT. So I was hoping to use global string constants. Is there another way to do this kind of thing ? thanks, Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com

On Mon, 12 Jun 2006, Simon Burton wrote: > It seems one can only put constant global statements > _before_ any functions are defined, not after. This is true in .ll files, but not necessary in LLVM modules. > I would like to produce eg. "hello world!" functions in a JIT. > So I was hoping to use global string constants. > Is there another way to do this kind of thing ? You should just be able to create the global. Can you be more specific what you are doing? -Chris -- http://nondot.org/sabre/ http://llvm.org/

...files. I'm using a workaround: permanently malloc some memory and just use that address directly in the .ll Could I suggest that this fact about globals be added to the LangRef documentation ? thanks, Simon. > > > I would like to produce eg. "hello world!" functions in a JIT. > > So I was hoping to use global string constants. > > Is there another way to do this kind of thing ? > > You should just be able to create the global. Can you be more specific > what you are doing? > > -Chris > > -- > http://nondot.org/sabre/ > http:...

...umentation so looking at the original source code in lldb is pretty useless because I can't see the instrumentation. Looking at the LLVM IR on the otherhand is very useful because I can see the ASan instrumentation at a (slightly) higher level than the native machine code assembly. * Debugging JIT'ed code. The LLVM IR that is JIT'ed might not come from a higher level language and might be generated directly. In this case the only debug information that makes sense is the LLVM IR representation of the JIT'ed LLVM IR. This might be a bit tricky though because there might not be an...

Hi Connor, ...The LLVM documentation has a page at > llvm.org/docs/DebuggingJITedCode.html > showing an example of using gdb to debug MCJIT’ed code, but has no mention > of ORC JIT. What debugging support MCJIT has is provided by the RuntimeDyld utility, which ORC shares. I would expect anything in that document to apply to ORC as well, though I haven't tested it p...

Greetings, LLVM wizards. I was just wondering if any progress has been made on this issue in the last few months (using gdb to debug a module compiled by Orc). I had to move to the Orc API in order to be able to call modules' constructors and destructors as needed, but I would quite like to be able to debug and profile the resulting code as well... Thanks, Geoff -------------- next part

...d on your GDBRegistrationListener. If code is going to be unloaded we would have to add an extra hook to call NotifyFreeingObject -- that seems totally reasonable to add. -- Lang. On Wed, Oct 11, 2017 at 10:44 AM, Yichao Yu <yyc1992 at gmail.com> wrote: > > What debugging support MCJIT has is provided by the RuntimeDyld utility, > > which ORC shares. I would expect anything in that document to apply to > ORC > > as well, though I haven't tested it personally. > > I'm pretty sure that's not the case, at least not with any simple > orcjit tutoria...

...pbox.com/u/46791180/perf.png>. One thing I'm a bit confused about is why I see a FunctionPassManager there. I use a FunctionPassManager at the end of LLVM IR code generation, write the IR to disk, then read it back later. Why is apparently another FunctionPassManager being used during the JIT'ing of the IR code? And how do I control what the passes are to that FunctionPassManager? The function that's being JIT'd has to executed only once so, ideally, I want to find a sweet spot between speed-of-JIT'ing and speed-of-generated-machine code. - Paul On Nov 13, 2012, at 1...

Thanks for responding. Sorry for the delay in my reply, but I was dealing with hurricane Sandy. Anyway.... My software build produces libmylib.so. The JIT'd function only calls external C functions in libmylib.so and not other JIT'd functions. The C functions are simple thunks to call constructors. For example, given: class BinaryNode : public Node { public: BinaryNode( Node *left, Node *right ); // ... }; there exists a C thunk:...

...tr" instructions here and there -- fairly straight-forward LLVM code. I then write out the LLVM IR code to disk and, at some later time, read it back in with ParseIR(), do getPointerToFunction(), execute that function, and the C++ iterator tree has been reconstituted. This all works, but the JIT compile step is *slow*. For a sequence of about 8000 LLVM instructions (most of which are "call"), it takes several seconds to execute. It occurred to me that I don't really want JIT compiling. I really want to compile the LLVM code to machine code and write that to disk so that wh...

...original > source code in lldb is pretty useless because I can't see the > instrumentation. Looking at the LLVM IR on the otherhand is very > useful because I can see the ASan instrumentation at a (slightly) > higher level than the native machine code assembly. > > * Debugging JIT'ed code. The LLVM IR that is JIT'ed might not come > from a higher level language and might be generated directly. In this > case the only debug information that makes sense is the LLVM IR > representation of the JIT'ed LLVM IR. This might be a bit tricky > though because th...

On Nov 24, 2012, at 3:50 PM, Rafael Espíndola wrote: > On 24 November 2012 17:36, Chris Lattner <clattner at apple.com> wrote: >> As others have said, unfortunately it is premature to remove the old jit. I don't know of anyone using the EH code though... It can almost certainly be removed! > > Cool. I will remove the EH bits by the end of the week if no one complains. Do you mean you're going to remove EH entirely from the old JIT? If so, I'll complain ;). As you pointed out...

...89s. Any ideas? - Paul On Nov 12, 2012, at 1:52 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > Hi Paul, > > This is definitely outside the area where I know the particulars of what's going on. However, one idea that might be worth trying is setting the JIT optimization level to 'CodeGenOpt::None'. This should trigger the use of the FastISel instruction selector. Normally, you wouldn't want that for anything other than generating debug code, but since your routines are just making calls, it might work for you. > > -Andy > >...

Hi Geoff, hi Alex If you implement the GDB JIT Interface in your Orc JIT, this is in general possible (at least from the JIT's point of view) with both debuggers, GDB and LLDB. Please have a look at the example here: https://github.com/weliveindetail/JitFromScratch/tree/jit-debug/gdb-interface You will probably need to adjust the code depe...

I don't think that GDB support is even present in the latest version of the old JIT in trunk. It used to have code to register emitted functions with GDB in a way that let GDB find the function name and EH frame information, but that got taken out back in January (r147615). As it stands now, I don't think GDB would provide any useful information at all about code emitted by...