From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) by sourceware.org (Postfix) with ESMTPS id C9A433857C66 for ; Fri, 6 Oct 2023 12:28:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C9A433857C66 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-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-4053c6f0db8so18363675e9.3 for ; Fri, 06 Oct 2023 05:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696595305; x=1697200105; 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=2X7xOQMH1bNJr3pioSFhkFlYbuMrLnloDv53oSm/Wr0=; b=IINOV7QUJe4ndBp1M8YZcWnXMSU39qLu9Dr5jLXMVmCFaEniFhC4styuXUDT16X9Ec v4tiZBIGG/VwRREoPxCbFZEkMyrFhSmTp0ApMNTEco3EbirW/p0l4sQOau7KrR+CKP80 aa+Z8XUUrnnO7Mv2IhaAkeRBEeu8fCOX12Ore/lRNrnJ31qeYk1JeJw5wZEtpMeHuFPS RUCTN7NmueO/1YqRRcAz5FP4C/G15J7n/pLz+b9ZbUO8y6gI4aX+Z2T5AKEL3nRdVVNb Ze5l1HTLTgWUmJ5xlThnsC7fELdNGt2ybbGJd/vBduYCjLixa4SkbQkI5XyL3aYzTY4b kqag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696595305; x=1697200105; 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=2X7xOQMH1bNJr3pioSFhkFlYbuMrLnloDv53oSm/Wr0=; b=Lt4MdU+MIXM1Zsu+hQS6c4pX9NOwVSPOgRoXMEOuulLQ1cl/XX/dwMvYn9dweJAnn+ XzTT8uZZwyPJv8ZDI0PKWgcorbutoQA/4dAudfwpWMdai7fs3JHAIhrEDCCDUzmGOSnb O72Gwv5UjiXaYRS5IN3LLCHehtBy0yq9PBRO+JGbgaH9g9xT4Kl3xBXOTybdwkUhccxl PQat3whIxjdED5qPyj/wzMzRaD+u8ZJHRk8FHi0IBzD5/9WRty/N2LdB6Mp9XQD4KHIU rzEEWbw+0aMZ6sG+6h2KT/CUSkdBm7qHmUmvAMc9pNmzmR2JyJTyXg95eTEIN8Hmhjkm tBMg== X-Gm-Message-State: AOJu0YznLd6UG9/sL/W1oJDJ7vEzN1Nbr9Ybr81pouyDPO57rzS4hec7 ZKn3cSXN5FNG6f8sN8VsbIM= X-Google-Smtp-Source: AGHT+IGzOtU5ZeE01firkyZmhg4y79AZFkaBpyvQmerEy/JD8J+iTnhrtFZZ1h5Ftnj2qyHrvV46ZQ== X-Received: by 2002:a7b:c858:0:b0:404:737a:17d with SMTP id c24-20020a7bc858000000b00404737a017dmr6608841wml.9.1696595305245; Fri, 06 Oct 2023 05:28:25 -0700 (PDT) Received: from [192.168.1.23] (ip-046-005-130-086.um12.pools.vodafone-ip.de. [46.5.130.86]) by smtp.gmail.com with ESMTPSA id m21-20020a056000025500b003296beb1436sm941329wrz.18.2023.10.06.05.28.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Oct 2023 05:28:24 -0700 (PDT) Message-ID: <187932bd-3a22-acdb-025b-e17ca3408e3a@gmail.com> Date: Fri, 6 Oct 2023 14:28:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Cc: rdapp.gcc@gmail.com, Tamar Christina , gcc-patches Subject: Re: [PATCH] ifcvt/vect: Emit COND_ADD for conditional scalar reduction. Content-Language: en-US To: Richard Biener References: <0193b63e-98dc-42bc-cd33-485361ea50bf@gmail.com> <671a575c-02ff-071b-967e-2e93d8986c1a@gmail.com> <85b08273-7eea-be3f-f08a-edf0780d36a7@gmail.com> From: Robin Dapp In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,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: > ... here we probably get PLUS_EXPR for MINUS_EXPR above but IIRC > for MINUS_EXPR the !as_initial case should return positive zero. > > Can you double-check? You're referring to the canonicalization from a - CST to a + -CST so that the neutral op would need to change with it? Argh, good point. >From what I can tell the only difference for MINUS_EXPR is that we negate the reduction operand and then just continue as if it were a PLUS_EXPR (which is the right thing to do also for +-0.0?). At least I didn't observe a canonicalization and we don't call neutral_op_for_reduction in between. What we do have, though, is for the fully-masked case (you added that recently): if (LOOP_VINFO_FULLY_MASKED_P (loop_vinfo)) { vector_identity = build_zero_cst (vectype_out); if (!HONOR_SIGNED_ZEROS (vectype_out)) ; else { gcc_assert (!HONOR_SIGN_DEPENDENT_ROUNDING (vectype_out)); vector_identity = const_unop (NEGATE_EXPR, vectype_out, vector_identity); } } So for /* Handle MINUS by adding the negative. */ if (reduc_fn != IFN_LAST && code == MINUS_EXPR) { tree negated = make_ssa_name (vectype_out); We might need a similar assert gcc_assert (HONOR_SIGNED_ZEROS (vectype_out) && !HONOR_SIGN_DEPENDENT_ROUNDING (vectype_out));? Apart from that the only call with !as_inital is in vect_create_epilog_for_reduction. I just instrumented it with an assert (false) but i386.exp doesn't trigger it at all. Regards Robin