This is the mail archive of the gcc-patches@gcc.gnu.org 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: [power7-meissner, committed] Make vector unsigned builtins type correct


> On Thu, Apr 30, 2009 at 10:25 PM, Michael Meissner
> <meissner@linux.vnet.ibm.com> wrote:
> > I spent some fixing up the builtin functions so that the internal
> tree is type
> > correct, and survives the gimple type checking that was just enabled.
It
> > doesn't fix all of the bugs that type checking has found, but this
patch
> > reduces the vectorization failures by about 20 cases.
> >
> > Because this patch depends on all of the infrastructure I've
> developed for the
> > power7, it will not apply at all to the mainline. ?The power7 stuff is
ready
> > for submission, so I will not be back porting these changes to
themainline,
> > unless it appears it will take awhile to get the total power7
> patches approved
> > (for example if a condition of the slush being lifted is that the power
> > regressions go away).
> >
> > I will be putting a call for other powerpc users to try my branch
> to make sure
> > I haven't broken things in parts of the compiler I don't test on the
gcc
> > mailing list shortly.
>
> I think we should start thinking about not producing too many "standard"
> builtin function calls from the vectorizer but instead invent new tree
codes
> for common stuff (like for example a generic vector permute/select
operation).

that's a good point, and I think what you suggest is exactly the rule of
thumb that has been used in the vectorizer: use optabs/tree-codes for
generic stuff, and use builtins only for esoteric functions (e.g.
builtin_mask_for_load, builtin_mul_widen_even/odd). The only other
vectorizer builtins that we have are builtin_conversion and
builtin_vec_perm, for which I think it may be indeed questionable whether
the right choice was made.
I don't know why we added the vector conversion idiom as a builtin -- maybe
that's something to revisit.
As for builtin_vec_perm -- there was actually a long discussion about this
one at the time (about 5 years ago... titled "optabs and tree-codes for
vector operations" from Aug 2004) -- the conclusion was that a generic
vec_perm was supported only by Altivec and therefore does not deserve an
optab/tree-code. Also at the time we used this permute-like functionality
only for realignment, for which we ended up adding more specific idioms
instead. But I think things have changed since then on both respects: more
platforms now support generic permutes (Cell-SPU, as well as recent SSE
versions (and/or AVX?)), and also we are now generating permutes for cases
other than realignment. So it may indeed make sense now to upgrade vec_perm
to have proper optab/tree-code rather than a builtin.

dorit

> That would be a type generic solution and expand can then directly handle
> them.  That would avoid the need to create the variants for signedness
> or int/float kind for the builtins at least.
>
> OTOH your fix is certainly valid.
>
> Richard.


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