[Bug target/112919] LoongArch: Alignments in tune parameters are not precise and they regress performance

["chenglulu at loongson dot cn" <gcc-bugzilla@gcc.gnu.org>]

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

--- 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? :)
> > > > 
> > > > 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 the
> > > > test time will be longer.
> > > > I will reply here as soon as the results are available.
> > > 
> > > Can we determine on LA664 if the current default alignment is better than
> > > not aligning at all?  Coremarks results suggest the current default is even
> > > 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 random
> > > fluctuation) we can disable the aligning for LA664.
> > > 
> > > (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?
> 
> 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 Mar
> we can just use the best we'll find.

Well, the results should be available before GCC14 is released. It also seems
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.