From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id F0D6D3858C31 for ; Wed, 25 Oct 2023 22:32:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F0D6D3858C31 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F0D6D3858C31 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698273126; cv=none; b=rR18ZMRFQu4RsOlRezqoaob8R7BieIWksdCU+lip5hygwfQxOvSaJj9PJKscAF1IO9Q9SzsG3lS2xxJFE9n7i5mZOI++6yNuzUhiQ2znJ0O1YUGcRKBAzzETkoHQHNAehNyborOvhGKSAq6Kh7F/vvvcnqYHU00g15NiFIHBlXM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698273126; c=relaxed/simple; bh=cHJvzlEJPanr/PVdDlZrui1bpmENU7gNXTiZfCzOUx4=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=svuCeEj0S0QbK3o8Ay7tAv6NIExxv6hnJMax0pTypFnwJ+ZmHaKiuHeZfaXlVXvGiKnemNhHtOS+bySZ+FCQFWSWoHsfjeQSQUzVRloKIfLXL9aENtBXf9jJ4foAm216Ay0fC7RwNSTjVjS13/tQH3fFnAreOcyS+gGGUX6GF/k= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 32B1A2F4; Wed, 25 Oct 2023 15:32:46 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BFFAF3F64C; Wed, 25 Oct 2023 15:32:03 -0700 (PDT) From: Richard Sandiford To: =?utf-8?B?6ZKf5bGF5ZOy?= Mail-Followup-To: =?utf-8?B?6ZKf5bGF5ZOy?= ,gcc-patches , rdapp.gcc , rguenther , richard.sandiford@arm.com Cc: gcc-patches , rdapp.gcc , rguenther Subject: Re: [PATCH] internal-fn: Add VCOND_MASK_LEN. References: Date: Wed, 25 Oct 2023 23:32:02 +0100 In-Reply-To: (=?utf-8?B?IumSn+WxheWTsiIncw==?= message of "Thu, 26 Oct 2023 06:10:56 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-16.1 required=5.0 tests=BAYES_00,BODY_8BITS,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: =E9=92=9F=E5=B1=85=E5=93=B2 writes: >>> Which one is right? > Hi, Richard. Let me explain this situation. > > Both situations are possible. It's depending on the 'ELSE' value whether = it is unitialized value. > > For reduction case: > > for (int i =3D 0; i < n; i++) > result +=3D a[i] > > The trailing elements should be well-defined, keep the original value. Ot= herwise, it will cause run-time issue. > > For integer DIV operation: > > for (int i =3D 0; i < n; i++) > a[i] =3D a[i] / b[i]; > > The trailling elements are DON'T care (or undefined), I will use unitiali= zed value in 'ELSE' value. > Then later 'expand' stage will expand it into "clobber scratch" RTL. OK, in that case it sounds like we're talking about PR110751. The gimple semantics are that the COND_LEN operates on all lanes of the mode (and the md.texi documentation should be fixed). But if the else value is undefined, we can simplify: IFN_COND_LEN_IOR (mask, a, 0, undef, len, bias) to "a". That's not really a property of COND_LEN though. The same thing applies to plain IFN_COND_IOR. If the fold reduces to a selection between two values, and one of them is undefined, we can pick the other. (Although we'd need to think a little carefully about that, c.f. llvm's distinction between undef and poison.) Thanks, Richard