similar to: devirtualization with new-PM pipeline

Yes, this looks broken in the new PM. The DevirtSCCRepeatedPass::run method first scans the functions in the SCC to collect value handles for indirect calls, runs the CGSCC pass pipeline and then checks if any of the call value handles now point to a direct call, in which case it runs the pipeline again (which should inline the devirtualized call) . The problem is scanning the initial SCC for

Hello all, Our compilers class has been using LLVM, and a partner and I decided to implement devirtualization of virtual C++ calls in LLVM as a class project. We quickly realized that existing debug metadata generated by Clang didn't give us enough info to (precisely) implement this, and as such have already begun modifying Clang to insert such metadata. However, for devirtualization we also

Hello Fedor. Thank you for the information. I made a simple patch that exposes PassInstrumentationCallback so llvmGetPassPluginInfo can use it: https://reviews.llvm.org/D71086 . Would this change make sense? Thanks, Juneyoung Lee On Thu, Dec 12, 2019 at 12:44 AM Fedor Sergeev <fedor.sergeev at azul.com> wrote: > > > On 12/3/19 8:01 PM, Juneyoung Lee via llvm-dev wrote: > >

On Mon, Oct 11, 2010 at 11:10 PM, John McCall <rjmccall at apple.com> wrote: > On Oct 11, 2010, at 2:01 PM, Kenneth Uildriks wrote: >> A better way for a front-end to declare that vtbl-ptr-hacking is not >> expected and not supported is for it to emit llvm.invariant.start and >> llvm.invariant.end calls for it. > > Some of us were talking about this apropos your

Hi David: >> How do you deal with basic blocks which appear to be used by multiple parts >> of the coroutine? We handled this in WinEHPrepare by cloning any BBs which >> were shared. I experimented with several approaches, but, cloning ended up being the simplest and most reliable. Suspend points express three different control flows that can happen at the suspend point: a

Hello all, Is there a way to register callback that runs before/after passes? PassTimingInfo seems to do a similar thing by calling PassInstrumentationCallbacks::registerBeforePassCallback / registerAfterPassCallback, but it is hard-wired with StandardInstrumentations class. Do we have something similar to RegisterStandardPasses, so custom callbacks can be added from somewhere outside LLVM?

I have two physical servers: Virt1 and Virt2. I'm setting up live migration with CentOS 5.5 between the two. I've done this by NFS mounting /etc/libvirt and /var/lib/libvirt/images on both servers. This is working well for me except for one thing. I see the same list of VMs on each server (as expected), but each server (Virt1 and Virt2) are able to start the same VM at the same time.

On Dec 10, 2011, at 12:26 PM, Nick Lewycky wrote: > John McCall wrote: >> On Dec 8, 2011, at 10:03 PM, Nick Lewycky wrote: >>> Noalias returns, nocapture, SCC refinement, linkonce_odr and >>> available_externally were added with the goal of making devirtualization >>> in LLVM happen, but as orthogonal independent optimizations. I think >>> LLVM should

I have install and configure on two server centos8 glusterfs in replica mode in this manner: dnf install centos-release-gluster -y dnf install glusterfs-server glusterfs glusterfs-fuse -y systemctl enable --now glusterd gluster peer probe virt1 gluster peer status sh creavolume.sh gfsvol1 301G /gfsvol1 xfs # NOTE: this is a my shell script to create fs on lvm mkdir

On Wed, Oct 13, 2010 at 12:45 AM, Nick Lewycky <nicholas at mxc.ca> wrote: > Kenneth Uildriks wrote: >>> >>> You're right, I hadn't thought this through. The whole point of making >>> them >>> local is to say that "I'm sure these callees won't modify that memory" >>> regardless of what functions actually get called,

hello list I have a network mounted home directory shared between all hosts on my network: [bluethundr at LCENT03:~]#df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/VolGroup00-LogVol00 140G 4.4G 128G 4% / /dev/sda1 99M 35M 60M 37% /boot tmpfs 1.6G 0 1.6G 0% /dev/shm nas.summitnjhome.com:/mnt/nas

On 12 October 2010 05:00, Kenneth Uildriks <kennethuil at gmail.com> wrote: > On Mon, Oct 11, 2010 at 11:10 PM, John McCall <rjmccall at apple.com> wrote: > > On Oct 11, 2010, at 2:01 PM, Kenneth Uildriks wrote: > >> A better way for a front-end to declare that vtbl-ptr-hacking is not > >> expected and not supported is for it to emit llvm.invariant.start and

On 11 December 2011 03:18, John McCall <rjmccall at apple.com> wrote: > On Dec 10, 2011, at 12:26 PM, Nick Lewycky wrote: >> John McCall wrote: >>> On Dec 8, 2011, at 10:03 PM, Nick Lewycky wrote: >>>> Noalias returns, nocapture, SCC refinement, linkonce_odr and >>>> available_externally were added with the goal of making devirtualization

In an effort to get a better understanding of Crossbow I decided to create some vnics for use between a couple of Solarsi 10 branded zones. I was quite surprised that when I went to verify the setup within zonecfg I got the following error. zonecfg:virt1> verify Error: solaris10 zones do not currently support exclusive ip-type stacks virt1: Brand-specific error Is this a feature that is

> You're right, I hadn't thought this through. The whole point of making them > local is to say that "I'm sure these callees won't modify that memory" > regardless of what functions actually get called, even indirectly. We can't > know that they won't modify the vptr in advance, so invariant doesn't work > here. Making it non-local just means

Vitor Luis Menezes wrote: > Hello all, > > Our compilers class has been using LLVM, and a partner and I decided to > implement devirtualization of virtual C++ calls in LLVM as a class > project. We quickly realized that existing debug metadata generated by > Clang didn't give us enough info to (precisely) implement this, and as > such have already begun modifying Clang to

On Oct 13, 2010, at 4:35 AM, Kenneth Uildriks wrote: > On Wed, Oct 13, 2010 at 12:45 AM, Nick Lewycky <nicholas at mxc.ca> wrote: >> Kenneth Uildriks wrote: >>>> >>>> You're right, I hadn't thought this through. The whole point of making >>>> them >>>> local is to say that "I'm sure these callees won't modify

Kenneth Uildriks wrote: > On Wed, Oct 13, 2010 at 12:45 AM, Nick Lewycky<nicholas at mxc.ca> wrote: >> Kenneth Uildriks wrote: >>>> >>>> You're right, I hadn't thought this through. The whole point of making >>>> them >>>> local is to say that "I'm sure these callees won't modify that memory" >>>>

On Thu, Dec 8, 2011 at 9:56 AM, Vitor Luis Menezes <vitor at utexas.edu> wrote: > Hello all, > > Our compilers class has been using LLVM, and a partner and I decided to > implement devirtualization of virtual C++ calls in LLVM as a class project. > We quickly realized that existing debug metadata generated by Clang didn't > give us enough info to (precisely) implement

Kenneth Uildriks wrote: >> You're right, I hadn't thought this through. The whole point of making them >> local is to say that "I'm sure these callees won't modify that memory" >> regardless of what functions actually get called, even indirectly. We can't >> know that they won't modify the vptr in advance, so invariant doesn't work