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 C23EF384BC17; Wed,  6 Jan 2021 13:16:25 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C23EF384BC17
From: "rsandifo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/98542] Redundant loads in vectorised loop
Date: Wed, 06 Jan 2021 13:16: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: 11.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rsandifo at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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-98542-4-ulaG2AhU7v@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-98542-4@http.gcc.gnu.org/bugzilla/>
References: <bug-98542-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
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jan 2021 13:16:25 -0000

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

--- Comment #2 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.or=
g> ---
(In reply to Richard Biener from comment #1)
> What do you mean with "twice"?  We seem to do interleaving here (on x86_6=
4)
> but since 'v' and 'i' have different types they do not belong to the same
> interleaving chain (but we have two that "interleave" - heh).
>=20
> x.c:6:21: note:   =3D=3D=3D vect_analyze_data_ref_accesses =3D=3D=3D
> x.c:6:21: note:   Detected single element interleaving _3->v step 16
> x.c:6:21: note:   Detected single element interleaving _3->i step 16
>=20
> so if that's the main complaint then a testcase w/o gather is probably
> more relevant at first?  For x86 the two loads are offsetted by one
> element, for your asm that looks like to be the same (x5 vs x0).
Yeah, that's the main complaint.  Because we implement the interleaving
with load-lanes, the load of the =E2=80=9Cv=E2=80=9D vector provides the co=
rresponding
=E2=80=9Ci=E2=80=9D vector as a byproduct.  But rather than use that =E2=80=
=9Ci=E2=80=9D vector,
we load the =E2=80=9Ci=E2=80=9D fields a second time, which again provides =
a vector
of the following =E2=80=9Cv=E2=80=9D fields.  In other words, we effectivel=
y do
four loads and four permutes in order to get two vectors.

This is in contrast to targets that use separate loads and permutes,
where we only emit permutes for the vectors that we use, and where
we stand a chance of CSEing four loads into three.

It also means that we force peeling for gaps when it shouldn't be
necessary.

With the follow-on mentioned (=E2=80=9Ci=E2=80=9D being 32-bits rather than=
 64) we'd
still want to treat the structure access as a single group, even though
the fields are different sizes.

Using gather seems fine to me, but then I'm biased :-)=