This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Zdenek Dvorak <> wrote on 08/07/2007 18:07:06:

> Hello,
> > > Hi Dorit,
> > >
> > >  I agree that a lot of analyzes in vectorizer and builtinizer are
> > > or very similar. So, I can try to merge it to vectorizer. I have
> > > 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 (, 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).


> Zdenek

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]