From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 297F63858C35; Fri, 1 Mar 2024 08:14:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 297F63858C35 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1709280895; bh=1/Lpe5uEfo/bgbmMjqjoyB3QzxQ9BKNNnfAqc1hUidQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WwwDbdzQ4lIY6EoW6fxdHKJYfJ3sfQmJmZOW3glNo2Jur0TjoJjfaE8jhatcIyfMx GQiUNTYxkxa9ldJYhsk+nmk54XXfIYRRQhSc9/FQCXF1dMMDpnZriIhkCXSweEdpMe 0KUuQs7J9eZDKdgci7f7JuOo09xcBM+9ZeNzdEIg= From: "chenglulu at loongson dot cn" 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:14:53 +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: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D112919 --- Comment #10 from chenglulu --- (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 on the > > spec score, I am currently testing it on a single-channel machine, so t= he > > 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 is ev= en > worse than not aligning, but arguably Coremarks is far different from real > workloads. However if the current default is not better than not aligning > (or the difference is only marginal and is likely covered up by some rand= om > 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 machine= , I need to judge the fluctuation of the spec and then let's see if the default alignment is set? In addition, I also tested it on the 3A5000 again, and the results will be available around March 15th. The conclusion of coremark from our team leader Xu Chenghua is that '-falign-labels' have a regular effect on the performance of coremark, and = when the value of '-falign-labels' is greater than 4 bytes, the performance decreases significantly.=