Re: Auto-Vectorization, Polyhedral Model
Hi, Auto-Vectorization is still implemented in the 'old'- non polyhedral way. Polyhedral model can only help drive the vectorization strategies. What is happening is that Graphite (polyhedral model framework inside GCC) is setting the flag on the loop that it thinks should be vectorized. Later, the vectorizer pass is performing the vectorization - by rewritting scalar instructions into vector instructions. Please have a look at the paper "Polyhedral-Model Guided Loop-Nest Auto-Vectorization". Konrad 2011/11/15 steven su : > Hi, > Can anyone explain whether GCC has implemented Auto-Vectorization > based on Polyhedral Model? > Are there any related projects shooting at this, and in progress? > > Steven. >
Re: [graphite] Loop tiling
Hi, some short note on coupling loop tiling and gloog code generator. I will need to extend mapping of old induction variables <-> new induction variables. Until now I assume preserved one-to-one relationship. But, this does not allow many of the loop transformations (like loop inversion). I will implement an mechanism to express old induction variable as the function (gimple expression) of new induction variables. Ideally it should handle functional relationship of any complexity. I also think this is necessary to enable code generation for tiled loops. Let me work on this ;) regards, Konrad 2008/6/11 Cédric Bastoul <[EMAIL PROTECTED]>: > I started to write the following message two days ago but I wished to > send a .cloog which is not easy since I changed my laptop just before > the trip I'm still on ! I need to finish installing all the tools... > Here is the message, just a follow-up of Albert's one. > > Ced. > > --- > Hi Tobi, > Sebastian gave you the right pointers, you should also have a look at > examples in the CLooG test directory called tilingX.cloog. However to > be honest I'm not fond of the second solution you suggested. The > reason is the scattering is supposed to only drive the way the > polyhedra are scanned. Adding new dimensions there is against this > (well, I designed scattering this way -allowing inequalities- because > I wished to do that, but I changed my mind and now I think it's > dirty...). The right solution to me is acting both on the domain and > in the scattering (in the end, something similar to your second > solution). > > By the way we are incorporating directly inside CLooG the tiling > scheme described there > http://www.cs.colostate.edu/~ln/publications/pldi07.pdf (a student is > working on this at this moment). > --- > > On Mon, Jun 9, 2008 at 7:25 PM, Sebastian Pop <[EMAIL PROTECTED]> wrote: >> Hi Tobi, >> >> Thanks for working on this. >> >> Solution 2 is the right one. >> >> On Mon, Jun 9, 2008 at 11:58 AM, Tobias Grosser >> <[EMAIL PROTECTED]> wrote: >>> 1. It is not very efficient. As we have many multiplications in the >>> code. >>> Will later gcc optimization passes convert these multiplications to >>> additions? >>> >> >> Yes, you should not worry about scalar optimizations at all. >> >>> 2. I could not find any documentation about scattering functions, that >>> describe this way of using the scattering functions. >>> >> >> I think that the best place to look at this is: >> page 4 of http://www.lri.fr/~girbal/publi/ics05_facilitating.ps >> >> also have a look at the other reports from: >> http://www.lri.fr/~girbal/site_wrapit/ >> >> Albert probably has some other pointers for reports that describe how >> to do loop tiling. >> >>> Another graphite specific problem is, how we connect the real loop >>> variables to the cloog variables. Before loop tiling this was easy. >>> Loops of the same depth in the cloog output correspond to the loops of >>> the same depth in the original gimple loop nest. But know we have to add >>> some data structure, that connects the gimple loops, with the cloog >>> loops. >>> >> >> This was also the case before: we needed a map between the old >> induction variable and the new ones. >> >> Sebastian Pop >> -- >> AMD - GNU Tools >> >
Re: vectorization, -floop-strip-mine, -floop-block and -floop-interchange
hi, they should work completely independently from vectorization. It does not matter if vectorizaton is already run or not, they will apply if You enable them by flags. konrad From: Jack Howarth <[EMAIL PROTECTED]> To: Dorit Nuzman/Haifa/[EMAIL PROTECTED] Cc: gcc@gcc.gnu.org, Konrad Trifunovic/Haifa/Contr/[EMAIL PROTECTED] Date: 13/08/2008 17:24 Subject:Re: vectorization, -floop-strip-mine, -floop-block and -floop-interchange Dorit, So it is correct to say that any loop that is vectorized is removed from consideration for these other loop optimizations? I ask because I am wondering if I should be testing these new loop optimizations at -O2 in order to see their full effect (without vectorization inhibiting their use). Jack On Wed, Aug 13, 2008 at 05:08:53PM +0300, Dorit Nuzman wrote: > >Can anyone explain the relationship between the current vectorization > > optimizations in the gcc trunk compiler and the new -floop-strip-mine, > > -floop-interchange and -floop-block loop optimizations? Which takes > > precedence and does one set block the other in any way? I would hope > > that the new loop optimizations simply redefine the loops that are then > > processed for vectorization so that both sets of optimizations can > > be in effect at the same time. Thanks in advance for any clarifications > > on how these optimizations interact with each other. > > There's currently no interaction between the Graphite optimizations and > vectorization. I don't know what considerations/cost-model Graphite uses > before applying its optimizations, but vectorization is not one of them. We > are now starting to look into teaching Graphite to take into account > factors that affect the applicability and profitability of vectorization, > but this work is in a very initial stage. > > dorit > > > Jack
Re: vectorization, -floop-strip-mine, -floop-block and -floop-interchange
Hi, sorry for my top-posting in last e-mail. > hi, > > they should work completely independently from vectorization. It does not > matter if vectorizaton is already run or not, they will apply > if You enable them by flags. > > konrad > > > Dorit, > So it is correct to say that any loop that is vectorized is > removed from consideration for these other loop optimizations? > I ask because I am wondering if I should be testing these new > loop optimizations at -O2 in order to see their full effect > (without vectorization inhibiting their use). >Jack > > On Wed, Aug 13, 2008 at 05:08:53PM +0300, Dorit Nuzman wrote: >> >Can anyone explain the relationship between the current > vectorization >> > optimizations in the gcc trunk compiler and the new -floop-strip-mine, >> > -floop-interchange and -floop-block loop optimizations? Which takes >> > precedence and does one set block the other in any way? I would hope >> > that the new loop optimizations simply redefine the loops that are then >> > processed for vectorization so that both sets of optimizations can >> > be in effect at the same time. Thanks in advance for any clarifications >> > on how these optimizations interact with each other. >> By looking at passes.c I see that graphite is invoked before vectorizer. This means that first the loop optimizations -floop-interchange etc. will take place and then vectorizer will try to vectorize them. There is no direct interaction between those optimizations. I would be glad to see the results though. >> There's currently no interaction between the Graphite optimizations and >> vectorization. I don't know what considerations/cost-model Graphite uses >> before applying its optimizations, but vectorization is not one of them. > We >> are now starting to look into teaching Graphite to take into account >> factors that affect the applicability and profitability of vectorization, >> but this work is in a very initial stage. >> >> dorit >> >> > Jack > > > > konrad
