search for: llilc

...deopt bundles, PlaceSafepoints etc. is to "constant fold" -spp-no-statepoints and -rs4gc-use-deopt-bundles to true. We (Azul) have moved to a representation of safepoint polls, deopt state etc. that enables us to do the above; and at this point I'm waiting for an okay from you guys. LLILC should mostly Just Work in this new world, with the exception of gc transition operands -- the LLILC frontend will have to denote these using "gc-transition" operand bundles, and not by eagerly emitting gc.statepoint calls. You should be able to test out your changes by passing in -spp-n...

Agreed, that sounds like the best plan. I'll look into moving LLILC to ORC. Thanks -Joseph From: Russell Hadley Sent: Friday, May 29, 2015 8:13 PM To: Lang Hames; Joseph Tremoulet Cc: llvmdev at cs.uiuc.edu Subject: RE: [LLVMdev] MCJit interface question Hey Joseph, What Lang said made me wonder. Is it the right time for us (LLILC) to move to ORC? The long te...

Hi Lang, I'm looking at extending the compilation passes used in the LLILC JIT and it seems like the simplest thing is to make a copy of the SimpleCompiler functor into the LLILC code and then modify it for the phases I want to run. But I was wondering if this was the best approach. Do you expect different clients to create their own compiler functors or do you imagin...

Hi all, So I’m also working on LLILC. Specifically, I have been working on a JITEventListener to pass debug line info to the CoreCLR EE. With Joe’s change, I’ve lost the ability (or as far as I can tell) to attach an event listener. Is there a way within Orc to do the sorts of things that the JITEventListeners do in MCJIT? How would I...

Hey Joseph, What Lang said made me wonder. Is it the right time for us (LLILC) to move to ORC? The long term plan was to go there but this could be our forcing function. -R From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Lang Hames Sent: Friday, May 29, 2015 2:23 PM To: Joseph Tremoulet Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLV...

When we were using MCJIT, I could do this: // Attach the event listener Context.EE->RegisterJITEventListener( LLILCJitEventListener::createLLILCJitEventListener( new LLILCJitEventWrapper(&Context))); The event listeners listened for when an object is emitted (NotifyObjectEmitted), and that’s when we’d go through and extract debug info from the ObjectFile. Now, I imagine I’d need to add some sort o...

Hi, I think I need to make a small change to the MCJit interface, and would like some feedback on what the most appropriate option would be. I'm working on LLILC (a jit for the CoreCLR built on MCJit, which creates one module for each MSIL method, containing the main function and zero or more EH handler functions extracted from the MSIL method). The CoreCLR requires the jit to notify it of the size of the unwind info descriptors for each function in the mo...

...n Fri, May 29, 2015 at 9:05 AM, Joseph Tremoulet <jotrem at microsoft.com> wrote: > Hi, > > > > I think I need to make a small change to the MCJit interface, and would > like some feedback on what the most appropriate option would be. > > > > I'm working on LLILC (a jit for the CoreCLR built on MCJit, which creates > one module for each MSIL method, containing the main function and zero or > more EH handler functions extracted from the MSIL method). The CoreCLR > requires the jit to notify it of the size of the unwind info descriptors > for eac...

...ndles upstream, LLVM will be able to carry deoptimization state directly on calls and invokes using a `"deopt"` operand bundle. This will obviate reason (1) for keeping non-rewritten `gc.statepoint` s in the IR. This leaves (2), which I think can be dealt with in three ways: a. Change LLILC to emit unmanaged calls with a `"gc-transition"` operand bundle holding the transition arguments instead of a `gc.statepoint` wrapped call holding them. RS4GC would then would then parse and transcribe that information into the "transition args" field of the...

Hello, I'm working on LLILC (a jit for the CoreCLR built on ORC), in particular, on using LLILC as an ngen jit. I would like to have an ability to be notified of relocations that ObjectLinkingLayer is applying and to be able to tell the linking layer not to resolve certain relocations for external symbols (so that the client...

