search for: jirislaby

Hello, we, at the Masaryk University, have developed an interprocedural static slicer with other useful stuff. This includes Andersen's points-to analysis, accurate call-graph, modifies relations. The whole code is available in this repository: https://github.com/jirislaby/LLVMSlicer The question I would like to ask is, would you accept this library into the core LLVM if we send patches or is it too off for LLVM's purposes? If the latter is the case, would it be possible to create a page at llvm dot org with stuff like this? thanks, -- js

To avoid a wrong compiler warning, use unitialized_var(cx) in xen_init_cpuid_mask. cx needn't be initialized for cpuid when ax is 1. Signed-off-by: Jiri Slaby <jirislaby at gmail.com> Cc: Jeremy Fitzhardinge <jeremy at xensource.com> Cc: Chris Wright <chrisw at sous-sol.org> --- arch/x86/xen/enlighten.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index e90540a..5ab75e2...

To avoid a wrong compiler warning, use unitialized_var(cx) in xen_init_cpuid_mask. cx needn't be initialized for cpuid when ax is 1. Signed-off-by: Jiri Slaby <jirislaby at gmail.com> Cc: Jeremy Fitzhardinge <jeremy at xensource.com> Cc: Chris Wright <chrisw at sous-sol.org> --- arch/x86/xen/enlighten.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index e90540a..5ab75e2...

To avoid a wrong compiler warning, use unitialized_var(cx) in xen_init_cpuid_mask. cx needn't be initialized for cpuid when ax is 1. Signed-off-by: Jiri Slaby <jirislaby at gmail.com> Cc: Jeremy Fitzhardinge <jeremy at xensource.com> Cc: Chris Wright <chrisw at sous-sol.org> --- arch/x86/xen/enlighten.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index e90540a..5ab75e2...

Hi js, On Feb 13, 2012, at 8:49 AM, Jiri Slaby <jirislaby at gmail.com> wrote: > Hello, > > we, at the Masaryk University, have developed an interprocedural static > slicer with other useful stuff. This includes Andersen's points-to > analysis, accurate call-graph, modifies relations. > > The whole code is available in this...

From: Jiri Slaby (SUSE) <jirislaby at kernel.org> [ Upstream commit 3638a820c5c3b52f327cebb174fd4274bee08aa7 ] gcc-13 warns about mismatching types for enums. That revealed switched arguments of nv50_wndw_new_(): drivers/gpu/drm/nouveau/dispnv50/wndw.c:696:1: error: conflicting types for 'nv50_wndw_new_' due to enum/i...

From: Jiri Slaby (SUSE) <jirislaby at kernel.org> [ Upstream commit 3638a820c5c3b52f327cebb174fd4274bee08aa7 ] gcc-13 warns about mismatching types for enums. That revealed switched arguments of nv50_wndw_new_(): drivers/gpu/drm/nouveau/dispnv50/wndw.c:696:1: error: conflicting types for 'nv50_wndw_new_' due to enum/i...

From: Jiri Slaby (SUSE) <jirislaby at kernel.org> [ Upstream commit 3638a820c5c3b52f327cebb174fd4274bee08aa7 ] gcc-13 warns about mismatching types for enums. That revealed switched arguments of nv50_wndw_new_(): drivers/gpu/drm/nouveau/dispnv50/wndw.c:696:1: error: conflicting types for 'nv50_wndw_new_' due to enum/i...

From: Jiri Slaby (SUSE) <jirislaby at kernel.org> [ Upstream commit 3638a820c5c3b52f327cebb174fd4274bee08aa7 ] gcc-13 warns about mismatching types for enums. That revealed switched arguments of nv50_wndw_new_(): drivers/gpu/drm/nouveau/dispnv50/wndw.c:696:1: error: conflicting types for 'nv50_wndw_new_' due to enum/i...

...compiler warnings (Sam) - Fix typo in comment (Jiri) - add a todo entry for the cleanup (Thomas) Reviewed-by: Thomas Zimmermann <tzimmermann at suse.de> Reviewed-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org> Acked-by: Sam Ravnborg <sam at ravnborg.org> Cc: Jiri Slaby <jirislaby at kernel.org> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie at samsung.com> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org> Cc: Linus Torvalds <torvalds at linux-foundation.org> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org Cc: Tomi Val...

