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 ABFE33858C53; Fri,  1 Mar 2024 08:49:34 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ABFE33858C53
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1709282974;
	bh=pQrxQUgigwkfatYaWanE+za6Qd3QwcU6kay4vc4Mb5M=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=ZHuHw7Jjyfdri7pBfMKk6KGHT1qwrP/KxJu4J8llB2bzAzwb8FTd4g+DKqbS4pE9B
	 j79rhB/8Kzy/I6pMlGCzQBEO3KeC2TE4WXkuA+XX0bufTcRxginieMDEx1VrzYKa3X
	 5n69gqyMvmIvAqfov9yvV/I28YUA2NuukNhIrByY=
From: "chenglulu at loongson dot cn" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/112919] LoongArch: Alignments in tune parameters are not
 precise and they regress performance
Date: Fri, 01 Mar 2024 08:49:16 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: chenglulu at loongson dot cn
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-112919-4-CW8PgYnhZM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-112919-4@http.gcc.gnu.org/bugzilla/>
References: <bug-112919-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=3D112919

--- Comment #12 from chenglulu <chenglulu at loongson dot cn> ---
(In reply to Xi Ruoyao from comment #11)
> (In reply to chenglulu from comment #10)
> > (In reply to Xi Ruoyao from comment #9)
> > > (In reply to chenglulu from comment #8)
> > > > (In reply to Xi Ruoyao from comment #7)
> > > > > Any update? :)
> > > >=20
> > > > Well, I haven't run it yet. Since this does not have a big impact o=
n the
> > > > spec score, I am currently testing it on a single-channel machine, =
so the
> > > > test time will be longer.
> > > > I will reply here as soon as the results are available.
> > >=20
> > > Can we determine on LA664 if the current default alignment is better =
than
> > > not aligning at all?  Coremarks results suggest the current default i=
s even
> > > worse than not aligning, but arguably Coremarks is far different from=
 real
> > > workloads. However if the current default is not better than not alig=
ning
> > > (or the difference is only marginal and is likely covered up by some =
random
> > > fluctuation) we can disable the aligning for LA664.
> > >=20
> > > (Maybe we and the HW engineers have done some repetitive work or even=
 some
> > > work cancelling each other out :(. )
> > On March 8th I should be able to get the test results on the 3A6000 mac=
hine,
> > I need to judge the fluctuation of the spec and then let's see if the
> > default alignment is set?
>=20
> I just mean if we cannot get a decisive result before GCC 14 we may just
> turn off alignment.  But if we can get a decisive result as expected in M=
ar
> we can just use the best we'll find.

Well, the results should be available before GCC14 is released. It also see=
ms
that the setting of 3A5000 needs to be changed, because the value of
'-falign-labels' was affected by the macro ASM_OUTPUT_ALIGN_WITH_NOP in the
previous test.=