The LLILC project does not require direct interaction with the PDB, so it’s not part of our plans. The JIT uses a special reporting format to communicate debug info (frame info and machine->IL mappings) back to the CoreCLR EE. The debugger joins this with the frontend-produced debug information (IL->s...

...39;ve mentioned some of these, but > specific topics of interest for me include: > - Dealing with the explosion of basic blocks that come up with > languages where almost every function call, implicit and explicit, can > raise exceptions. I saw this come up in a recent discussion about LLILC. One simple way to do this is to introduce a new intrinsic, like “llvm.nullcheck(x)” which symbolically represents the null check and bail out in one instruction - instead of the fully elaborated basic block representation (which slows everything down by increasing the height of the CFG). These n...

..._______________________________ From: llvmdev-bounces at cs.uiuc.edu <llvmdev-bounces at cs.uiuc.edu> on behalf of Chandler Carruth <chandlerc at google.com> Sent: Wednesday, April 15, 2015 3:14 AM To: C Bergström; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] MS fork They presented on LLILC at EuroLLVM, and indicated they were just starting up but were definitely planning to contribute everything back to upstream. Personally, I'm pretty happy to see them talking actively to the community, participating effectively in EuroLLVM and some of the stuff they talked about there was reall...

Thanks for the pointer, it's always helpful to be able to see how another project solved similar problems. > On Mar 8, 2016, at 11:24 AM, Andy Ayers <andya at microsoft.com> wrote: > > FWIW, LLILC (https://github.com/dotnet/llilc) uses MCJIT with a custom memory manager to hold onto the binary bits and discard the rest. > > As far as I know it doesn't leak, though we don't blow away the context, so that grows a bit over time. > > -----Original Message----- > From: ll...

...gjmp outside a child frame of the function > that called setjmp. Anyway it turned all far too hacky. > > If you are willing to do research, compare implementations and behavior > with the MachO and ELF versions. At least one of them works, just not on > Windows ;) > Also check the LLILC project: *https://github.com/dotnet/llilc* > <https://github.com/dotnet/llilc> I heard about some solution that uses > trampolines to push exceptions back to dynamically loaded code and handle > them there. > > AND disclaimer: I did not follow recent developments in this area....

...ndefined behavior to call longjmp outside a child frame of the function that called setjmp. Anyway it turned all far too hacky. If you are willing to do research, compare implementations and behavior with the MachO and ELF versions. At least one of them works, just not on Windows ;) Also check the LLILC project: https://github.com/dotnet/llilc I heard about some solution that uses trampolines to push exceptions back to dynamically loaded code and handle them there. AND disclaimer: I did not follow recent developments in this area. If there's news please let me know! Cheers & Good Luck! S...

...se the supplied address to apply every relocation for that symbol. Is that sufficient to support your use-case? Cheers, Lang. On Wed, Jun 24, 2015 at 12:03 AM, Eugene Rozenfeld <Eugene.Rozenfeld at microsoft.com<mailto:Eugene.Rozenfeld at microsoft.com>> wrote: Hello, I’m working on LLILC (a jit for the CoreCLR built on ORC), in particular, on using LLILC as an ngen jit. I would like to have an ability to be notified of relocations that ObjectLinkingLayer is applying and to be able to tell the linking layer not to resolve certain relocations for external symbols (so that the client...

...nce and clarify the goal. > > Joseph Tremoulet from Microsoft partially confirmed Igor's statements: > "I checked with some experts here, and they agree with your/Igor’s > assessment that it’s not possible to have a dynamically generated handler on > x86" > "the llilc code only handles x86_64, not 32-bit x86; I know the > implementations of WinEH are quite different between the two" > First conclusion: No solution for JITed catch handlers on x86. > > I think for most of us x86 has little prio anyway, so let's focus on x86_64. > In theory...

I work on the LLILC team, and we are trying to send debug line info through to the CoreCLR EE without using an EventListener because we need to send extra info (more than just available in DebugLoc) like if it’s a call instruction, a call site, etc. We thought extending AsmPrinterHandler would be useful since it seems...

Dear MS, Will you be cleaning up and encouraging people to get the work on github upstream? https://github.com/Microsoft/llvm/commits/MS Thanks