From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id 23E133875457 for ; Tue, 17 Oct 2023 11:39:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 23E133875457 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 23E133875457 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::429 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697542784; cv=none; b=qrxKvJw6uUi2msKNL0SP29KbJtBLUUwUWYPBWu+5Ft4wNd9cYJvsGxNd/3jkiFFigRewMn9SMvod4gCtkVHewVZyNhOd/HQTjVEAdEjCwUiz4C+ss9JeX+QEZr/0K/b9CMLE2RaQWE3h4lY9X4GvWuwCmy9RpUxe1pWvtEQUTcM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697542784; c=relaxed/simple; bh=ZJYy5fvL9RYDiBYgUGa+kxH5FG22DGyxoLG+fOQRzvg=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=k1gQcJVyjL1Zmgo1i41FIdeeMLgDHa+bFSKgQD292h9OvEmkESdXNR5jGRhDfReusCo8vW/RK9ny+ir40oEW+WkAjZTjwnhilqxs6tM8DjH1vcxn9uSGveLlY/nO2t4UjjVEH2Kx/CUt0s3/MhCAeRHq+4otoqbjmm1vs/ksq2o= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-3296b49c546so4495770f8f.3 for ; Tue, 17 Oct 2023 04:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697542780; x=1698147580; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Lj6hlYywb3JJHBvGBeBJWY2VEtMasxBnnV2WUmukUIM=; b=AlyM9Y9bc+j7j03qdc6dKtoNxnLHuC1rfxPyGWQJa93hZd9STm45ob6kecxQCWqPfe H2Vc8iSkkxYBbvCusE7MB7UKjjcKdK6/mV7QfAdETPDVIA6mArdjNdhzk6vOkuvzxG5y nHzQiafKoLyylYfLYSkI1m31AEIq/dsjrR/JeldU3mns4fB611rzMY2QhjsAZ9tjXvQ2 475yXMiGrKpCtz7du7JCGffsdfK9Pb+EtZ1R+MeBx0ylmqP+lWsHKuSnFfgBGyggXHEK reXC2LQ6PS/BbcnA/GnZmq6q2eJaPNESsJkDnVWfYwviU7f+WU+a2fGKcKYXb//6KdO/ 8eiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697542780; x=1698147580; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Lj6hlYywb3JJHBvGBeBJWY2VEtMasxBnnV2WUmukUIM=; b=Ccx6n5JOdQh3TNexeSk5PrlulUmkQd0S/UQCq6wVPs10R8r/f4+Wn6u1Y7XH1nXeVv 5DyKqlB83E+lE8MquLqqO0FMwnp6z6FbtMxQ07KFZ5nbRbzqy+nZxdbRwc/0I82KqK71 sgeVWX/HoohrRF/MRSwmCN25L/rmzptVwLKopYm3RB4WpfDNZVFxDwf10czGFrpIti3S g8sPMqK6m5yuFgteKSdfu2BvrCXIZcO96E7jCDhogxbKt0X3OIn7Cdcnu05j00wK7FB8 1f2SClYF3NcGKuZGdXQG9PgN1812xS4dRk8cCZ0qvqDiZzPOBJgu3tgWhK7h4JE3kicQ 9jkA== X-Gm-Message-State: AOJu0Yz5b21yYgEiOskJRX4O5QUerl8CEK4L9wtdMbhGG5Qrk11ngqli ZZ69KiavOmlo2hilrtPBOzg= X-Google-Smtp-Source: AGHT+IFltWR3os2frtZgY9h1Lad4y5vhjRYdUVIjysq75Q7ambQZ5Rq84F/Kw11acSPi8XD379utDw== X-Received: by 2002:a5d:6b83:0:b0:32d:984e:97b2 with SMTP id n3-20020a5d6b83000000b0032d984e97b2mr1858879wrx.46.1697542780293; Tue, 17 Oct 2023 04:39:40 -0700 (PDT) Received: from [192.168.1.23] (ip-046-223-203-173.um13.pools.vodafone-ip.de. [46.223.203.173]) by smtp.gmail.com with ESMTPSA id l12-20020adfe9cc000000b003231ca246b6sm1494131wrn.95.2023.10.17.04.39.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Oct 2023 04:39:40 -0700 (PDT) Message-ID: <03a8c49e-af19-4b38-966b-e9ddae4863f5@gmail.com> Date: Tue, 17 Oct 2023 13:39:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: rdapp.gcc@gmail.com Subject: Re: [PATCH] gimple-match: Do not try UNCOND optimization with COND_LEN. Content-Language: en-US To: Richard Biener , Robin Dapp via Gcc-patches , richard.sandiford@arm.com References: <4b77e155-0936-67d6-ab2d-ae7ef49bfde0@gmail.com> <4afb967d-96ea-7e74-1a35-c86aa5a5ffa6@gmail.com> <38b16b69-1b82-420c-839b-d82278515f10@gmail.com> From: Robin Dapp In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-9.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,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: >> I don't know much about valueisation either :) But it does feel >> like we're working around the lack of a LEN form of COND_EXPR. >> In other words, it seems odd that we can do: >> >> IFN_COND_LEN_ADD (mask, a, 0, b, len, bias) >> >> but we can't do: >> >> IFN_COND_LEN (mask, a, b, len, bias) >> >> There seems to be no way of applying a length without also finding an >> operation to perform. > > Indeed .. maybe - _maybe_ we want to scrap VEC_COND_EXPR for > IFN_COND{,_LEN} to be more consistent here? So, yes we could define IFN_COND_LEN (or VCOND_MASK_LEN) but I'd assume that there would be a whole lot of follow-up things to consider. I'm wondering if we really gain something from the the round-trip via VEC_COND_EXPR when we eventually create a COND_(LEN_)_OP anyway? Sure, if the target doesn't have the particular operation we would want a VEC_COND_EXPR. Same if SEQ is somehow more complicated. So the IFN_COND(_LEN) =? VCOND_MASK(_LEN) discussion notwithstanding, couldn't what I naively proposed be helpful as well? Or do we potentially lose optimizations during the time where e.g. a _foo = a BINOP b VEC_COND_EXPR (cond, foo, else) has not yet been converted into a COND_OP? We already create COND_OPs for the other paths (via convert_conditional_op) so why not for this one? Or am I missing some interdependence with SEQ? FWIW I did a full bootstrap and testsuite run on the usual architectures showing no changes with the attached patch. Regards Robin Subject: [PATCH] gimple-match: Create COND_OP directly if possible. This patch converts simplified sequences into conditional operations instead of VEC_COND_EXPRs if the target supports them. This helps for len-masked targets which cannot directly use a VEC_COND_EXPR in the presence of length masking. gcc/ChangeLog: * gimple-match-exports.cc (directly_supported_p): Define. (maybe_resimplify_conditional_op): Create COND_OP directly. * gimple-match.h (gimple_match_cond::gimple_match_cond): Initialize length and bias. --- gcc/gimple-match-exports.cc | 40 ++++++++++++++++++++++++++++--------- gcc/gimple-match.h | 7 +++++-- 2 files changed, 36 insertions(+), 11 deletions(-) diff --git a/gcc/gimple-match-exports.cc b/gcc/gimple-match-exports.cc index b36027b0bad..ba3bd1450db 100644 --- a/gcc/gimple-match-exports.cc +++ b/gcc/gimple-match-exports.cc @@ -98,6 +98,8 @@ static bool gimple_resimplify5 (gimple_seq *, gimple_match_op *, tree (*)(tree)) static bool gimple_resimplify6 (gimple_seq *, gimple_match_op *, tree (*)(tree)); static bool gimple_resimplify7 (gimple_seq *, gimple_match_op *, tree (*)(tree)); +bool directly_supported_p (code_helper, tree, optab_subtype); + /* Match and simplify the toplevel valueized operation THIS. Replaces THIS with a simplified and/or canonicalized result and returns whether any change was made. */ @@ -299,22 +301,42 @@ maybe_resimplify_conditional_op (gimple_seq *seq, gimple_match_op *res_op, } } - /* If the "then" value is a gimple value and the "else" value matters, - create a VEC_COND_EXPR between them, then see if it can be further - simplified. */ + /* If the condition represents MASK ? THEN : ELSE, where THEN is a gimple + value and ELSE matters, create a VEC_COND_EXPR between them, then see + if it can be further simplified. + For COND_LEN masking, try to create a COND_LEN_OP directly in case + SEQ contains a supportable operation. */ gimple_match_op new_op; if (res_op->cond.else_value && VECTOR_TYPE_P (res_op->type) && gimple_simplified_result_is_gimple_val (res_op)) { - new_op.set_op (VEC_COND_EXPR, res_op->type, - res_op->cond.cond, res_op->ops[0], - res_op->cond.else_value); - *res_op = new_op; - return gimple_resimplify3 (seq, res_op, valueize); + /* If a previous simplification was pushed to SEQ + and we can convert it to a COND_OP directly, do so + in order to save a round-trip via VEC_COND_EXPR -> COND_OP. */ + if (seq && *seq && is_gimple_assign (*seq) + && directly_supported_p (gimple_assign_rhs_code (*seq), res_op->type, + optab_scalar)) + { + res_op->code = gimple_assign_rhs_code (*seq); + res_op->num_ops = gimple_num_ops (*seq) - 1; + res_op->ops[0] = gimple_assign_rhs1 (*seq); + if (res_op->num_ops > 1) + res_op->ops[1] = gimple_assign_rhs2 (*seq); + if (res_op->num_ops > 2) + res_op->ops[2] = gimple_assign_rhs2 (*seq); + } + else if (!res_op->cond.len) + { + new_op.set_op (VEC_COND_EXPR, res_op->type, + res_op->cond.cond, res_op->ops[0], + res_op->cond.else_value); + *res_op = new_op; + return gimple_resimplify3 (seq, res_op, valueize); + } } - /* Otherwise try rewriting the operation as an IFN_COND_* call. + /* Otherwise try rewriting the operation as an IFN_COND_(LEN_)* call. Again, this isn't a simplification in itself, since it's what RES_OP already described. */ if (convert_conditional_op (res_op, &new_op)) diff --git a/gcc/gimple-match.h b/gcc/gimple-match.h index bec3ff42e3e..55c771d560f 100644 --- a/gcc/gimple-match.h +++ b/gcc/gimple-match.h @@ -32,7 +32,9 @@ public: enum uncond { UNCOND }; /* Build an unconditional op. */ - gimple_match_cond (uncond) : cond (NULL_TREE), else_value (NULL_TREE) {} + gimple_match_cond (uncond) + : cond (NULL_TREE), else_value (NULL_TREE), len (NULL_TREE), + bias (NULL_TREE) {} gimple_match_cond (tree, tree); gimple_match_cond (tree, tree, tree, tree); @@ -56,7 +58,8 @@ public: inline gimple_match_cond::gimple_match_cond (tree cond_in, tree else_value_in) - : cond (cond_in), else_value (else_value_in) + : cond (cond_in), else_value (else_value_in), len (NULL_TREE), + bias (NULL_TREE) { } -- 2.41.0