On Mon, Oct 17, 2022 at 09:22:23AM +0200, Richard Biener wrote:
> On Fri, Oct 14, 2022 at 4:18 PM Paul Iannetta via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
> >
> > On Wed, Oct 12, 2022 at 01:18:19AM +0200, Paul Iannetta wrote:
> > > On Mon, Oct 10, 2022 at 11:07:06PM +0000, Joseph Myers wrote:
> > > > On Mon, 10 Oct 2022, Paul Iannetta via Gcc-patches wrote:
> > > >
> > > > > I have a patch to bring this feature to the C front-end as well, and
> > > > > would like to hear your opinion on it, especially since it may affect
> > > > > the feature-set of the objc front-end as well.
> > > >
> > > > > Currently, this is only a tentative patch and I did not add any tests
> > > > > to the testsuite.
> > > >
> > > > I think tests (possibly existing C++ tests moved to c-c++-common?) are
> > > > necessary to judge such a feature; it could better be judged based on
> > > > tests without implementation than based on implementation without tests.
> > >
> > > Currently, this feature has the following tests in g++.dg/ext/
> > > - vector9.C
> > > - vector19.C
> > > - vector21.C
> > > - vector22.C
> > > - vector23.C
> > > - vector27.C
> > > - vector28.C
> > > provided by Marc Glisse when he implemented the feature for C++.
> > >
> > > They are all handled by my mirror implementation (after removing
> > > C++-only features), save for a case in vector19.C ( v ? '1' : '2',
> > > where v is a vector of unsigned char, but '1' and '2' are considered
> > > as int, which results in a type mismatch.)
> > >
> > > I'll move those tests to c-c++-common tomorrow, but will duplicate
> > > vector19.C and vector23.C which rely on C++-only features.
> > >
> > > During my tests, I've been using variations around this:
> > >
> > > typedef int v2si __attribute__((__vector_size__ (2 * sizeof(int))));
> > >
> > > v2si f (v2si a, v2si b, v2si c)
> > > {
> > > v2si d = a + !b;
> > > v2si e = a || b;
> > > return c ? (a + !b) && (c - e && a) : (!!b ^ c && e);
> > > }
> > >
> > > It is already possible to express much of the same thing without the
> > > syntactic sugar but is is barely legible
> > >
> > > typedef int v2si __attribute__((__vector_size__ (2 * sizeof(int))));
> > >
> > > v2si f (v2si a, v2si b, v2si c)
> > > {
> > > v2si d = a + (b == 0);
> > > v2si e = (a != 0) | (b != 0);
> > > return ((c != 0) & (((a + (b == 0)) != 0) & (((c - e) != 0) & (a !=
> > > 0))))
> > > | ((c == 0) & (((((b == 0) == 0) ^ c) != 0) & (e != 0)));
> > > }
> > >
> > > Paul
> >
> > I still need to check what is done by clang on the objc side, but in
> > order to not conflict with what was done before, a warning is
> > triggered by c_obj_common_truthvalue_conversion and
> > build_unary_operator warns if '!' is used with a vector. Both warnings
> > are only triggered in pedantic mode as suggested by Iain Sandoe.
> >
> > The support of the binary ops and unary ops works as the C++ front-end
> > does, there is however the case of the ternary conditional operator,
> > where the C standard mandates the promotion of the operands if they
> > have rank less than (unsigned) int, whereas C++ does not.
> >
> > In any case, as per the documentation of VEC_COND_EXPR,
> > "vec0 = vector-condition ? vec1 : vec2" is equivalent to
> > ``` (from tree.def)
> > for (int i = 0 ; i < n ; ++i)
> > vec0[i] = vector-condtion[i] ? vec1[i] : vec2[i];
> > ```
> > But this is currently not the case, even in C++ where
> > ``` (Ex1)
> > typedef signed char vec2 __attribute__((vector_size(16)));
> > typedef float vec2f __attribute__((vector_size( 2 * sizeof (float))));
> >
> > void j (vec2 *x, vec2 *z, vec2f *y, vec2f *t)
> > {
> > *x = (*y < *t) ? '1' : '0'; // error: inferred scalar type ‘char’ is
> > // not an integer or floating-point type
> > // of the same size as ‘float’.
> >
> > for (int i = 0 ; i < 2 ; ++i) // fine
> > (*x)[i] = (*y)[i] < (*t)[i] ? '1' : '0'; //
> >
> > *z = (*x < *z) ? '1' : '0'; // fine
> > }
> > ```
> >
> > The documentation explicitly says:
> > > the ternary operator ?: is available. a?b:c, where b and c are
> > > vectors of the same type and a is an integer vector with the same
> > > number of elements of the same size as b and c, computes all three
> > > arguments and creates a vector {a[0]?b[0]:c[0], a[1]?b[1]:c[1], …}
> > Here, "*y < *t" is a boolean vector (and bool is an integral type
> > ([basic.fundamental] 11), so this should be accepted.
> >
> > An other point is that if we look at
> > ```
> > for (int i = 0 ; i < n ; ++i)
> > vec0[i] = vector-condtion[i] ? vec1[i] : vec2[i];
> > ```
> > implicit conversions may happen, which is completely over-looked
> > currently. That is, the type of (1): "v = v0 ? v1 : v2" is the lowest
> > common type of v, v1 and v2; and the type of (2): "v0 ? v1 : v2" is the
> > lowest common type of v1 and v2. (2) can appear as a parameter, but
> > even in that case, I think that (2) should be constrained by the type
> > of the parameter and we are back to case (1).
> >
> > My points are that:
> > - the current implementation has a bug: " *x = (*y < *t) ? '1' :
> > '0';" from (Ex1) should be fine.
> > - the current implementation does not explicetly follow the
> > documented behavior of VEC_COND_EXPR.
> >
> > What do you think?
>
> Implicit promotion was explicitely not implemented for the vector
> extension as that would usually lead to unexpected slowness
> (scalar expansion). Instead I think we accept unpromoted operands
> when they match and diagnose other cases. ISTR this is documented
> somewhere but the ternary conditional operator docs may be indeed
> over-simplified here. The docs mention
> 'The operations behave like C++ @code{valarrays}.' it should
> probably be clarified that while
>
> v16qi a,b,c;
> a = b + c;
>
> computes the sum of the elements the implicit promotion/demotion
> required by the C/C++ standards for scalar operations is _not_
> performed (and so technically considers signed vector char
> adds as invoking undefined behavior on overflow rather than
> implementation defined behavior on the truncation step - something
> we should mitigate by performing the adds in unsigned when C/C++
> would promote)
>
> I think the non-promotion also follows what openCL does (the intent
> of the vector extension was to somewhat follow that spec).
>
> Richard.
>
I understand better the context and the motivation behind the current
implementation, thanks!
If the goal is indeed to match the behavior of OpenCL C on how it treats
vectors in the select operation, I should do the same in C. I think
that I will add a flag controlling the promotion of operands in
build_conditionnal_expr in order to avoid duplicating too much code.
I'll also try to clarify the documentation with respect to those
issues.
Paul.
> >
> > Paul
