[cfe-dev] On which option should vector operator ? : depend?

[Daniel Dunbar]

On Wed, Sep 29, 2010 at 9:17 PM, Bob Wilson <bob.wilson at apple.com> wrote:
>
> On Sep 29, 2010, at 2:11 PM, Douglas Gregor wrote:
>
>>
>> On Sep 29, 2010, at 12:35 PM, Daniel Dunbar wrote:
>>
>>> On Wed, Sep 29, 2010 at 11:23 AM, Douglas Gregor <dgregor at apple.com>
>>> wrote:
>>>>
>>>> On Sep 29, 2010, at 11:08 AM, Sebastian Redl wrote:
>>>>
>>>>>
>>>>> On Sep 29, 2010, at 11:01 AM, Daniel Dunbar wrote:
>>>>>
>>>>>> On Wed, Sep 29, 2010 at 10:41 AM, Sebastian Redl
>>>>>> <sebastian.redl at getdesigned.at> wrote:
>>>>>>>
>>>>>>> It seems weird to me too, but I think the question here is not
>>>>>>> whether to have it - IIUC OpenCL demands it - but whether it makes sense to
>>>>>>> make it work conditionally only for some language flags. And IMO, if you
>>>>>>> have ?: mean vector select in one dialect, you might as well make it work in
>>>>>>> all of them.
>>>>>>
>>>>>> Why? OpenCL is a different language in many ways.
>>>>>
>>>>> AltiVec vector support isn't.
>>>>
>>>> For AltiVec support, we have precedent to follow: what does GCC do? We
>>>> need to do the same.
>>>>
>>>> Now, Clang's ext_vector_type is a specific vector type that Clang added
>>>> for OpenCL. It seems reasonable that it would have OpenCL's semantics,
>>>> regardless of dialect. For example, we permit the OpenCL "vec.xyzw" syntax
>>>> for ext_vector_type vectors in all dialects.
>>>
>>> Yes, but that syntax has no (sensical) precedent in C, so programmers
>>> aren't likely to confuse it with "what C would normally do", at least
>>> in code that compiles.
>>
>> I think that's a wonderful argument against OpenCL's abuse of the ? :
>> notation to mean vector selection. But, OpenCL made that decision, so our
>> only decision is whether this syntax applies to Clang's extended vectors
>> (the purpose of which is to support OpenCL) or to Clang when in OpenCL mode.
>> We have precedent for the format.
>>
>> Note that there's no conversion from a vector type to bool, so
>>
>>        vec? vec1 : vec2
>>
>> is currently ill-formed. So, while having that expression turn into a
>> select might confuse a C programmer, at least we're not changing the
>> semantics of existing, well-formed code.
>
> I don't know much of anything about OpenCL, Clang, or the history of this
> issue, but here's my $0.02: I can see a few possible versions of ?: with
> vectors.
>
> 1) bool ? vec1 : vec2
> That is pretty unambiguous to me.
>
> 2) vector of bools ? vec1 : vec2
> This too seems unambiguous.  It must be a vector select (if it's legal).
>
> 3) vector comparison ? vec1 : vec2
> e.g. "vec1 < vec2 ? vec1 : vec2" would be a vector minimum
> How does Clang handle comparisons of its extended vector types?
>
> As Doug pointed out, interpretations (1) and (2) are not going to be
> confused unless you have conversions from vector types to bool.  All the
> other vector operations in LLVM (maybe not in Clang?) are defined to be the
> element-wise equivalents of the standard operations, so that would argue for
> allowing (2).
>
> It seems to me that case (3) might help clarify this.  If Clang allows
> element-wise comparisons of its extended vector types, you ought to be able
> to replace the vector minimum example above with: "tmp = vec1 < vec2; min =
> tmp ? vec1 : vec2".  That would mean that case (2) should be allowed.  If
> Clang does not support element-wise vector comparisons, is there any
> particular reason why not?  If you want to do vector comparisons and selects
> with Clang's extended vectors, what is the alternative?  Builtins?

We do already support vector comparison as element-wise. I guess this
is a good argument for making the ternary operator be element wise
too.

 - Daniel