From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id 4A15C3858C83 for ; Mon, 17 Oct 2022 07:22:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4A15C3858C83 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-x62b.google.com with SMTP id b2so22838935eja.6 for ; Mon, 17 Oct 2022 00:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=UqpWAQAe4l5/MzDQsJQPUlAHjfcTeEWqW9//NR4XRF8=; b=e94IcS7R/rkzWotbYW53wQxGnneKLrTcm2GLbk+L3qaMuBim8xZJIrej1liG1ovWUb sfUUFgy+WWjcqPxKBFQxc67ICoOfZY9ChoOTa3u6MPl1Wh4s2GrAJAQ6eAwKWQjEYAIr 21QjSJNItGreb0+hDRcF0ejkgrkrJ9lREMv/1CJ3f1zmu7a0ryUPxGtkWXsS2YsT91wo 2tXB1TlmhCjXhxlvC7j/kBNt8K19/o5Oj+uTrai8fw5eBz0mToXmQ8v3gcXQt4lvALnj syflJ+7+wrB7CMYFENO817Y5XOLlx+nR7OtDqm/ognT46/WYXVxb0i38cXBJNmyVCqdw fqFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=UqpWAQAe4l5/MzDQsJQPUlAHjfcTeEWqW9//NR4XRF8=; b=B+7Gr8He2hRqHloDOn/CyEYpL1qGR/PHbiadWGk5R1wssI774o79/raVSxSImY1Bl7 RSaKEYhWptTXU9zrT3wJ0LW7WPOYS8TiT3N9cgyNVSdS7O9Psj3epoYlil8Sk89K+u45 QgBVn76+mddmeGRnVreaPosc9XDGeyDd/8tKaYhtrWnJ4hKc01h3axGBZAcalBW0qgGb E93JQgO1yx8GMqDFbRPz27fb05zQHTAOKKELhwMtYLFScJ77VaaGX9N6qKhTfALg0ZPc iygHVoHIPQdD7rVa8Z3rA9fjSkFxVqfJk+o5EocAysi67BptsqUiYp4PSFVLQxQeeJ4o K+UA== X-Gm-Message-State: ACrzQf2SvA6+BZ6Ke/fXm/NIIPWCX0ttEMsYJiuzy1hxKloIQQrmCbpz JGWXpcEaG1fEJJqbV4wW2KWW2Jh7atwyGufbiPY= X-Google-Smtp-Source: AMsMyM5IEP0GEI5VtstbjlI0Z3Dfc6EcY16soIZhKLFZD2jvYNHb4k4Rcgj3o4VAiSQQtvW5MzCFVP32HcKXn37T7EI= X-Received: by 2002:a17:907:6d08:b0:78e:e87:5c06 with SMTP id sa8-20020a1709076d0800b0078e0e875c06mr7346415ejc.511.1665991355835; Mon, 17 Oct 2022 00:22:35 -0700 (PDT) MIME-Version: 1.0 References: <20221010141141.krpmtzmbgadlo3db@ws2202.lin.mbt.kalray.eu> <20221011231819.u25zufq4fqmapwzg@ws2202.lin.mbt.kalray.eu> <20221014141709.chu64s2fpo6u3p76@ws2202.lin.mbt.kalray.eu> In-Reply-To: <20221014141709.chu64s2fpo6u3p76@ws2202.lin.mbt.kalray.eu> From: Richard Biener Date: Mon, 17 Oct 2022 09:22:23 +0200 Message-ID: Subject: Re: [RFC] Add support for vectors in comparisons (like the C++ frontend does) To: Paul Iannetta Cc: Joseph Myers , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Oct 14, 2022 at 4:18 PM Paul Iannetta via Gcc-patches 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, an= d > > > > would like to hear your opinion on it, especially since it may affe= ct > > > > the feature-set of the objc front-end as well. > > > > > > > Currently, this is only a tentative patch and I did not add any tes= ts > > > > to the testsuite. > > > > > > I think tests (possibly existing C++ tests moved to c-c++-common?) ar= e > > > necessary to judge such a feature; it could better be judged based on > > > tests without implementation than based on implementation without tes= ts. > > > > 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 =3D a + !b; > > v2si e =3D 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 =3D a + (b =3D=3D 0); > > v2si e =3D (a !=3D 0) | (b !=3D 0); > > return ((c !=3D 0) & (((a + (b =3D=3D 0)) !=3D 0) & (((c - e) !=3D 0)= & (a !=3D 0)))) > > | ((c =3D=3D 0) & (((((b =3D=3D 0) =3D=3D 0) ^ c) !=3D 0) & (e != =3D 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 =3D vector-condition ? vec1 : vec2" is equivalent to > ``` (from tree.def) > for (int i =3D 0 ; i < n ; ++i) > vec0[i] =3D 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 =3D (*y < *t) ? '1' : '0'; // error: inferred scalar type =E2=80=98c= har=E2=80=99 is > // not an integer or floating-point type > // of the same size as =E2=80=98float=E2=80= =99. > > for (int i =3D 0 ; i < 2 ; ++i) // fine > (*x)[i] =3D (*y)[i] < (*t)[i] ? '1' : '0'; // > > *z =3D (*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], =E2=80= =A6} > 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 =3D 0 ; i < n ; ++i) > vec0[i] =3D vector-condtion[i] ? vec1[i] : vec2[i]; > ``` > implicit conversions may happen, which is completely over-looked > currently. That is, the type of (1): "v =3D 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 =3D (*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 =3D 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. > > Paul > > > >