similar to: [LLVMdev] dynamic linkage for jit

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

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/pipermail/llvmdev/2011-December/046055.html  is there a branch where this is being work on, or is internal chromium project so far? Also

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,

> I don't know (don't use ices) but I thought I should inform you.. taking > user requests may cause you to violate the RIAA rules regarding that topic, > depending on how you handle it. Be careful. ;) Again, in Spain there is no rule in this sense... I mean, a normal air-FM/AM station can receive a call for a song and play it inmediately. What happens if this spanish station

> Again, in Spain there is no rule in this sense... I mean, a normal > air-FM/AM station can receive a call for a song and play it > inmediately. Yes. In the US as well. But not an INTERNET station. The rules are different if you broadcast over AM/FM than if you broadcast over IP. > What happens if this spanish station broadcasts its content to internet > and a US listener

Hi, In llvm 3.0 llvm::ConstantArray had a ::getAsCString() method that returned the buffer as a std::string. Now it seems that 3.1 this method dissapeared. I found that llvm::ConstantDataArray has a method called getAsString(), but it returns a Constant*. What is the safe way to retrieve the pointer of the Constant array as a C string?

On 16 November 2012 13:55, charles quarra <charllsnotieneningunputocorreo at gmail.com> wrote: > In llvm 3.0 llvm::ConstantArray had a ::getAsCString() method that > returned the buffer as a std::string. Now it seems that 3.1 this > method dissapeared. > > I found that llvm::ConstantDataArray has a method called > getAsString(), but it returns a Constant*. In 3.1

i'm afraid this question is extremely basic, but i've assumed that dumping a .bc file from a module was a trivial operation, but now, first time i have to actually do it from code, for the life of me i can't find one missing step in the process: static void WriteModule ( const Module * M, BitstreamWriter & Stream )

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 implemented in clang is a good start:

LLVM list, I bumped into Alex Friedman in the hall today and by coincidence he mentioned that they were switching to LLVM for their PLT Scheme JIT project. I had evaluated LLVM a few weeks ago for my own purposes, but decided that it was too C/C++ centered and that critical features such as tail call optimization and other stack manipulation features were likely stagnant. So naturally I asked

From: "Xiaowei.Hu" <xiaowei.hu at oracle.com> ocfs2_block_group_alloc_discontig() disables chain relink by setting ac->ac_allow_chain_relink = 0 because it grabs clusters from multiple cluster groups. It doesn't keep the credits for all chain relink,but ocfs2_claim_suballoc_bits overrides this in this call trace:

On Thu, May 05, 2005 at 03:46:58AM -0400, Alexander Friedman wrote: > On May 5, Misha Brukman wrote: > > To the best of my knowledge, this has not been done and no one has > > announced their intent to work on it, so if you are interested, > > you'd be more than welcome to do so. > > My C++ knowledge is completely non-existant, but so far I've had a >

Hi Frank, I'm not sure I completely understand what your delegating memory manager is doing, but I probably don't need to. If your primary objection is that you can't derive from the DefaultJITMemoryManager then I personally wouldn't object to your submitting a patch to make that accessible as a base class. The future path for JIT and MCJIT is under debate. A few of us would

On Thu, 5 May 2005, Misha Brukman wrote: > On Thu, May 05, 2005 at 03:46:58AM -0400, Alexander Friedman wrote: >> On May 5, Misha Brukman wrote: >>> To the best of my knowledge, this has not been done and no one has >>> announced their intent to work on it, so if you are interested, >>> you'd be more than welcome to do so. >> >> My C++ knowledge

I'm trying to get R running on OpenBSD/alpha. I've applied some configure patches which I've previously sent to the R-devel list to allow R to compile on an OpenBSD ELF platform (which OpenBSD/alpha is, as the i386 port soon will be). The patched source compiles without problems, and appears to run and perform properly apart from two (possibly unrelated) problems. 1) On startup

I'm making a Fink package for FLAC. It all builds fine except for the xmms plugin. I'd use the pbproject, but fink users are likely to want the xmms plugin which pbxbuild does not build. Also it seems the pbproject does not build dynamic libraries. I build with: ./configure --prefix=/sw --mandir=/sw/share/man make make install DESTDIR=/tmp (to simulate building into a deb file) The

Ok, it seems i had problems with stale stuff in there. I made clean and started over. The first part now correctly says " remember to run `libtool --finish /sw/lib'". The xmms plugin now gives a different error: /bin/sh ../../mkinstalldirs /tmp/sw/lib/xmms/Input ../../libtool-disable-static --mode=install /usr/bin/install -c libxmms-flac.la

Forgot to CC the list. -- John t. -------- Original Message -------- Subject: Re: [LLVMdev] Fwd: updating module references in call instructions after a module clone Date: Thu, 06 Dec 2012 11:48:37 -0600 From: John Criswell <criswell at illinois.edu> Organization: University of Illinois To: charles quarra <charllsnotieneningunputocorreo at gmail.com> On 12/6/12 11:43 AM,

Hi Assuming I had an application stub based on (say) lli, and I'd like to allow a hypothetical IDE to recompile and relink a function: Is that supported in any way currently? Assuming actually patching all call sites to point to the newly generated function is possible, I guess what I need is to be able to either track or find all of the call sites. The trickiest bit seems to be if the

>>>>> "Chris" == Chris Lattner <sabre at nondot.org> writes: >> FWIW I actually did this work twice, once for libjit and once for >> LLVM. I'm happy to provide a comparison, from a jit-writing >> perspective, if you're interested. Chris> Given your experience with both, I'd be very interested in any Chris> thoughts you have on