From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84759 invoked by alias); 30 Aug 2019 07:12:27 -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 84632 invoked by uid 89); 30 Aug 2019 07:12:26 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_1,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Received:Fri X-HELO: mail-lj1-f194.google.com Received: from mail-lj1-f194.google.com (HELO mail-lj1-f194.google.com) (209.85.208.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 30 Aug 2019 07:12:25 +0000 Received: by mail-lj1-f194.google.com with SMTP id x4so5483353ljj.6 for ; Fri, 30 Aug 2019 00:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ctzUge6Ej+y5KUTLa+Bl652o9xt9XXMxOI3UwseDwuw=; b=lC1jGkH+JYO9gS+wRrX99ZNitPRurHYL1NCdaMChtc6Hl2ETg4HobeG6JHJKvioyzz 5bPCHEUUx+E0z3AcXCyZfGb7iOkh+5T2bwGHqeqxW4DfPRB1nDBp7LBKu1rY59Dsb09A Kt2yinCjFXWkXI4H+modm9ohEBraCTrzAfOgZ0+8/EzqQ8HctNwV4qBryZnH6qHCWayw 3dgMOWsC2o9MXw1SdzvpGUVz9X5SCKUaNK1csHor+KgvbGt8KrWVBNxMk8EmlAEF0QYz tZO/rFlAxpwLOutoU4E5/yqOeOB0Z3X+ld8D0rMSB+0+IJ9lgIMmVaXBK352r1m9YWpZ qd/A== MIME-Version: 1.0 References: <20190822134551.18924-1-iii@linux.ibm.com> In-Reply-To: From: Richard Biener Date: Fri, 30 Aug 2019 07:27:00 -0000 Message-ID: Subject: Re: [PATCH v2 0/9] S/390: Use signaling FP comparison instructions To: Ilya Leoshkevich Cc: GCC Patches , Richard Sandiford , Segher Boessenkool Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg02031.txt.bz2 On Thu, Aug 29, 2019 at 5:39 PM Ilya Leoshkevich wrote: > > > Am 22.08.2019 um 15:45 schrieb Ilya Leoshkevich : > > > > Bootstrap and regtest running on x86_64-redhat-linux and > > s390x-redhat-linux. > > > > This patch series adds signaling FP comparison support (both scalar and > > vector) to s390 backend. > > 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. > > vector36.C test is failing because gimplifier produces the following > > _5 = _4 > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 }; > _6 = VEC_COND_EXPR <_5, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>; > > from > > VEC_COND_EXPR < (*b > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 }) , > { -1, -1, -1, -1 } , > { 0, 0, 0, 0 } > > > 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: > > if (gimple_seq_empty_p (internal_post) && (*gimple_test_f) (*expr_p)) > goto out; > > gimple_test_f is is_gimple_condexpr, and it eventually calls > operation_could_trap_p (GT). > > 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. > > I was thinking about two other possible solutions: > > 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. > > 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. > > What would be a better way to proceed here? 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. 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. Richard. >