similar to: GraphTraits dereferencing

Hi there, I'm currently writing an analysis (for now) pass for LLVM that kind of need some information from the CallGraph of the program. This info would be extremely easy to get if I could build the DominatorTree information about the CallGraph. I even checked out and saw the declarations of GraphTraits templates for CallGraph and CallGraphNode, which might indicate that all algorithms that

Dear testers, 5.0.0-rc3 was just tagged. This is a release candidate in the real sense: if nothing bad comes up in testing, this is what the release is going to look like. Please build, test and upload binaries to the sftp (use the /data/testers-uploads/ directory) and let me know what issues remain. I know we're a little bit behind schedule, but hopefully we can get to 'final'

Commit 0deab087b16a ("vsock/virtio: use RCU to avoid use-after-free on the_virtio_vsock") starts to use RCU to protect 'the_virtio_vsock' pointer, but we forgot to annotate it. This patch adds the annotation to fix the following sparse errors: net/vmw_vsock/virtio_transport.c:73:17: error: incompatible types in comparison expression (different address spaces):

Commit 0deab087b16a ("vsock/virtio: use RCU to avoid use-after-free on the_virtio_vsock") starts to use RCU to protect 'the_virtio_vsock' pointer, but we forgot to annotate it. This patch adds the annotation to fix the following sparse errors: net/vmw_vsock/virtio_transport.c:73:17: error: incompatible types in comparison expression (different address spaces):

RCU trickery: net/vmw_vsock/virtio_transport.c:73:17: error: incompatible types in comparison expression (different address spaces): net/vmw_vsock/virtio_transport.c:73:17: struct virtio_vsock [noderef] __rcu * net/vmw_vsock/virtio_transport.c:73:17: struct virtio_vsock * net/vmw_vsock/virtio_transport.c:171:17: error: incompatible types in comparison expression (different address spaces):

Hi: This series tries to fix various issues of vhost: - Patch 1 adds a missing write barrier between used idx updating and logging. - Patch 2-3 brings back the protection of device IOTLB through vq mutex, this fixes possible use after free in device IOTLB entries. - Patch 4 fixes the diry page logging when device IOTLB is enabled. We should done through GPA instead of GIOVA, this was done

Hi: This series tries to fix various issues of vhost: - Patch 1 adds a missing write barrier between used idx updating and logging. - Patch 2-3 brings back the protection of device IOTLB through vq mutex, this fixes possible use after free in device IOTLB entries. - Patch 4 fixes the diry page logging when device IOTLB is enabled. We should done through GPA instead of GIOVA, this was done

I've run into a use case where I'd like to use a mapped_iterator to iterator the 1st (or 2nd) items in a sequence of std::pairs. Does select1st/select2nd exist somewhere within LLVM or is there some equivalent? If not, I'll add it. -Dave

I found some warnings reported by sparse in the virtio code when I checked virtio-crypto's driver stuff. Let's fix them. Gonglei (2): virtio_pci_modern: fix complaint by sparse virtio_ring: fix complaint by sparse drivers/virtio/virtio_pci_modern.c | 8 ++++---- drivers/virtio/virtio_ring.c | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) -- 1.8.3.1

I found some warnings reported by sparse in the virtio code when I checked virtio-crypto's driver stuff. Let's fix them. Gonglei (2): virtio_pci_modern: fix complaint by sparse virtio_ring: fix complaint by sparse drivers/virtio/virtio_pci_modern.c | 8 ++++---- drivers/virtio/virtio_ring.c | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) -- 1.8.3.1

On 2009-09-06 19:57, Ioannis Nousias wrote: > Edwin, > > thank you for your effort, but I'm not sure I understand. > Are you describing a graph traversal problem? Is the data model stored > in a predecessor/successor fashion, which requires you to 'walk' the > graph in order to visit all nodes? (and what happens when you have > disjointed DFGs?). Sorry for the

Edwin, thanks, it starts making sense inline comments... Török Edwin wrote: > On 2009-09-06 19:57, Ioannis Nousias wrote: > >> Edwin, >> >> thank you for your effort, but I'm not sure I understand. >> Are you describing a graph traversal problem? Is the data model stored >> in a predecessor/successor fashion, which requires you to 'walk' the

Hi all, I have two questions related to .dot graph output. Basically, I have a graph representing a program dependence graph like structure with (a) multiple edges between the same pair of nodes (b) each edge having a special (different) text/label I implemented a template-specialized version of DotGraphTraits for the my graph structure which given a node, uses a map_iterator (similar to the one

On Jul 15, 2011, at 12:35 PM, David Greene wrote: > I've run into a use case where I'd like to use a mapped_iterator to > iterator the 1st (or 2nd) items in a sequence of std::pairs. Does > select1st/select2nd exist somewhere within LLVM or is there some > equivalent? If not, I'll add it. Is this making the resultant loop simpler? C++ without lambda's isn't

Hi, I started to work with llvm and liked the CFG dotty printer a lot. However there was none for the dominance trees. I implemented dotty printing for dominance trees and introduced these new flags: -dot-dom : Print dominance tree of function to 'dot' file -dot-dom-only : Print dominance tree of function to 'dot' file (with no function

CHECK drivers/char/virtio_console.c drivers/char/virtio_console.c:687:36: warning: incorrect type in argument 1 (different address spaces) drivers/char/virtio_console.c:687:36: expected void [noderef] <asn:1>*to drivers/char/virtio_console.c:687:36: got char *out_buf drivers/char/virtio_console.c:790:35: warning: incorrect type in argument 2 (different address spaces)

Tobias Grosser wrote: > On Wed, 2009-07-15 at 00:20 +0200, Tobias Grosser wrote: >> Hi, >> >> I started to work with llvm and liked the CFG dotty printer a lot. >> However there was none for the dominance trees. >> >> I implemented dotty printing for dominance trees Great! I'm a huge fan of graphviz integration in the compiler. > And here is the

CHECK drivers/char/virtio_console.c drivers/char/virtio_console.c:687:36: warning: incorrect type in argument 1 (different address spaces) drivers/char/virtio_console.c:687:36: expected void [noderef] <asn:1>*to drivers/char/virtio_console.c:687:36: got char *out_buf drivers/char/virtio_console.c:790:35: warning: incorrect type in argument 2 (different address spaces)

Hi, I am trying to generate the DFG of machine functions. Initially, I added a pass to generate the DFG of LLVM IR functions. This was based on the mail thread - http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025582.html. This pass worked fine and I was able to generate DFG of LLVM IR functions. Later, I ported the DFG pass code for machine functions. I ported the InstIterator.h

On Wed, 2009-07-15 at 00:20 +0200, Tobias Grosser wrote: > Hi, > > I started to work with llvm and liked the CFG dotty printer a lot. > However there was none for the dominance trees. > > I implemented dotty printing for dominance trees And here is the patch. Tobi -------------- next part -------------- A non-text attachment was scrubbed... Name: