similar to: [LLVMdev] Question about llvm JIT

On Mon, Aug 6, 2012 at 9:35 AM, Peng Cheng <gm4cheng at gmail.com> wrote: > I have a function in llvm ir as follows: > > def [2 x [3 x double]] @fun() > { > return [ ... ]; // a [2 x [3 x double]] constant > } > > I would like to JIT this function in C. > > I first get the void pointer using: > > void *FPtr =

Hi, I was just reading through the Kaleidoscope tutorial (which is greatly written and understandable, thanks! ) hoping to get some glimpse about the workings of the JIT and the optimizations that are done at run time. I am curious as to how LLVM's JIT dynamically generates native code from bit code at run time and runs that code (I think my question is also somewhat more general in the sense

I am new to llvm so I might be missing a critical step. My system is Fedora 12 but this also happens in Mac OS X 10.6.2. Here are the steps I used to compile llvm: export TARGETS=x86,x86_64,cpp export INSTALLDIR=/home/rovitotv/llvm ../llvm-2.6/configure --prefix=$INSTALLDIR --enable-bindings=none --enable-targets=$TARGETS --enable-optimized --with-llvmgccdir=$INSTALLDIR

First, you have to call llvm-g++ to use the llvm-gcc front end, but it doesn't matter here. I'd like to suggest that you use pastebin to put your code and the send us the link, so that we can download it. The problem is that TheExecutionEngine is set to NULL (maybe because of a previous error), but it will be really better if you use pastebin. On Wed, Feb 17, 2010 at 6:01 AM, Todd Rovito

Hi, I was just reading through the Kaleidoscope tutorial (which is greatly written and understandable, thanks! ) hoping to get some glimpse about the workings of the JIT and the optimizations that are done at run time. I am curious as to how LLVM's JIT dynamically generates native code from bit code at run time and runs that code (I think my question is also somewhat more general in the sense

Bugs item #27425, was opened at 2009-11-11 21:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=411&aid=27425&group_id=85 Category: win32-open3 Group: Code Status: Open Resolution: None Priority: 3 Submitted By: Daniel Berger (djberg96) Assigned to: Nobody (None) Summary: win32-open3 doesn''t build with 1.9.1 Initial Comment: Windows XP VC++ 9

target triple = "i386-pc-linux-gnu" On 13/05/2010, at 9:25 PM, Anton Korobeynikov wrote: >> int (*FP)() = (int (*)())FPtr; >> int res = FP(); >> >> when the function executes correctly in the case of instead having created a standard global variable. > What is the platform you're running the code on? > > -- > With best regards, Anton

2017-01-10 0:06 GMT+01:00 David Blaikie <dblaikie at gmail.com>: > > > On Mon, Jan 9, 2017 at 2:59 PM Sanjoy Das via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> Sorry I fat fingered an earlier send in the previous email. I was >> trying to say: >> >> On Mon, Jan 9, 2017 at 2:52 PM, Sanjoy Das >> <sanjoy at

Thanks for the quick reply and fix. Now it just means I have to hunt further in exploring why, in my simple test program, replacing the following line of code: GlobalVariable* global = new GlobalVariable(*MyModule, IntegerType::get(getGlobalContext(), 32), false, GlobalValue::ExternalLinkage, 0, "global"); with the following line of code: GlobalVariable* global = new

I note also that this is not a currently unsupported target case where an error should/could/would be produced on attempting to emit code with thread local references. I say this because clang is able to compile both c source with __thread on a global and bc containing a @variable = thread_local global ... and a function that references the thread local global variable to both assembly and machine

Hi, Sorry I fat fingered an earlier send in the previous email. I was trying to say: On Mon, Jan 9, 2017 at 2:52 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: >> +1 Exactly this. >> I don't think C programmer will not understand using. The "=" makes it much >> simpler to read, even if it is the first time you see it, which is not the >>

On 2/19/2013 12:26 PM, Chris Lattner wrote: > > void foo() { > auto fp = printf; > fp("xyz\n"); > } > > With -fno-builtin-printf, we can't optimize the call to printf, even though it only becomes apparent after (trivial) devirtualization. Ha. Good example. What would you expect to happen in this case? --- a.cpp --- (with -fno-builtin-printf) pointer

There are several ways that VMs can take advantage of UFO and get the host to do fragmentation for them: drivers/net/macvtap.c: gso_type = SKB_GSO_UDP; drivers/net/tun.c: skb_shinfo(skb)->gso_type = SKB_GSO_UDP; drivers/net/virtio_net.c: skb_shinfo(skb)->gso_type = SKB_GSO_UDP; Our implementation of UFO for IPv6 does: fptr =

There are several ways that VMs can take advantage of UFO and get the host to do fragmentation for them: drivers/net/macvtap.c: gso_type = SKB_GSO_UDP; drivers/net/tun.c: skb_shinfo(skb)->gso_type = SKB_GSO_UDP; drivers/net/virtio_net.c: skb_shinfo(skb)->gso_type = SKB_GSO_UDP; Our implementation of UFO for IPv6 does: fptr =

Hi, I’m working on setting up ThinLTO+CFI for a C application which uses a lot of function pointers. While functionally it appears stable, it’s performance is significantly degraded, to the tune of double digit percentage points compared to regular LTO+CFI. Looking into possible causes I see that under ThinLTO+CFI iCall type checks almost always generate jump table entries for indirect calls,

I watched Teresa’s talk on ThinLTO from last year’s CppCon, and it sounded like adding global variable information to the summaries was in the works, or at least in planning. Can someone (Teresa?) please share the current status? If it’s part of future plans, are there any specific proposals that can be picked up and worked on? Thanks! > On Apr 9, 2018, at 6:51 PM, via llvm-dev <llvm-dev

Hi Peter, We could probably tolerate a certain amount of unused jump table entries. However, I just realized that all non-inline imported calls end up going through a jump table entry. Is that correct? Initially I thought you meant calls promoted from indirect. While this can be fixed by replacing direct calls to jump tables with direct calls to real targets, I found other cases where ThinLTO+CFI

2017-01-09 19:25 GMT+01:00 Mehdi Amini <mehdi.amini at apple.com>: > > On Jan 9, 2017, at 10:20 AM, Reid Kleckner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > On Mon, Jan 9, 2017 at 7:25 AM, Piotr Padlewski via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 2017-01-09 16:15 GMT+01:00 Renato Golin <renato.golin at linaro.org>:

Hi Dmitry, Sorry for the late reply. For CFI specific code generation, pcc is a better person to answer. But on the issue of global variables being optimized, that hasn't happened yet. That would be great if you wanted to pick that up! In your original email example, it seems like the file static i=53 could be constant propagated since there are no other defs, and the code in get_fptr

On 01/08/2013 01:48 PM, Eli Friedman wrote: > On Mon, Jan 7, 2013 at 6:07 PM, reed kotler <rkotler at mips.com> wrote: >> For example: >> >> /home/rkotler/llvm/install/bin/llc -mcpu=mips16 hf16_2.ll -march=mipsel >> -relocation-model=pic -o hf16_2.s -O3 -mips16-hard-float -soft-float > Try something like the following: > > float f; > double test(void*