"Richard Guenther" <richard.guenther@gmail.com> wrote on 25/01/2007
18:02:59:
> On 1/25/07, Dorit Nuzman <DORIT@il.ibm.com> wrote:
> > which goes back to the point I was trying to make above - vectorizing
> > function calls (that happen to do a conversion) should be handled by
> > vectorizable_call. vectorizable_conversion will handle only tree-code
that
> > do conversions. What do you say?
>
> Hmm, but then if there is no special support for lhs_type !=
> rhs_type necessary
> then why call it vectorize_intfloat_conversion and not provide generic
> target_vectorize_unop and target_vectorize_binop target hooks (or only
one)?
>
it's a good point actually - it may be that vectorizable_conversion has
more in common with vectorizable_operation than it may have seemed at
first. The general idea was that all vectorizable_* functions (at least
those that deal with tree-codes) handle the same type coming in as the type
coming out, expect for vectorizable_demotion, vectorizable_promotion, and
vectorizable_conversion, which are the only places where you need to worry
about different types. But it may not be a bad idea to distribute things
differently, like you suggest. Anyhow, lets put in this functionality first
as is, and then see how best (if at all) to reorganize things...
> If it is indeed special because it's a conversion then it should also
handle
> the case of converting function calls
I was thinking there's more in common to handling different function calls
than between handling (conversion) tree-codes and (conversion) function
calls. But, the more I think about it the less I'm sure of it... Also, I
think that once we add the conversion between different sizes, it will be
clearer how we want to organize things. Anyhow, like I said before, I think
there's a lot in common to a lot of the vectorizable_* functions, and maybe
even room to consider a single template, so when I get to doing that it
will also sort out this issue...