similar to: Supporting external MCContext in MMI

Hi Evan, My apologies: I've been so excited on sharing the functionality that I forgot to review my patch! Evan Cheng wrote: > On Dec 10, 2007, at 9:52 AM, Nicolas Geoffray wrote: > > >> Hi everyone, >> >> Here's a patch that enables exception handling when jitting. I've >> copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may

On Dec 10, 2007, at 9:52 AM, Nicolas Geoffray wrote: > Hi everyone, > > Here's a patch that enables exception handling when jitting. I've > copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may > need > to factorize it, but the functionality is there and I'm very happy > with > it :) Very nice! I don't know enough about EH, someone else

Looks sane. Thanks. Evan On Feb 1, 2008, at 1:24 AM, Nicolas Geoffray wrote: > Dear all, > > Here's a new patch with Evan's comments (thx Evan!) and some cleanups. > Now the (duplicated) exception handling code is in a new file: > lib/ExecutionEngine/JIT/JITDwarfEmitter. > > This patch should work on linux/x86 and linux/ppc (tested). > > Nicolas > Index:

On Wed, May 10, 2017 at 4:45 AM, elio manes <elioarmando at optonline.net> wrote: > Hello, > > > I am hoping that perhaps you know the answer to my car audio question, or > can at least point me in the right direction. I own a 2013 Audi S4 that > has the 3G-Plus Multi Media Interface (MMI) with the Bang & Olufsen Sound > System. > > > The MMI is able to

Hi, I run into a a strange error when compiling with debug infos, where LLC tries to generate a variable DIE using a completely wrong frame-index (DebugDwarf tries to resolve frame index 27 in a simple function which only has a single frame object .. ). After digging around, I found that MachineModuleInfo has a VariableDbgInfo map, that is filled by SelectionDAGBuilder.

Hi Stefan, This looks like a bug. Thanks for catching this and writing the mailing list. Do you think you could submit a patch to fix the problem ? I understand that you can’t release your source code, but there is an easy way to generate test-cases from confidential code. If you can write a “verifier" that makes the compiler crash on an assertion then you can use bug point to reduce

Hello, I am hoping that perhaps you know the answer to my car audio question, or can at least point me in the right direction. I own a 2013 Audi S4 that has the 3G-Plus Multi Media Interface (MMI) with the Bang & Olufsen Sound System. The MMI is able to playback lossy, compressed audio files (MP3, WMA and AAC), but does not have native support for FLAC, ALAC, or WMA Lossless.

Attached is a working patch set for llvm to be able to emit arm64 (currently as triple aarch64-apple-ios) mach-o object files, in case someone is interested. I'm not sure if the llvm maintainers want the patch given the previous message that there's going to be an official patch set from apple to support this, but here is mine. What works (tested on an iPhone 5S): * objc strings,

On Apr 7, 2008, at 3:02 AM, Nicolas Geoffray wrote: > Hi Evan, > > Evan Cheng wrote: >> >> I don't think the duplication is going to be top much of a problem. >> If >> it is, I'll bug you about refactoring. :) >> >> > > I don't mean to show how lazy I can be, but I also need to know the > size > of the exception table

Hi, Two questions. 1) How are you computing size of the method being jitted? 2) Why not simply add the functionality of allocating emission buffer of specific size to MachineCodeEmitter instead? Thanks, Evan On Mar 30, 2008, at 12:05 PM, Nicolas Geoffray wrote: > Hi everyone, > > vmkit requires to know the size of a jitted method before emitting > the method. This allows to

Hi Evan, >>Is it possible to implement it without using MachineModuleInfo? but llvm-2.5 didn't , if implement it without using MachineModuleInfo, so I should create another ADT, but that is mostly same to MachineModuleInfo, that's repeat work! or less cost for me ! >> It's being removed. if so, what's the replacement of the MachineModuleInfo ? zhangzw

On Apr 1, 2008, at 12:50 AM, Nicolas Geoffray wrote: > Hi Evan, > > Evan Cheng wrote: >> 1) How are you computing size of the method being >> jitted? > > I add a new pass with addSimpleCodeEmitter, with the emitter being a > SizeEmitter. Since the target calls the emitter with functions such as > writeByte, writeWord, etc.... the SizeEmitter class implements these

On Apr 4, 2008, at 11:16 PM, Nicolas Geoffray <nicolas.geoffray at lip6.fr> wrote: > Evan Cheng wrote: >> >> Let's see. ARM has it already. PPC has getNumBytesForInstruction so >> you only need to add one to compute function size. Also you only need >> to implement it for targets that support JIT right now, which leaves >> Alpha and X86. I'm

On Apr 4, 2008, at 5:50 AM, Nicolas Geoffray wrote: > Evan Cheng wrote: >> On Apr 1, 2008, at 12:50 AM, Nicolas Geoffray wrote: >> >> >> That's a hack. :-) > > It is if you think that code emitter should only be used for actually > writing somewhere the data. It is not if you find it another useful > utility ;-) Except it's pretty slow at it. :-)

Hi Evan, Evan Cheng wrote: > > I don't think the duplication is going to be top much of a problem. If > it is, I'll bug you about refactoring. :) > > I don't mean to show how lazy I can be, but I also need to know the size of the exception table emitted in memory (JITDwarfEmitter.cpp). Reviewing it a little, I can not see how things won't be duplicated.

Hi Evan, Evan Cheng wrote: > 1) How are you computing size of the method being > jitted? I add a new pass with addSimpleCodeEmitter, with the emitter being a SizeEmitter. Since the target calls the emitter with functions such as writeByte, writeWord, etc.... the SizeEmitter class implements these function by incrementing a counter. At the end of the pass, the code size of the

Hi Joseph, There are several reasons that a client might want to access the object before it's loaded, so a general API like #2 seems like the way to go. To support this in MCJIT you can add this to the event listener API. Orc clients can already do this by adding a custom object-file layer. - Lang. On 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

Evan Cheng wrote: > On Apr 1, 2008, at 12:50 AM, Nicolas Geoffray wrote: > > > That's a hack. :-) It is if you think that code emitter should only be used for actually writing somewhere the data. It is not if you find it another useful utility ;-) > Some targets already have ways to compute the exact > size of a function. See ARM::GetFunctionSize()

Hello, I am working on a project where I need to insert some logic before each machine basic block. In particular, it involves setting some global variables and calling a function. I'm able to add the instructions and verify they get added, but when the compiled program runs, it stops with a segfault. For brevity, I'm not sharing the whole code here but basically I have a X86