[cfe-dev] [RFC] Ternary operator with vector type predicate

Tue May 19 11:48:07 PDT 2020

Yes, we do implement these rules for OpenCL and they are applied to all OpenCL versions.
https://godbolt.org/z/YH6ExF

From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of Finkel, Hal J. via cfe-dev
Sent: Tuesday, May 19, 2020 8:36 PM
To: Anastasia Stulova <Anastasia.Stulova at arm.com>; Keane, Erich <erich.keane at intel.com>; Min-Yih Hsu <minyihh at uci.edu>; clang developer list <cfe-dev at lists.llvm.org>
Cc: nd <nd at arm.com>
Subject: Re: [cfe-dev] [RFC] Ternary operator with vector type predicate

Thanks, Anastasia. I have certainly used the ext_vector_type types outside of OpenCL mode in the past. Do we currently implement the OpenCL 2 ternary operator rules for these vectors?

 -Hal

Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

________________________________
From: Anastasia Stulova <Anastasia.Stulova at arm.com<mailto:Anastasia.Stulova at arm.com>>
Sent: Tuesday, May 19, 2020 12:30 PM
To: Keane, Erich <erich.keane at intel.com<mailto:erich.keane at intel.com>>; Min-Yih Hsu <minyihh at uci.edu<mailto:minyihh at uci.edu>>; Finkel, Hal J. <hfinkel at anl.gov<mailto:hfinkel at anl.gov>>; clang developer list <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Cc: nd <nd at arm.com<mailto:nd at arm.com>>
Subject: Re: [cfe-dev] [RFC] Ternary operator with vector type predicate

I see ext_vector_type as a Clang extension that implements OpenCL rules under OpenCL mode. I believe there are areas where it behaves slightly differently if it's used in non-OpenCL code. I am not aware of details, but I believe it is used outside of OpenCL mode too.

Anastasia
________________________________
From: cfe-dev <cfe-dev-bounces at lists.llvm.org<mailto:cfe-dev-bounces at lists.llvm.org>> on behalf of Finkel, Hal J. via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Sent: 19 May 2020 14:22
To: Keane, Erich <erich.keane at intel.com<mailto:erich.keane at intel.com>>; Min-Yih Hsu <minyihh at uci.edu<mailto:minyihh at uci.edu>>
Cc: cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org> <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Subject: Re: [cfe-dev] [RFC] Ternary operator with vector type predicate

________________________________
From: Keane, Erich <erich.keane at intel.com<mailto:erich.keane at intel.com>>
Sent: Tuesday, May 19, 2020 8:10 AM
To: Finkel, Hal J. <hfinkel at anl.gov<mailto:hfinkel at anl.gov>>; Min-Yih Hsu <minyihh at uci.edu<mailto:minyihh at uci.edu>>
Cc: cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org> <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Subject: RE: [cfe-dev] [RFC] Ternary operator with vector type predicate

What is the intent with the ext-vector-types?

That's a really good question. I've always thought of them as a slightly-more-convenient version of the vector types, although I suppose that they're really supposed to be OpenCL vectors. The Clang extension docs say, "OpenCL vector types are created using the ext_vector_type attribute. It supports the V.xyzw syntax and other tidbits as seen in OpenCL." Thus, for OpenCL, I suppose that it is supposed to do this: https://www.khronos.org/registry/OpenCL/specs/2.2/html/OpenCL_C.html#operators-ternary-selection

 -Hal

 It seems to me that it is an incompatible extension without anyone really maintaining them, and slightly different SEMA rules (for seemingly no reason).

The conditional operator for the vector_size value was implemented as a GCC compatibility option, but no such motivation existed for ext-vetctor-types.

That said, the semantic analysis for this in ext-vector-types is sufficiently different that it wasn't possible to combine implementations.  The rules had diverged significantly at one point, so there wasn't really a way to do so compatibly.

From: Finkel, Hal J. <hfinkel at anl.gov<mailto:hfinkel at anl.gov>>
Sent: Tuesday, May 19, 2020 6:05 AM
To: Keane, Erich <erich.keane at intel.com<mailto:erich.keane at intel.com>>; Min-Yih Hsu <minyihh at uci.edu<mailto:minyihh at uci.edu>>
Cc: cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] [RFC] Ternary operator with vector type predicate

In general, I don't like to see features supported by not-ext-vector types that are not supported by ext-vector types.

That having been said, is this related to our discussion on bool vectors:

  http://lists.llvm.org/pipermail/cfe-dev/2020-May/065434.html

 -Hal

Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

________________________________

From: cfe-dev <cfe-dev-bounces at lists.llvm.org<mailto:cfe-dev-bounces at lists.llvm.org>> on behalf of Min-Yih Hsu via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Sent: Friday, May 8, 2020 1:17 PM
To: Keane, Erich <erich.keane at intel.com<mailto:erich.keane at intel.com>>
Cc: cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org> <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Subject: Re: [cfe-dev] [RFC] Ternary operator with vector type predicate

Interesting....then I think the question simply becomes whether we should support it in ext_vector_type as well.

Thanks for the pointer

-Min

On May 8, 2020, at 11:04 AM, Keane, Erich <erich.keane at intel.com<mailto:erich.keane at intel.com>> wrote:

Note that this was implemented for non-ext-vector types here:

https://github.com/llvm/llvm-project/commit/349636d2bfc39a5c81a835a95d203a42d9f9301a

Which matches the GCC version.

The attribute is vector_size, not ext_vector_type however.

Otherwise, it does everything you're proposing (like I said, just with a more portable vector-type definition).

From: cfe-dev <cfe-dev-bounces at lists.llvm.org<mailto:cfe-dev-bounces at lists.llvm.org>> On Behalf Of Min-Yih Hsu via cfe-dev
Sent: Friday, May 8, 2020 10:58 AM
To: cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
Subject: [cfe-dev] [RFC] Ternary operator with vector type predicate

Hi folks,

In clang's vector extension, the ternary operator (?:) is able to select from two vector type values based on the boolean type predicate. For example:

```

typedef float float4 __attribute__((ext_vector_type(4)));

float4 foo(bool cond, float4 a, float4 b) {

  return cond? a : b;

}

```

However, clang currently doesn't support vector type values as the predicates. So code shown below won't compile:

```

float4 foo(float4 a, float4 b) {

  return a > b? a : b;

}

```

Which is essentially just a max function that can be implemented by hardware instructions (vmaxps in Intel AVX for example) efficiently.

I'm proposing to support vector type values as predicates in the ternary operator: If the predicate value has vector type, each of its element would be converted to bool before being used to select corresponding elements from the second or third operands. Note that this is exactly what GCC is doing right now [1] in their vector extensions.

On the (IR) codegen side, since the IR `select`, `icmp`, and `fcmp` instruction all support vector type values as the operands, I don't think there are much trouble in it.

Here are the reasons and some advantages:

1. It provides more flexibility for programmers to do conditional selections on vectors. Especially for cases that can be optimized by hardware instructions like the motivated example above.

2. It will not break the current usages of ternary operator: If the predicate is a scalar value, it's still sticking to the current model.

3. If the goal of our extensions is aiming to "support a broad range of GCC extensions". Then the behavior should also be as consistent as possible.

I'll try to come up with a patch for preview as soon as possible.

Also a slightly off-topic thing: In our document [2], the ternary operator has always been mis-typed as ':?' Maybe we should fix it some times.

Thanks for the feedbacks in advance.

-Min

[1]: https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html

[2]: https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200519/b05dd67f/attachment-0001.html>