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: Vector comparison


On Sun, Aug 15, 2010 at 7:45 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Sun, 15 Aug 2010, Artem Shinkarov wrote:
>
>> This patch implements vector comparison according to OpenCL standard.
>
> Suppose your target's vector comparison instructions encode the result
> some way other than a vector of 0 and -1 values. ?How effectively can such
> instructions be used in the context of your patch?

SSE and AltiVec at least define vector comparison result as a vector
of 0 and -1. So I think that this would be an exotic architecture (but
I'm not sure). Anyway, if the target returns boolean value, then the
implementation of the hook should return constant vector of zeros for
false and constant vector of -1-s for true.

The other thing which is unclear what is the definition of boolean
comparison with the test ">"? It could be treated very differently
considering the situation: all the elements of first vector are
bigger, most of the elements are bigger, at least one element is
bigger... I don't know the right answer, I'm even not sure if there is
one.

Again, both approaches (vector return and boolean return) have its own
disadvantages. The question is what is the common approach at in
hardware. I think that vector return.

Also it is not a big deal to support both approaches, the question is
which one should be expressed using the comparison operations.

>In the typical use
> cases of comparisons that you expect in real code, will it be possible to
> optimize code written for the 0 and -1 values so that it uses instructions
> generating some other encoding without a lot of conversions between the
> two conventions? ?(For example, if code does several vector comparisons
> and boolean operations on the results of those comparisons, it should be
> possible to convert convention at most once at the end of those
> operations.) ?Is there a clear route, once your patch is applied, to add
> support incrementally for targets using such other conventions and for
> such optimizations for such targets?

I think that yes, if we will agree on what are the rules for
conversion between boolean and vector approach. In other words how
many -1 is enough to make the value true.

All the reset is solvable. We would just change a boolean with a
vector and vice-versa. At least I can't see any huge problems there,
but may be i'm wrong.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
>


-- 
Artem Shinkarov


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