[PATCH] [Polly] Update ISL to isl-0.15-3-g532568a

Tobias Grosser tobias at grosser.es
Thu Jun 18 09:07:41 PDT 2015


In http://reviews.llvm.org/D10505#190247, @Meinersbur wrote:

> In http://reviews.llvm.org/D10505#190234, @grosser wrote:
>
> > In http://reviews.llvm.org/D10505#190225, @Meinersbur wrote:
> >
> > > In http://reviews.llvm.org/D10505#190085, @grosser wrote:
> > >
> > > > It seems you somehow changed the format of isl_config.h. When importing isl I just copied this file from an isl_config.h.in. It seems you now use a slightly different approach to obtain the contents of this file which causes changes all over this file.
> > >
> > >
> > > It is the output of ./configure on my machine.
> > >
> > > Using isl_config.h.in straight away is about the least favorable thing you can do. It just defines nothing. I am surprised it worked.
> >
> >
> > The intention was to define as little as possible. My feeling was that isl would not use (or need) most of these macros anyhow, so I wanted to leave them undefined such that it clearly breaks if there arises a need at some point.
>
>
> According to that logic we should use an empty isl_config.h


That may indeed make sense.

> > Using the configure of your machine just means it will work on your machine, but it seems there is a risk that your machine has certain features that are not available on other machines and consequently would break the build there if enabled.

> 

> 

> It at least ensures that the macros are compatible with each other and work for gcc and clang. Using an unconfigured isl_config.h to work on any machine is pure coincidence.


Maybe we have been lucky, right.

> > As said before, I am happy to have this improved (and with your cmake-ificaton of isl you may have some good ideas), but let's not change our approach within a massive update of isl. Those two things are orthogonal.

> 

> 

> Not really. isl_config.h is version-specific. Upgrading ISL logically also required upgrading isl_config.h


Right. I was only concerned that we do this upgrade using the same approach as was used before, as we otherwise get random changes if different people update this file.

As I said, I am happy to have this improved. If you want to do so, feel free to start a discussion.


http://reviews.llvm.org/D10505

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list