On Di, 2016-11-08 at 22:37 +0200, Michael S. Tsirkin wrote: > On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: > > Hi, > > > > I can relatively easily reproduce this bug: How? > > BUG: 'list_empty(&vgdev->free_vbufs)' is true! > The following might be helpful for debugging - if kernel still will > not stop panicing, we are looking at

On Di, 2016-11-08 at 22:37 +0200, Michael S. Tsirkin wrote: > On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: > > Hi, > > > > I can relatively easily reproduce this bug: How? > > BUG: 'list_empty(&vgdev->free_vbufs)' is true! > The following might be helpful for debugging - if kernel still will > not stop panicing, we are looking at

...the cleanup (Thomas) > > v3: Remove more unused variables (0day) > > Reviewed-by: Thomas Zimmermann <tzimmermann at suse.de> > Reviewed-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org> > Acked-by: Sam Ravnborg <sam at ravnborg.org> > Cc: Jiri Slaby <jirislaby at kernel.org> > Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie at samsung.com> > Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org> > Cc: Linus Torvalds <torvalds at linux-foundation.org> > Cc: Ben Skeggs <bskeggs at redhat.com> > Cc: nouveau at lists.fre...

...ic_crtc_needs_modeset() (Daniel). > > > > Cc: 1882851 at bugs.launchpad.net > > Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change") > > Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> > > Tested-by: Jiri Slaby <jirislaby at kernel.org> Ping. Need an ack or an review to merge this. thanks, Gerd

...h an older version of LLVM and probably needs some > TLC. It also only backtracks until it hits a load; additional code must > be written to backtrack further to find potentially reaching stores. > > The second option is to use some code written by Jiri Slaby at > https://github.com/jirislaby/LLVMSlicer. I believe his implementation > is a complete static backwards slicer, but I haven't used it myself, so > I don't know it's quality or what version of LLVM it uses. > > I think someone at UW-Madison may have an implementation as well; I'll > contact that p...

...he Giri code runs with an older version of LLVM and probably needs some TLC. It also only backtracks until it hits a load; additional code must be written to backtrack further to find potentially reaching stores. The second option is to use some code written by Jiri Slaby at https://github.com/jirislaby/LLVMSlicer. I believe his implementation is a complete static backwards slicer, but I haven't used it myself, so I don't know it's quality or what version of LLVM it uses. I think someone at UW-Madison may have an implementation as well; I'll contact that person and see. -- Jo...

...more confident to work on it. Last, in FindFlow.h:67, is the code correct? I suppose it should be: > - std::vector<const Function *>::iterator FE = Targets.begin(); > --- > + std::vector<const Function *>::iterator FE = Targets.end(); Regards. L [1] https://github.com/jirislaby On Mon, Nov 19, 2012 at 1:46 PM, Mingliang LIU <liuml07 at gmail.com> wrote: > John, > > Thanks for your quick reply. > > Firstly, I'd like to employ a slicer for our benchmarking work (in one > word, reducing the long-time irrelevant computing). I find the giri proje...

Hello, I am curious to know if LLVM offers any passes to do interprocedural slicing, I need to eliminate most of the computations(possibly all, if they don't influence the control flow), but the control flow of the program should be maintained at all cost. I did see an optimization pass to print the CFG of a function without its body to a dot file, but I am interested in generating the

On 02/14/2012 07:26 AM, Evan Cheng wrote: > Hi js, > > On Feb 13, 2012, at 8:49 AM, Jiri Slaby <jirislaby at gmail.com> wrote: > >> Hello, >> >> we, at the Masaryk University, have developed an interprocedural static >> slicer with other useful stuff. This includes Andersen's points-to >> analysis, accurate call-graph, modifies relations. >> >> The w...

...t;> I can relatively easily reproduce this bug: > > > > How? > > Run dmesg -w in the qemu window (virtio_gpu) to see a lot of output. > Run pps [1] without exit(0); on e.g. serial console. > Wait a bit. The lot of output causes the BUG. > > [1] https://github.com/jirislaby/collected_sources/blob/master/pps.c Doesn't reproduce here. Running "while true; do dmesg; done" on the virtio-gpu fbcon. Running the pps fork bomb on the serial console. Can watch dmesg printing the kernel messages over and over, until the shell can't spawn dmesg any more due...