From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88369 invoked by alias); 9 Sep 2019 08:43:57 -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 88361 invoked by uid 89); 9 Sep 2019 08:43:57 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-14.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-lj1-f195.google.com Received: from mail-lj1-f195.google.com (HELO mail-lj1-f195.google.com) (209.85.208.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Sep 2019 08:43:55 +0000 Received: by mail-lj1-f195.google.com with SMTP id a4so11872379ljk.8 for ; Mon, 09 Sep 2019 01:43:55 -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=hBwJXOLhU9hwIO+fCAjQXWgvWYsup8lHjtETZjYfZvU=; b=kt6LnX8RLTYZGC58ORmSLCEC5x36jkKwt70Tz1A9XPNGE1IHfjfZKrcVSKDBCcKn3P YtctZhJtF9tY1aIsClUOcqH5P6JyAfh7RxmxlUh8HI3EJo7lQ4JfxDfchtP847thsH7g 6Pb12cSbvFgIlrp97z7mHlsu5/j8Ht6ug+txGDCKk0yXYR/ouKrdUsYrAio/d0Wggqkm kFFxHb+1y66HihuSa3wopb+i2hXWAsfMDZ47Zdfh9tti1/5U3jYK0UihsRbOsBzAFIM/ xr9rY3FplJK5lsqWktbcCsZS0654kWLIL8ymoOuK1vLPKlxwqs8PH7O5djq3Bl6kfU+o 1NqA== MIME-Version: 1.0 References: <20190905111019.8951-1-iii@linux.ibm.com> <20190905111019.8951-2-iii@linux.ibm.com> <6DCAE849-42F6-4538-8AE1-EE091F01FC3B@linux.ibm.com> In-Reply-To: <6DCAE849-42F6-4538-8AE1-EE091F01FC3B@linux.ibm.com> From: Richard Biener Date: Mon, 09 Sep 2019 08:43:00 -0000 Message-ID: Subject: Re: [PATCH v3 1/9] Allow COND_EXPR and VEC_COND_EXPR condtions to trap To: Ilya Leoshkevich Cc: GCC Patches , Richard Sandiford , Segher Boessenkool , "Joseph S. Myers" , Andreas Krebbel , Robin Dapp Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00468.txt.bz2 On Fri, Sep 6, 2019 at 5:45 PM Ilya Leoshkevich wrote: > > > Am 06.09.2019 um 13:07 schrieb Richard Biener : > > > > On Thu, Sep 5, 2019 at 1:10 PM Ilya Leoshkevich wrote: > >> > >> Right now gimplifier does not allow VEC_COND_EXPR's condition to trap > >> and introduces a temporary if this could happen, for example, generating > >> > >> _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 GENERIC > >> > >> VEC_COND_EXPR < (*b > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 }) , > >> { -1, -1, -1, -1 } , > >> { 0, 0, 0, 0 } > > >> > >> This is not necessary and makes the resulting GIMPLE harder to analyze. > >> In particular, one of the next patches in series needs to get to > >> VEC_COND_EXPR's comparison code, which is not possible when a temporary > >> is introduced. > >> > >> This patch takes special care to avoid introducing trapping comparisons > >> in GIMPLE_COND. They are not allowed, because they would require 3 > >> outgoing edges (then, else and EH), which is awkward to say the least. > >> Therefore, computations of such conditions should live in their own basic > >> blocks. > > > > Comments inline (thanks for the work btw) > > > >> #endif /* GCC_GIMPLE_EXPR_H */ > >> diff --git a/gcc/gimple.c b/gcc/gimple.c > >> index 633ef512a19..fd14fbec15e 100644 > >> --- a/gcc/gimple.c > >> +++ b/gcc/gimple.c > >> @@ -2144,6 +2144,8 @@ gimple_could_trap_p_1 (gimple *s, bool include_mem, bool include_stores) > >> op = gimple_assign_rhs_code (s); > >> if (get_gimple_rhs_class (op) == GIMPLE_BINARY_RHS) > >> div = gimple_assign_rhs2 (s); > >> + else if (op == COND_EXPR || op == VEC_COND_EXPR) > >> + op = TREE_CODE (gimple_assign_rhs1 (s)); > > > > I think this is not correct since we can have > > > > int i = fp > 1. ? intval1 : intval2 > > > > and thus FLOAT_TYPE_P (t) is wrong. You need to do > > > > t = TREE_TYPE (op); > > > > as well I think. > > Doesn't this mean there is a problem with the existing logic too? If `s` > is > > int i = fp > 1.; > > then > > t = gimple_expr_type (s); > > would give us BOOLEAN_TYPE instead of REAL_TYPE. Yeah, that looks broken as well. > > Also, the new logic will probably be a bit more complicated, since I > will first have to do: > > tree cond = gimple_assign_rhs1 (s); > > then see if `cond` is not e.g. an SSA_NAME, but rather a tcc_comparison, > and only then > > t = TREE_TYPE (TREE_OPERAND (cond, 0)) > > So I'd rather send a new version before merging this :-) Fine with me ;) Richard.