similar to: RFC: Import of Integer Set Library into LLVM source tree

On 01/15/2018 10:52 AM, Michael Kruse via llvm-dev wrote: > Dear community, > > for our goal to make polyhedral optimization available in the main > LLVM source, we will need the Integer Set Library (isl)[1]. It is the > main dependency of Polly, but would be required even if we do not > directly import Polly. > > I already prepared a patch [2], unfortunately without

On Mon, Jan 15, 2018, at 22:10, Philip Pfaffe via llvm-dev wrote: > Hi Micheal, > > thanks for moving this forward! > > 2018-01-15 17:52 GMT+01:00 Michael Kruse via llvm-dev < > llvm-dev at lists.llvm.org>: > > > Dear community, > > > > for our goal to make polyhedral optimization available in the main > > LLVM source, we will need the Integer

Hi Micheal, thanks for moving this forward! 2018-01-15 17:52 GMT+01:00 Michael Kruse via llvm-dev < llvm-dev at lists.llvm.org>: > Dear community, > > for our goal to make polyhedral optimization available in the main > LLVM source, we will need the Integer Set Library (isl)[1]. It is the > main dependency of Polly, but would be required even if we do not > directly

On Tue, Jan 16, 2018, at 08:53, Tobias Grosser via llvm-dev wrote: > On Mon, Jan 15, 2018, at 22:10, Philip Pfaffe via llvm-dev wrote: > > Hi Micheal, > > > > thanks for moving this forward! > > > > 2018-01-15 17:52 GMT+01:00 Michael Kruse via llvm-dev < > > llvm-dev at lists.llvm.org>: > > > > > Dear community, > > > >

On 01/16/2018 01:59 AM, Tobias Grosser via llvm-dev wrote: > On Tue, Jan 16, 2018, at 08:53, Tobias Grosser via llvm-dev wrote: >> On Mon, Jan 15, 2018, at 22:10, Philip Pfaffe via llvm-dev wrote: >>> Hi Micheal, >>> >>> thanks for moving this forward! >>> >>> 2018-01-15 17:52 GMT+01:00 Michael Kruse via llvm-dev < >>> llvm-dev at

On 01/15/2018 08:52 AM, Michael Kruse via llvm-dev wrote: > Dear community, > > for our goal to make polyhedral optimization available in the main > LLVM source, we will need the Integer Set Library (isl)[1]. It is the > main dependency of Polly, but would be required even if we do not > directly import Polly. > > I already prepared a patch [2], unfortunately without

On Mon, Jan 15, 2018 at 05:52:02PM +0100, Michael Kruse via llvm-dev wrote: > * The library is named LLVMISL and contained in the lib/ISL folder to > work best with LLVM's component system. The component's name "ISL" was > chosen over "isl" as it matches the capitalization of other > two/three-letter-acronym components. Are the ISL sources themselve put

> On Jan 15, 2018, at 8:52 AM, Michael Kruse via llvm-dev <llvm-dev at lists.llvm.org> wrote: > As for the main motivation on why to import the entire source of isl at all: > Polly interacts relative tightly with isl which provide the main > optimization algorithms. For instance, Polly's regression tests > compare the string output of set representation, which

On Wed, Jan 17, 2018, at 07:22, Chris Lattner via llvm-dev wrote: > > On Jan 15, 2018, at 8:52 AM, Michael Kruse via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > As for the main motivation on why to import the entire source of isl at all: > > Polly interacts relative tightly with isl which provide the main > > optimization algorithms. For instance, Polly's

Hi Rick, Tobi, now that we have a way to link polly statically into the tools, we can turn on the windows polly build-bot. Let's speak about the config that the bot will run: ISL only (no CLooG), imath as a replacement for GMP, and cmake to configure llvm. The compiler will be MSVC 2013: we have verified that the current ISL version with the two patches that I sent out for ISL are compiling

Hi Tobi, I'm familiar with Zorg, but sometimes people have plans for existing bots I might not be aware of. Are there specific bots for linux/windows I should add this to, or should I leave the existing polly bots alone and create one or two new ones? Of course, Any change would be backward compatible to all other users of the builder. The plan would be have linux and windows cmake

On Tue, Sep 26, 2017 at 2:00 AM, Tobias Grosser via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Tue, Sep 26, 2017, at 00:03, Johannes Doerfert wrote: >> It depends on what you want. If you want a polyhedral scheduler right >> away, integration is the way to go. I think this is the topic of the thread as the folks who started this discussion stated that they want to see

2018-01-18 6:40 GMT+01:00 Chris Lattner <clattner at nondot.org>: > Great, I think that that would be a fine approach: you can have the cmake logic detect which version of isl is installed and fail if it is the wrong version. This would address my concern. > The motivation explained in the original email seemed to hinge around the fact that Polly’s unit tests depend on accidental

Am Mi., 1. Juli 2020 um 05:46 Uhr schrieb MyDeveloper Day via llvm-dev <llvm-dev at lists.llvm.org>: > I always knew "polly" was mostly clean too, and actually one of the areas I already test against, (along with lib/Format obviously). You have no other choice. Polly verifies its source formatting as part of check-polly, so every commit that violates formatting will get an

On Tue, Sep 26, 2017, at 00:03, Johannes Doerfert wrote: > Hi Hal, > > On 09/22, Hal Finkel wrote: > > Hi, Johannes, > > > > Thanks for writing this. I certainly think you have the right idea in terms > > of the desired end state and modular design. > > Thanks for the feedback! > > > > On 09/19/2017 07:33 PM, Johannes Doerfert wrote: >

On Tue, 2012-02-07 at 00:47 +0100, Tobias Grosser wrote: > On 02/06/2012 11:28 PM, Chris Lattner wrote: > > On Feb 6, 2012, at 1:56 PM, Hal Finkel wrote: > >>> If you do not want to use polly, you could use ISL > >>> http://freecode.com/projects/isl to set up the dependence problem and > >>> use ISL's ILP to solve it. > >> > >> isl

On Feb 6, 2012, at 1:56 PM, Hal Finkel wrote: >> If you do not want to use polly, you could use ISL >> http://freecode.com/projects/isl to set up the dependence problem and >> use ISL's ILP to solve it. > > isl is an LGPL project. It is not clear to me what the general consensus > would be on having a core analysis pass carry an LGPL dependency. This is fine for

Hi Tobi, when polly is configured with isl and without cloog, make polly-test does not pass cleanly as there are several testcases that use a pass flag that does not exist in this configuration: -polly-cloog. I was thinking to address this problem by renaming -polly-cloog and -polly-codegen-isl to -polly-codegen and making all these tests using -polly-codegen. Another option is to disable these

Hi Tobi, Sebastian Pop wrote: > Sebastian Pop wrote: > > Another option is to disable these tests when cloog is not available, and to > > write other tests that will work with -polly-codegen-isl. > > I think I like this way better. The attached patches move all the test > dependent on Cloog to be conditionally executed to CLOOG_FOUND. I am preparing > another patch

On 02/06/2012 11:28 PM, Chris Lattner wrote: > On Feb 6, 2012, at 1:56 PM, Hal Finkel wrote: >>> If you do not want to use polly, you could use ISL >>> http://freecode.com/projects/isl to set up the dependence problem and >>> use ISL's ILP to solve it. >> >> isl is an LGPL project. It is not clear to me what the general consensus >> would be on