This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: vectorizer cost model
- From: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: "Linthicum, Tony" <tony dot linthicum at amd dot com>, gcc at gcc dot gnu dot org, Dorit Nuzman <DORIT at il dot ibm dot com>
- Date: Fri, 16 Feb 2007 19:35:44 +0100
- Subject: Re: RFC: vectorizer cost model
- References: <m3hctmdl6c.fsf@localhost.localdomain>
Hello,
> "Linthicum, Tony" <tony.linthicum@amd.com> writes:
>
> > * Would using a tree-level API like estimate_num_insns be superior
> > to using a simple cost of 1 per statment?
>
> For this sort of calculation, I would guess not. I would imagine that
> on most processors the cost of a single vector instruction is
> comparable to the cost of the same operation on scalar operands. So
> simply counting instructions should give you a good indication of
> whether vectorization is profitable, even though each instruction will
> of course have a different cost.
>
> If this turns out not to be the case, then I think the next step would
> be to have a target defined multiplier for vector instructions,
> indicating that for that target vector instructions were more or less
> expensive than scalar instructions according to some ratio.
>
> I doubt that using the full fledged cost infrastructure would give you
> better results than that in practice.
on the other hand, using it does not cost you anything, and would avoid
risk of creating yet another code duplication.
> > * What is the best way to access target level cost information?
>
> I'm sure you know that the loop code does this by generating RTL and
> asking for the cost of it (computation_cost in tree-ssa-loop-ivopts.c).
Which should be removed (I have some patches for that, but I somehow
forgot on them because of other issues).
Zdenek