similar to: [LLVMdev] Problem with building Polly with PoCC

ether wrote: >> The polyhedral loop description is simple and not compiler depended. >> Therefore external tools like LooPo (automatic parallelization), Pluto >> (optimization in general) > i had contacted the author a week ago, and if we use it, we need a IR > generator in llvm side to extract SCoP, and the corresponding parser in > Pluto side that read, then a

How to feed pocc by jscop files which are made with -polly-export-jscop? 2011/4/8 ether zhhb <etherzhhb at gmail.com>: > Hi, > > 2011/4/8 Vlad Krylov <krvladislav at gmail.com>: >> Hi. >> >> I see that to detect scops firstly we search for regions in CFG ( by >> RegionInfo ) and then select regions that answer some requirements ( >> in

On Mon, Dec 28, 2009 at 05:05, Albert Cohen <Albert.Cohen at inria.fr> wrote: > PCP is only partially implemented: conversion out of PCP to Graphite is not > implemented, Actually Gimple to PCP to Graphite is implemented in some extent, but there still are plenty of bugs and we should work on the out of Graphite to PCP to Gimple/LLVM if we want to get rid of all these bugs. Also the

hi Tobi , that sounds greate :D On 2009-12-27 5:43, Tobias Grosser wrote: > I already looked into implementing something like Graphite for LLVM. > However just recently, so I have not released any code yet. As soon as > some code is available I will post patches. whats its status? do you need any help? > A general plan to implement polyhedral transformations in LLVM: > > 1.

On 04/26/2013 05:08 AM, tanmx_star wrote: > Hi all, Hi, thanks for the update and sorry for the delay in reviewing. I just had a look at your proposal. > I have updated my GSoS proposal: "FastPolly: Reducing LLVM-Polly Compiling overhead" (https://gist.github.com/tanstar/5441808). I think the pass ordering problem you discussed early can be also investigated in this project!

Tobias Grosser wrote: > The way to go is the scoplib format (propably extended by quantified > variables). This format could be extracted from graphite easily and > could also be created in LLVM. > What we need to get back into LLVM is only the new optimized schedule > described e.g. as cloog like scattering functions. These can be parsed > easily. The real code generation

On 12/27/09 10:18, ether wrote: > hi Tobi , > > that sounds greate :D > > On 2009-12-27 5:43, Tobias Grosser wrote: >> I already looked into implementing something like Graphite for LLVM. >> However just recently, so I have not released any code yet. As soon as >> some code is available I will post patches. > whats its status? do you need any help? Very

Hi ether, On 12/26/09 13:06, ether zhhb wrote: > hi, > > dose anyone going/planning to add something like > Graphite(http://gcc.gnu.org/wiki/Graphite) in gcc to llvm(or that > should be implement at the level of clang?)? I already looked into implementing something like Graphite for LLVM. However just recently, so I have not released any code yet. As soon as some code is

Hello I need help on a fedora release 11 (Leonidas) when I start the dovecot process I get an error : Jun 17 10:15:24 aragon dovecot: Dovecot v1.2.rc3 starting up (core dumps disabled) Jun 17 10:15:24 aragon dovecot: Fatal: auth(default): Support not compiled in for passdb driver 'ldap' Jun 17 10:15:24 aragon dovecot: Fatal: Auth process died too early - shutting down I installed

Hi all, I have updated my GSoS proposal: "FastPolly: Reducing LLVM-Polly Compiling overhead" (https://gist.github.com/tanstar/5441808). I think the pass ordering problem you discussed early can be also investigated in this project! Is there any comment or advice about my proposal? I appreciate all your help and advice. Thanks, Star Tan Proposal:

This reorganizes virtio-pci code in vp_interrupt slightly, so that it's easier to add per-vq MSI support on top. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_pci.c | 45 +++++++++++++++++++++++++++++++++--------- 1 files changed, 35 insertions(+), 10 deletions(-) diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c index

This reorganizes virtio-pci code in vp_interrupt slightly, so that it's easier to add per-vq MSI support on top. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_pci.c | 45 +++++++++++++++++++++++++++++++++--------- 1 files changed, 35 insertions(+), 10 deletions(-) diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c index

This reorganizes virtio-pci code in vp_interrupt slightly, so that it's easier to add per-vq MSI support on top. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_pci.c | 53 +++++++++++++++++++++++++++--------------- 1 files changed, 34 insertions(+), 19 deletions(-) diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c index

This reorganizes virtio-pci code in vp_interrupt slightly, so that it's easier to add per-vq MSI support on top. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_pci.c | 53 +++++++++++++++++++++++++++--------------- 1 files changed, 34 insertions(+), 19 deletions(-) diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c index

This reorganizes virtio-pci code in vp_interrupt slightly, so that it's easier to add per-vq MSI support on top. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_pci.c | 53 +++++++++++++++++++++++++++--------------- 1 files changed, 34 insertions(+), 19 deletions(-) diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c index

This reorganizes virtio-pci code in vp_interrupt slightly, so that it's easier to add per-vq MSI support on top. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_pci.c | 53 +++++++++++++++++++++++++++--------------- 1 files changed, 34 insertions(+), 19 deletions(-) diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c index

Hi, 2011/4/8 Vlad Krylov <krvladislav at gmail.com>: > Hi. > > I see that to detect scops firstly we search for regions in CFG ( by > RegionInfo ) and then select regions that answer some requirements ( > in ScopDetection ). Because only affine expressions in conditions and > bounds are permissible, we trying to get scalar expressions into > affine form by

pci_enable_msix currently returns -EINVAL if you ask for more vectors than supported by the device, which would typically cause fallback to regular interrupts. It's better to return the table size, making the driver retry MSI-X with less vectors. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Hi Jesse, This came up when I was adding MSI-X support to virtio pci driver, which

pci_enable_msix currently returns -EINVAL if you ask for more vectors than supported by the device, which would typically cause fallback to regular interrupts. It's better to return the table size, making the driver retry MSI-X with less vectors. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Hi Jesse, This came up when I was adding MSI-X support to virtio pci driver, which

Hi, all It seems that rev. 131463 [1] makes LLVM failed to recognize ARM correctly. My best guess is the variable LLVM_HOSTTRIPLE got something like "armv7l-unknown-linux-gnueabi" when LLVM compiled natively on ARM. Then the Arch (armv7l) is not recognized by LLVM. As you can see from attach (llvm-131463-gcc-4.4.1-native-arm2.log), there are a lot failure while running test cases