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? Paul