From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fx302.security-mail.net (mxout.security-mail.net [85.31.212.42]) by sourceware.org (Postfix) with ESMTPS id 422063858D3C for ; Tue, 18 Oct 2022 09:22:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 422063858D3C Authentication-Results: sourceware.org; dmarc=fail (p=quarantine dis=none) header.from=kalrayinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kalray.eu Received: from localhost (localhost [127.0.0.1]) by fx302.security-mail.net (Postfix) with ESMTP id 1E9041C3E679 for ; Tue, 18 Oct 2022 11:22:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kalrayinc.com; s=sec-sig-email; t=1666084921; bh=0TmQT+mxvscR8CSwC17y8rMt0wp3AarpbTHDuBCUMP0=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=OZVftRX8wx+jwY8d9GJqCoX96uqKP1s7V+6yUJhmE8kxX/5YajvT3atlWMdmxsq2x SFsXJpSr5jvwNrqBwCGDeFWM0CCFmJiExUGftd+bTM2LQkLAGZjoWmJpG5emj5QpZG ZksF8L+JRe8blj/7t8M9UNbz/qGkxHl13afcuv+8= Received: from fx302 (localhost [127.0.0.1]) by fx302.security-mail.net (Postfix) with ESMTP id F24081C3E669; Tue, 18 Oct 2022 11:22:00 +0200 (CEST) Received: from zimbra2.kalray.eu (unknown [217.181.231.53]) by fx302.security-mail.net (Postfix) with ESMTPS id 4CED01C3E5CE; Tue, 18 Oct 2022 11:22:00 +0200 (CEST) Received: from zimbra2.kalray.eu (localhost [127.0.0.1]) by zimbra2.kalray.eu (Postfix) with ESMTPS id 3119327E0461; Tue, 18 Oct 2022 11:22:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra2.kalray.eu (Postfix) with ESMTP id 1840527E0478; Tue, 18 Oct 2022 11:22:00 +0200 (CEST) Received: from zimbra2.kalray.eu ([127.0.0.1]) by localhost (zimbra2.kalray.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1LxjwYTE18ot; Tue, 18 Oct 2022 11:22:00 +0200 (CEST) Received: from localhost (unknown [192.168.37.51]) by zimbra2.kalray.eu (Postfix) with ESMTPSA id EE06227E0461; Tue, 18 Oct 2022 11:21:59 +0200 (CEST) X-Virus-Scanned: E-securemail Secumail-id: <11a32.634e7038.4b767.0> DKIM-Filter: OpenDKIM Filter v2.10.3 zimbra2.kalray.eu 1840527E0478 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kalrayinc.com; s=4F334102-7B72-11EB-A74E-42D0B9747555; t=1666084920; bh=khmE6uDjkZvB8rDw8+8CXEEQqjpwqGKzELE1Uq9/KB0=; h=Date:From:To:Message-ID:MIME-Version; b=ms/yo+7RuUXkH/boPJqcIqqy4lT0vdcrMjsi2Lb2johc0AbITlEH2N7/PvzbzczUc tZF56l5tmaiF8joGMDPGED1QptyTjkRc3ev65+tr7gI1EWdMMEDPOdBnJXRPRKoN/5 m3X+8dcwxknvZONHVOg6ZYIaoUQGlp2XMmg6YLVGDknfFxSMYeJ13s5706ZLSAhZrl B5yniMZWpVi0s7NbZNgCEyesa+S9Dr3+DVB5VfqZ2GoxpxeoonZ6gWDXIouja6uZbU WzRdhv6yg96aAATMrDNtjjXeP9RLc8vbNOLXhkNsZa1zfZnbvfLecL+AE8NtqSlHda E1lTd54ENpakw== Date: Tue, 18 Oct 2022 11:21:51 +0200 From: Paul Iannetta To: Richard Biener Cc: Joseph Myers , gcc-patches@gcc.gnu.org Subject: Re: [RFC] Add support for vectors in comparisons (like the C++ frontend does) Message-ID: <20221018092151.m7julmkv3nhmic3s@ws2202.lin.mbt.kalray.eu> References: <20221010141141.krpmtzmbgadlo3db@ws2202.lin.mbt.kalray.eu> <20221011231819.u25zufq4fqmapwzg@ws2202.lin.mbt.kalray.eu> <20221014141709.chu64s2fpo6u3p76@ws2202.lin.mbt.kalray.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Content-Transfer-Encoding: 8bit X-ALTERMIMEV2_out: done X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_LOW,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 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 > 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