similar to: [LLVMdev] IR function pointers

Hi, > For example: call void %1608(%"struct.LRT::RGBAucharFrameBuffer"* > %1604) > > How can I resolve the targets of these? Also, why are they appearing as > indirect calls in the IR, when they are direct calls in the source? You don't mention what language you're trying to compile, though it looks plausibly C++. I'd guess these are virtual function calls.

Hi Tim, This is C++ indeed. Basically, I am profiling the code. So, these edges that cannot be resolved at compile time present a problem. Where can I find these devirtualization optimizations that you mentioned? Thanks. -Apala On 01/01/2013 12:18 PM, Tim Northover wrote: > > Hi, > > > For example: call void %1608(%"struct.LRT::RGBAucharFrameBuffer"* > > %1604)

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

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 >>

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

Hello R users, I have a little problem with a for loop. Below there is an simple example of my problem. I want to delet the commas in the character string. Fore this reason I create a for loop to unpick the string and rebuild him without the commas. The problem is, that "paste" does not work in the loop as I expected. text <- "aaa,bbb,ccc,ddd" characterseq <-

Hi, PR17975 was caused by r191059 which was reverted on the 3.4 branch in r196521. However, the problem still occurs with trunk (confirmed as of r206186). >From a thread on cfe-commits I see that Kai Nacke (the author of r191059) was working on a patch to fix PR17975, but the conversation ends: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131202/197968.html So my question

On Feb 19, 2013, at 7:46 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 2/19/2013 12:31 AM, Bill Wendling wrote: >> >> Yeah, that was in the one that I committed. I basically want something like this: >> >> define void @foo() "no-builtin" { >> call void @printf() >> } >> >> And then the `call' to

Dear rsync people, Today I tried to back up my computer using rsnapshot with the RPM version of rsync-acl 2.6.9pre1 that I built. I tried twice, and both times, rsync encountered some kind of assertion failure. I was trying to reproduce the crash with rsync-acl 2.6.9pre2 and noticed a different bug (described below); when I have a chance, I will go back and investigate the crash further. Rsync

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 =

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

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,

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>:

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 = TheExecutionEngine->getPointerToFunction( func ); Then I need to conver this void pointer to the corresponding C function pointer type, and then call the function

On Mon, Dec 3, 2012 at 9:21 AM, David Tweed <david.tweed at arm.com> wrote: > -----Original Message----- > From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On > Behalf Of David Blaikie > Sent: 03 December 2012 16:41 > To: Renato Golin > Cc: LLVM Developers Mailing List; cfe-dev > Subject: Re: [cfe-dev] [LLVMdev] RFC: Change tests to run with

Regarding the orderfile, yes, I was thinking more about ordering the real functions. In that case it sounds like your best option may be to implement the optimization pass to make direct calls go directly to the real function. >From a performance perspective I don't think it would make much difference if there are unused jump table entries. Peter On Thu, Apr 19, 2018 at 6:09 PM, via

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

Hi all, I have a question about dereferenceable metadata on load instruction. I have a patch (https://reviews.llvm.org/D31539) for LICM that hoists loads with !invariant.group. The motivation example is devirtualization: struct A { virtual void foo(); }; int bar(); void indirect(A &a) { while(bar()) a.foo(); } With -O2 -fstrict-vtable-pointers we get: define void

> 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? In fact it is all calls that go through a function pointer type that is used anywhere in the program for an indirect call, but depending on your program that could be very close to "yes".