From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id EC5C63858D35 for ; Fri, 31 Jul 2020 11:36:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EC5C63858D35 Received: by mail-ed1-x533.google.com with SMTP id i26so18822220edv.4 for ; Fri, 31 Jul 2020 04:36:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=94iWmLr46xKAW3nU5w6EBZ+gUWP+qdj4Y1Hc1Pe8fME=; b=tHvbCsyg8tUkmm/UNy2aKTzOZz5rj+nkAzJdvcgvP05ATGBxy0+kuDGEGdR9g2MIvs 7iXumPYZmlg+aXfRGNwp5lvAErARowpBtQlgDnWcGTMm/Ueg1Lx/730IbSbk+QdnYKwH 5xteesFMUNwhLROkloVZbB4T+bwHWH7i1FW7C7Swm96Zm2jPgPZrWtuXl5xl/X1pjClr OLmUIgU25wabWyZRfK8G83UxyXxAwQv2+lIdqB/UfCrwkoOi7k9XfaYgFXlQdudtc8C5 reTGVD8mDB5IP7IPf3nzW+eBATsTZPg8eOz1T9vmQ72twfVS33TX0kFhhy8EWZ3/+DYK WsIw== X-Gm-Message-State: AOAM530gmcovEoMjDkiK8epf2OsMW1j5oXWHepT4Yy1ia2JYCY5p5nJt ZN7q/ZRAXq2i1/fxrEdIiQc0E3e1P6MXaTO2wzw= X-Google-Smtp-Source: ABdhPJwk5+Z2ojkVY5RsLOjv0VK6sObHAYEs+48sDKxxSrLEANsmpu2oowBuIuATe1ZjzmFkp0TZHCgeedcrXKWwl1M= X-Received: by 2002:a50:e1c5:: with SMTP id m5mr3562466edl.138.1596195362997; Fri, 31 Jul 2020 04:36:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Fri, 31 Jul 2020 13:35:51 +0200 Message-ID: Subject: Re: VEC_COND_EXPR optimizations To: Marc Glisse Cc: GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.8 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 11:36:05 -0000 On Thu, Jul 30, 2020 at 9:49 AM Marc Glisse wrote: > > When vector comparisons were forced to use vec_cond_expr, we lost a number > of optimizations (my fault for not adding enough testcases to prevent > that). This patch tries to unwrap vec_cond_expr a bit so some > optimizations can still happen. > > I wasn't planning to add all those transformations together, but adding > one caused a regression, whose fix introduced a second regression, etc. > > Using a simple fold_binary internally looks like an ok compromise to me. > It remains cheap enough (not recursive, and vector instructions are not > that frequent), while still allowing more than const_binop (X|0 or X&X for > instance). The transformations are quite conservative with :s and folding > only if everything simplifies, we may want to relax this later. And of > course we are going to miss things like a?b:c + a?c:b -> b+c. > > In terms of number of operations, some transformations turning 2 > VEC_COND_EXPR into VEC_COND_EXPR + BIT_IOR_EXPR + BIT_NOT_EXPR might not > look like a gain... I expect the bit_not disappears in most cases, and > VEC_COND_EXPR looks more costly than a simpler BIT_IOR_EXPR. > > I am a bit confused that with avx512 we get types like "vector(4) > " with :2 and not :1 (is it a hack so true is 1 and not > -1?), but that doesn't matter for this patch. > > Regtest+bootstrap on x86_64-pc-linux-gnu + (with + { + tree rhs1, rhs2 = NULL; + rhs1 = fold_binary (op, type, @1, @3); + if (rhs1 && is_gimple_val (rhs1)) + rhs2 = fold_binary (op, type, @2, @3); ICK. I guess a more match-and-simplify way would be (with { tree rhs1, rhs2; gimple_match_op op (gimple_match_cond::UNCOND, op, type, @1, @3); if (op.resimplify (NULL, valueize) && gimple_simplified_result_is_gimple_val (op)) { rhs1 = op.ops[0]; ... other operand ... } now in theory we could invent some new syntax for this, like (simplify (op (vec_cond:s @0 @1 @2) @3) (vec_cond @0 (op:x @1 @3) (op:x @2 @3))) and pick something better instead of :x (:s is taken, would be 'simplified', :c is taken would be 'constexpr', ...). _Maybe_ just (simplify (op (vec_cond:s @0 @1 @2) @3) (vec_cond:x @0 (op @1 @3) (op @2 @3))) which would have the same practical meaning as passing NULL for the seq argument to simplification - do not allow any intermediate stmt to be generated. The other "simple" patterns look good, you can commit them separately if you like. Richard. > 2020-07-30 Marc Glisse > > PR tree-optimization/95906 > PR target/70314 > * match.pd ((c ? a : b) op d, (c ? a : b) op (c ? d : e), > (v ? w : 0) ? a : b, c1 ? c2 ? a : b : b): New transformations. > > * gcc.dg/tree-ssa/andnot-2.c: New file. > * gcc.dg/tree-ssa/pr95906.c: Likewise. > * gcc.target/i386/pr70314.c: Likewise. > > -- > Marc Glisse