From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id 7D1273858D1E for ; Fri, 13 Oct 2023 15:50:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7D1273858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-9b2cee55056so394350466b.3 for ; Fri, 13 Oct 2023 08:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697212203; x=1697817003; 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=Ekjn2bOwd/69OJXF1bpPPqitW0ay/YYs4FnUJxPBmj0=; b=aYOIuBOcEiyoxV1s6rfVKYR/0BdCF+L5R7eNL5zZQKFQrjm8JPNSFpjlgdRPMDcMpA 8VBrNl6VwycW0W2BaGgRF0x11KFfesrWIUUqeKR2SqS+nAKxX/m+7ng8qgVmP0ZPZlqk DsEn9Mtl4WaeeQcUrgACoeSwYDodY+v670waBmWmLiiyhClbQd0e9v7YOrZyOFbaqCo1 SGX0rKehzbI5HanzHn0m0qwhT6CvXacDOa0Oxq9cW8W3VV8rwjmwt20AiGhlm9DTQ3kq fWA7V60b1MWB9u1plLL9/XQ6tLnl8NMcdqGJn0kb9WIu5U6isibyFupXiY1pX9EJbACW eGHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697212203; x=1697817003; 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=Ekjn2bOwd/69OJXF1bpPPqitW0ay/YYs4FnUJxPBmj0=; b=IBobwAPKQxZ4yusSQJxhPXBrnrSuG+fVG64IoljktCTMPF3WXPNxSSV0cdzhSX6F1t 94BvLC2Xt539U35ilcMtNyQEqJUzPelD0hYy7tRmfUEevceUPumx/FIBysZlsbPG+iKs jAplwG5CX/+PDqBGx1Y2oAR50J3uuOaZEhxnY1esD27rgHFLAfqMHg1/HuybxGvIo3fr ZkV10sRQ7O/VP1DlD7BNY8ozA6tE5p7IvIhLf2h+XcJpHM3J2WI8nXrWZqCPqWMIHI6j urhfAi3plKSHoNptmy8dbXEAvo4FNXhlqaxiOsmMP8CxLeuPSRU7LRZ9EcZQpP0YDj/D kN7g== X-Gm-Message-State: AOJu0YwHS60hFBaJg1K4X0xkSIYA/h2a1KQjuQSC4NN6ncIVnyngbowY sq4vCYSB6dqlG9t4pmtSTz9S/ZuVGWY= X-Google-Smtp-Source: AGHT+IE01KYt8cfWWNAm1rVQLirfKFHatxZ/LKiQjeoBD3wqBoKAp4pPCqslyBaxpwVxV5Lz/tqbHQ== X-Received: by 2002:a17:906:7949:b0:9bd:ff07:a58a with SMTP id l9-20020a170906794900b009bdff07a58amr1035572ejo.53.1697212202810; Fri, 13 Oct 2023 08:50:02 -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 a6-20020a1709062b0600b009ae57888718sm12458006ejg.207.2023.10.13.08.50.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Oct 2023 08:50:02 -0700 (PDT) Message-ID: <38b16b69-1b82-420c-839b-d82278515f10@gmail.com> Date: Fri, 13 Oct 2023 17:50:01 +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: Robin Dapp via Gcc-patches , richard.sandiford@arm.com References: <4b77e155-0936-67d6-ab2d-ae7ef49bfde0@gmail.com> <4afb967d-96ea-7e74-1a35-c86aa5a5ffa6@gmail.com> From: Robin Dapp In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.1 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > Why are the contents of this if statement wrong for COND_LEN? > If the "else" value doesn't matter, then the masked form can use > the "then" value for all elements. I would have expected the same > thing to be true of COND_LEN. Right, that one was overly pessimistic. Removed. > But isn't the test whether res_op->code itself is an internal_function? > In other words, shouldn't it just be: > > if (internal_fn_p (res_op->code) > && internal_fn_len_index (as_internal_fn (res_op->code)) != -1) > return true; > > maybe_resimplify_conditional_op should already have converted to an > internal function where possible, and if combined_fn (res_op->code) > does any extra conversion on the fly, that conversion won't be reflected > in res_op. I went through some of our test cases and believe most of the problems are due to situations like the following: In vect-cond-arith-2.c we have (on riscv) vect_neg_xi_14.4_23 = -vect_xi_13.3_22; vect_res_2.5_24 = .COND_LEN_ADD ({ -1, ... }, vect_res_1.0_17, vect_neg_xi_14.4_23, vect_res_1.0_17, _29, 0); On aarch64 this is a situation that matches the VEC_COND_EXPR simplification that I disabled with this patch. We valueized to _26 = vect_res_1.0_17 - vect_xi_13.3_22 and then create vect_res_2.5_24 = VEC_COND_EXPR ; This is later re-assembled into a COND_SUB. As we have two masks or COND_LEN we cannot use a VEC_COND_EXPR to achieve the same thing. Would it be possible to create a COND_OP directly instead, though? I tried the following (not very polished obviously): - 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 (!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); + } + else if (seq && *seq && is_gimple_assign (*seq)) + { + new_op.code = gimple_assign_rhs_code (*seq); + new_op.type = res_op->type; + new_op.num_ops = gimple_num_ops (*seq) - 1; + new_op.ops[0] = gimple_assign_rhs1 (*seq); + if (new_op.num_ops > 1) + new_op.ops[1] = gimple_assign_rhs2 (*seq); + if (new_op.num_ops > 2) + new_op.ops[2] = gimple_assign_rhs2 (*seq); + + new_op.cond = res_op->cond; + + gimple_match_op bla2; + if (convert_conditional_op (&new_op, &bla2)) + { + *res_op = bla2; + // SEQ should now be dead. + return true; + } + } This would make the other hunk (check whether it was a LEN and try to recreate it) redundant I hope. I don't know enough about valueization, whether it's always safe to do that and other implications. On riscv this seems to work, though and the other backends never go through the LEN path. If, however, this is a feasible direction it could also be done for the non-LEN targets? Regards Robin