similar to: [LLVMdev] on-the-fly recompilation/relinking

LLVM, When we recompile, is it possible to "make" only one of the tools, or at least relink only the tools whose object files have changed? Thanks Dave

That's a good point.  But it's worth noting that recompileAndRelinkFunction() and freeMachineCodeForFunction() are both vestiges of the old JIT (i.e. the "JIT" as opposed to the "MCJIT").  The old JIT is no longer actively supported. -Phil On April 26, 2014 at 9:47:05 AM, Sri (emdcdeveloper at gmail.com) wrote: Hi Fillip                  Addition to my previous

Hi Filip Thank you for your detailed explanation, I was actually looking to implement an adaptive approach which is basically when some function executed more frequently, I was trying to drop that function and compiled and linked with new optimized function. I just did the following - whenever some function executed more times , I called-back to program, so I that I

Just updated the source and now I get the unreachable error again. The JIT doesn't know how to handle a RAUW on a value it has emitted. UNREACHABLE executed at /home/conrado/engines/llvm/lib/ExecutionEngine/JIT/JITEmitter.cpp:1542! I think that it's not helpful now, but I can post the program, if you want me to. On Sun, Jan 31, 2010 at 2:49 PM, Jeffrey Yasskin <jyasskin at

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:

Hi, Let's suppose we have an ELF executable that doesn't issue any syscall (I mean, syscalls are issued from an external dynamic library, not from the executable, and we can ignore such dynamic library because we have the proper equivalent library with the proper syscalls in MacOS and Windows). So, the question: Is it "currently possible" (by "currently possible" I

Couldn’t you write the relocations to the ELF executable? I don’t know if current linkers have support for this, but it seems possible in theory to make a relinkable executable. If you want to do this with an already linked executable though, then yea this won’t be possible. On Fri, Jul 20, 2018 at 10:30 AM Reid Kleckner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Typically

Hm, I wonder if the error message for llvm_unreachable should change. I think I remember a couple people focusing incorrectly on the UNREACHABLE instead of the actual error message above it (which means it's our fault, not theirs). Miranda, this is pointing at the same problem you had before. You have a function JIT-compiled, and you're trying to RAUW (ReplaceAllUsesWith) it. You'll

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

Albert Graef wrote: > The way I do this in Pure is to always call global functions in an > indirect fashion, using an internal global variable which holds the > current function pointer. When a function definition gets updated, the > Pure interpreter just jits the new function, changes the global variable > accordingly, and frees the old code. > > Compared to Duncan's

Great! It just worked. I was a bit worried about using pointers to call functions because it's a little too overwhelming in a big project, I think. Just for the record, if the function code isn't freed with freeMachineCodeForFunction, I get a segmentation fault during recompileAndRelinkFunction with this stack dump: Running pass 'X86 Machine Code Emitter' on function

On Sat, Jan 30, 2010 at 6:22 PM, Conrado Miranda <miranda.conrado at gmail.com> wrote: > Albert Graef wrote: >> >> The way I do this in Pure is to always call global functions in an >> indirect fashion, using an internal global variable which holds the >> current function pointer. When a function definition gets updated, the >> Pure interpreter just jits the

Hi, I am trying to replace a c-style function with another function with same signature. Consider the following code: std::stringstream main_c; main_c <<"#include <stdio.h>\n" <<"extern \"C\" { \n" <<"int print1()\n" <<"{\n" <<" printf(\"Inside

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

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 >

On Sun, Jan 31, 2010 at 7:35 AM, Conrado Miranda <miranda.conrado at gmail.com> wrote: > Great! It just worked. I was a bit worried about using pointers to call > functions because it's a little too overwhelming in a big project, I think. > > Just for the record, if the function code isn't freed with > freeMachineCodeForFunction, I get a segmentation fault during >

/bin/sh ../../mkinstalldirs /sw/lib/xmms/Input ../../libtool-disable-static --mode=install /usr/bin/install -c libxmms-flac.la /sw/lib/xmms/Input/libxmms-flac.la libtool-disable-static: install: warning: relinking `libxmms-flac.la' cd /Users/glenn/Desktop/flac-1.0.5_beta1/src/plugin_xmms; /bin/sh ../../libtool-disable-static --mode=relink gcc -I../.. -I./include -I../../include -g -O2

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

Question 1: I am trying to get a function not to be inlined. What are llvm's rules pertaining to inlining? I have tried all of the standard gcc options for turning off inlining and they do not seem to work. Here is the sample code that I am working with: #include <stdio.h> void print_string(char* strval); int main() { char* strval = "Hello world\n"; while(1){

On May 5, Misha Brukman wrote: > Maybe we can use you for a testimonial... :) Certainly. > > Tail Call Elimination: > > > > I've read over the "Random llvm notes", and see that you guys have > > though about this already. > > > > However, the note dates from last year, so I am wondering if there is > > an implementation in the works.