Re: PATCH: Loop to builtin call pass (builtinizer)

[Tomas Bily <tbily at suse dot cz>]

Hi,

 I must say that analysis phase is nearly same as vectorizer phase
(building ddr structs, checking loop structure etc.) but builtinizer
is not so strict as vectorizer in some cases. It is at leas 50% of
source code of builtinizer and more on execution time. I agree with
Dorit that if there is plan to add virtual vectors to vectorizer in
future then builinization is sub-case of it and then adding
builtinization to vectorizer is valid.

 Greetings
 Tomas

> Zdenek Dvorak <rakdver@kam.mff.cuni.cz> wrote on 08/07/2007 18:07:06:
> 
> > Hello,
> >
> > > > Hi Dorit,
> > > >
> > > >  I agree that a lot of analyzes in vectorizer and builtinizer are
> same
> > > > or very similar. So, I can try to merge it to vectorizer. I have
> first
> > > > few questions about it:
> >
> > I would somewhat prefer not to merge the passes.  After all, what they
> > do is substantially different, and it does not make much sense to me to
> > complicate vectorizer unnecessarily.
> 
> I'm also generally in favor of having each pass focus on the one task it's
> supposed to do and not combine several tasks into one pass. However in this
> case, given that the analysis part is almost identical, I think it's
> appropriate to at least consider merging this task into the vectorizer and
> have a more concrete idea of how much it really complicates the vectorizer.
> After all, it's exactly like vectorizing, only with a virtual
> (unknown/infinite) sized vector. I think this is a direction in which we
> may want to take the vectorizer sooner or later (though I don't think we
> currently have a way to express "virtual" vectors in GIMPLE, do we?). This
> arises, for example, when vectorizing for targets like CLI (
> http://gcc.gnu.org/projects/cli.html), in which you don't know the concrete
> vector size during vectorization (the JIT compiler would then materialize
> these operations on virtual vectors to operations on the actual vector
> types available in the target machine).
> 
> > Of course, if there is some amount
> > of same/similar code, share the appropriate functions.
> >
> > The reason for merging vectorizer and builtinizer would be if there were
> > some interaction between them, i.e., if doing them at the same time
> > would enable us to optimize the code we cannot optimize now.  Is that
> > the case?  I do not think so -- it seems to me that running builtinizer
> > before vectorizer catches exactly the same amount of optimization
> > opportunities.
> >
> 
> code duplication and compile time are the main motivation here (reminds me
> the comment Steven Bosser made recently on how gcc slows down between
> releases, while we are allowing to incorporate a patch that "adds yet
> another pass over the whole function for some special-case optimization").
> I think this optimization is good, I just think it's so similar to
> vectorization that its worth examining the option of merging it to the
> vectorizer. If it turns out it's too complicated, then we can keep it
> separate for now until such time that we want to extend the vectorizer to
> work with virtual vectors).
> 
> dorit
> 
> > Zdenek