From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37317 invoked by alias); 30 Aug 2019 14:20:11 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 37237 invoked by uid 89); 30 Aug 2019 14:20:08 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-13.1 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 30 Aug 2019 14:20:06 +0000 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x7UEI6sJ100860 for ; Fri, 30 Aug 2019 10:20:04 -0400 Received: from e06smtp02.uk.ibm.com (e06smtp02.uk.ibm.com [195.75.94.98]) by mx0a-001b2d01.pphosted.com with ESMTP id 2uq3vebu7a-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 30 Aug 2019 10:20:04 -0400 Received: from localhost by e06smtp02.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 30 Aug 2019 15:20:02 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196) by e06smtp02.uk.ibm.com (192.168.101.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Fri, 30 Aug 2019 15:19:58 +0100 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x7UEJvW225755684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 30 Aug 2019 14:19:57 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BFFCEAE045; Fri, 30 Aug 2019 14:19:57 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 94492AE057; Fri, 30 Aug 2019 14:19:57 +0000 (GMT) Received: from dyn-9-152-96-21.boeblingen.de.ibm.com (unknown [9.152.96.21]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 30 Aug 2019 14:19:57 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: [PATCH v2 0/9] S/390: Use signaling FP comparison instructions From: Ilya Leoshkevich In-Reply-To: Date: Fri, 30 Aug 2019 14:32:00 -0000 Cc: GCC Patches , Richard Sandiford , Segher Boessenkool Content-Transfer-Encoding: quoted-printable References: <20190822134551.18924-1-iii@linux.ibm.com> To: Richard Biener x-cbid: 19083014-0008-0000-0000-0000030F0BFA X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19083014-0009-0000-0000-00004A2D53E8 Message-Id: <2E1A915D-0625-4C17-9DC7-7058D9C033DF@linux.ibm.com> X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg02080.txt.bz2 > Am 30.08.2019 um 09:16 schrieb Richard Biener : >=20 > On Fri, Aug 30, 2019 at 9:12 AM Richard Biener > wrote: >>=20 >> On Thu, Aug 29, 2019 at 5:39 PM Ilya Leoshkevich wro= te: >>>=20 >>>> Am 22.08.2019 um 15:45 schrieb Ilya Leoshkevich : >>>>=20 >>>> Bootstrap and regtest running on x86_64-redhat-linux and >>>> s390x-redhat-linux. >>>>=20 >>>> This patch series adds signaling FP comparison support (both scalar and >>>> vector) to s390 backend. >>>=20 >>> I'm running into a problem on ppc64 with this patch, and it would be >>> great if someone could help me figure out the best way to resolve it. >>>=20 >>> vector36.C test is failing because gimplifier produces the following >>>=20 >>> _5 =3D _4 > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 }; >>> _6 =3D VEC_COND_EXPR <_5, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>; >>>=20 >>> from >>>=20 >>> VEC_COND_EXPR < (*b > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 }) , >>> { -1, -1, -1, -1 } , >>> { 0, 0, 0, 0 } > >>>=20 >>> Since the comparison tree code is now hidden behind a temporary, my code >>> does not have anything to pass to the backend. The reason for creating >>> a temporary is that the comparison can trap, and so the following check >>> in gimplify_expr fails: >>>=20 >>> if (gimple_seq_empty_p (internal_post) && (*gimple_test_f) (*expr_p)) >>> goto out; >>>=20 >>> gimple_test_f is is_gimple_condexpr, and it eventually calls >>> operation_could_trap_p (GT). >>>=20 >>> My current solution is to simply state that backend does not support >>> SSA_NAME in vector comparisons, however, I don't like it, since it may >>> cause performance regressions due to having to fall back to scalar >>> comparisons. >>>=20 >>> I was thinking about two other possible solutions: >>>=20 >>> 1. Change the gimplifier to allow trapping vector comparisons. That's >>> a bit complicated, because tree_could_throw_p checks not only for >>> floating point traps, but also e.g. for array index out of bounds >>> traps. So I would have to create a tree_could_throw_p version which >>> disregards specific kinds of traps. >>>=20 >>> 2. Change expand_vector_condition to follow SSA_NAME_DEF_STMT and use >>> its tree_code instead of SSA_NAME. The potential problem I see with >>> this is that there appears to be no guarantee that _5 will be inlined >>> into _6 at a later point. So if we say that we don't need to fall >>> back to scalar comparisons based on availability of vector > >>> instruction and inlining does not happen, then what's actually will >>> be required is vector selection (vsel on S/390), which might not be >>> available in general case. >>>=20 >>> What would be a better way to proceed here? >>=20 >> On GIMPLE there isn't a good reason to split out trapping comparisons >> from [VEC_]COND_EXPR - the gimplifier does this for GIMPLE_CONDs >> where it is important because we'd have no way to represent EH info >> when not done. It might be a bit awkward to preserve EH across RTL >> expansion though in case the [VEC_]COND_EXPR are not expanded >> as a single pattern, but I'm not sure. >>=20 >> To go this route you'd have to split the is_gimple_condexpr check >> I guess and eventually users turning [VEC_]COND_EXPR into conditional >> code (do we have any?) have to be extra careful then. >=20 > Oh, btw - the fact that we have an expression embedded in [VEC_]COND_EXPR > is something that bothers me for quite some time already and it makes > things like VN awkward and GIMPLE fincky. We've discussed alternatives > to dead with the simplest being moving the comparison out to a separate > stmt and others like having four operand [VEC_]COND_{EQ,NE,...}_EXPR > codes or simply treating {EQ,NE,...}_EXPR as quarternary on GIMPLE > with either optional 3rd and 4th operand (defaulting to boolean_true/fals= e_node) > or always explicit ones (and thus dropping [VEC_]COND_EXPR). >=20 > What does LLVM do here? For void f(long long * restrict w, double * restrict x, double * restrict y, in= t n) { for (int i =3D 0; i < n; i++) w[i] =3D x[i] =3D=3D y[i] ? x[i] : y[i]; } LLVM does %26 =3D fcmp oeq <2 x double> %21, %25 %27 =3D extractelement <2 x i1> %26, i32 0 %28 =3D select <2 x i1> %26, <2 x double> %21, <2 x double> %25 So they have separate operations for comparisons and ternary operator (fcmp + select).