search for: alquarra

Hi Charllls, I didn't really get it. Are you saying that you would execute some functions using the JIT then, later, those functions will be modified and thus need to be re-jitted? Ciao, Duncan. On 07/06/12 20:13, Charllls Alquarra wrote: > > Sorry if it comes out a bit pushy bumping my own question, but it's been really > difficult to find any info regarding this functionality > in the mailing list archives. Just some emails i've found from people working on > NaCl: > > http://lists.cs.uiuc.edu/p...

...uiuc.edu/pipermail/llvmdev/2011-December/046055.html  is there a branch where this is being work on, or is internal chromium project so far? Also i'm not sure if this is exactly the same as what i'm looking for, but it sounds similar enough ________________________________ De: Charllls Alquarra <charlesneedspace at yahoo.com.ar> Para: "LLVMdev at cs.uiuc.edu" <> Enviado: sábado, 2 de junio de 2012 12:14 Asunto: [LLVMdev] dynamic linkage for jit Hi, I want to execute functions in a module, this module will have dependencies resolved in other modules. the modul...

Hi, I want to execute functions in a module, this module will have dependencies resolved in other modules. the modules might change (dynamic compilation environment) so i would prefer not not link all the dependencies in a single monolithic module, that is, if it can be avoided I hope to use Linker::linkModules but this is always destructive. That is ok for one module depending on a single one,

On Sep 30, 2011, at 11:02 AM, Charllls Alquarra wrote: > Hi all, > > Is it too soon to start porting EH code to the new C++ API? Nope! :-) > Are there sample implementations? llvm.org/demo still uses the old > EH gizmos. should we wait for 3.0 release? If you're using the LLVM APIs, then looking at how it's implemente...

Hi all, Is it too soon to start porting EH code to the new C++ API? Are there sample implementations? llvm.org/demo still uses the old EH gizmos. should we wait for 3.0 release? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110930/3bc09ea9/attachment.html>

On Apr 13, 2011, at 21:43 CDT, John McCall wrote: > And it's okay to have limited goals! I personally don't; I think we > should aim to get the IR design good enough to support crazy resumptive > languages with crazy custom unwinding schemes. But I need to know what > range of problems we're willing to consider solving before I can usefully > weigh different

On May 4, 2011, at 8:23 AM, Evan Cheng wrote: >> I don't know how realistic it is to model the loop buffer in the register allocator, but this would a very interesting thing to try to optimize for in a later pass. If an inner loop "almost" fits, then it would probably be worth heroic effort to try to reduce the size of it to shave off a few bytes. > > Jakob and I have

Hi, >Am 02.05.2011 um 11:05 schrieb Anton Korobeynikov: > >> Hello Toralf, >> >>> I wanted to ask what the current status of llvm-stack-switch[1] is. >> Given that this project never appeared in this mailing list - have you >> tried to ask its author? > >It is on the mailing list. This is how I found this project.

--- wednesday 11-may-11, John McCall <rjmccall at apple.com> wrote: > > > > However, it has always seemed to me that exception > handling (at least on c++) is just a particular syntax of a > subset of coroutine semantics: > > This is certainly one way of implementing exceptions.  > Unfortunately, it would be prohibitively expensive to create > a new coroutine

Generally speaking, when writing a llvm frontend, one will take an AST and first check that its semantics is well-defined. After this, one will take the AST and perform the IR build phase. I was wondering, how realistic is to perform directly the IR build phase onto the AST, and if errors are found during the build process, revert any partial changes to the module object? i assume something like