From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 04E8E385841B; Thu, 22 Feb 2024 11:10:27 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 04E8E385841B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1708600228;
	bh=Zo3m1qUqBaLTsmQ0ptpC8JBt1Q1MqigmjzzC3sJ15t0=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=BDZCUZ8nilgnmD7/7GmpDnnP+hv7KbFUc6A21IArV4a4HgIDUkcRsKfHnjwN/R5Zw
	 WrddH0lfe7vKajYgQYssI+oJq5hUJXLzAGyDZPlVhFFWcgZ/kU6IkGXXBBXjCm6uSx
	 jlIZH6Gj4TvU1eRM/mm3fo3IedZ5HoOcTiKP+QVU=
From: "acoplan at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/111770] predicated loads inactive lane values
 not modelled
Date: Thu, 22 Feb 2024 11:10:25 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: acoplan at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-111770-4-u3pV8uy3cU@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-111770-4@http.gcc.gnu.org/bugzilla/>
References: <bug-111770-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D111770

--- Comment #4 from Alex Coplan <acoplan at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> As said X + 0. -> X is an invalid transform with FP unless there are no
> signed zeros (maybe also problematic with sign-dependent rounding).

Yeah, I was thinking about the integer case above.

>=20
> I think we agree to define .MASK_LOAD to zero masked elements.  When we n=
eed
> something else we need to add an explicit ELSE value.  That needs documen=
ting
> of course and also possibly testsuite coverage - I _think_ you should be =
able
> to do a GIMPLE frontend testcase for this.

Sounds good, thanks.

>=20
> Note this behavior would extend to .MASK_GATHER_LOAD as well as
> the load-lanes and -len variants.
>=20
> Unfortunately we do not have _any_ internals manual documentation for
> internal functions - but you can backtrack to the optabs documentation
> where this would need documenting.
>=20
> Now, if-conversion could indeed elide the .COND_ADD for integers.  It's
> problematic there only because of signed overflow undefinedness, so
> you shouldn't see it for 'unsigned' already, and adding zero is safe.

Can you elaborate on this a bit? Do you mean to say that the .COND_ADD is o=
nly
there to avoid if-conversion introducing UB due to signed overflow? ISTM it=
's
needed for correctness even without that, as the addend needn't be guarante=
ed
to be zero in the general case.

> if-conversion would need to have an idea of all the ranges involved here
> so it might be a bit sophisticated to get it right.

Does what I suggested above make any sense, or do you have in mind a differ=
ent
way of handling this in if-conversion? I'm wondering how ifcvt should deter=
mine
that the addend is zero in the case where the predicate is false.

Thanks=