[Pixman] [PATCH v2 2/3] build: use '-mloongson-mmi' for Loongson MMI.

[Matt Turner]

On Sat, Feb 22, 2020 at 6:34 AM YunQiang Su <wzssyqa at gmail.com> wrote:
>
> Shiyou Yin <yinshiyou-hf at loongson.cn> 于2020年2月22日周六 下午9:26写道：
> >
> > >-----Original Message-----
> > >From: Adam Jackson [mailto:ajax at redhat.com]
> > >Sent: Friday, February 21, 2020 11:33 PM
> > >To: Yin Shiyou; pixman at lists.freedesktop.org
> > >Subject: Re: [Pixman] [PATCH v2 2/3] build: use '-mloongson-mmi' for Loongson MMI.
> > >
> > >On Thu, 2020-02-20 at 22:23 +0800, Yin Shiyou wrote:
> > >> It's suggested to use '-mloongson-mmi' to enable MMI.
> > >> To keep compatible with old processor, '-mloongson-mmi' will be
> > >> setted for Loongson-3A only.
> > >
> > >The pattern we've used for other CPUs is to build support for as many
> > >ISA extensions as possible, unless they are explicitly disabled.
> > >Distributions tend to want to set their own minimum ISA levels, and if
> > >they wanted to assert -mloongson-mmi they would already have added it
> > >to CFLAGS globally.
> > >
> > >Do you have any performance data for this change?
> > >
> > >If setting -mloongson-mmi means the compiler can do useful
> > >autovectorization, then that's probably true for other arches too (eg
> > >amd64 vs avx2), and we should support this kind of thing more
> > >generically. But as it stands I don't think this patch is a good idea.
> > >
> > First, that's introduce the history of '-march=loongson2f' and '-mloongson-mmi'.
> > From loongson2f start, mmi is supported by loongson processor.
>
> Yes. So that's why when we code, we should be very careful, especially
> when we work on base part of a OS, just like pixman.
> One, history mistake will make all of the people painful.
>
> An exmaple is about time_t on 32bit system.
>
> > Unfortunately, the compiler's support for MMI extention is not standardized.
> > Gcc compiler use '-march=loongson2f' for loongson2f at first, but from Loongson-3A,
> > opcode of mmi instruction has changed, and '-march=loongson3a' is in replaced.
>
> That is the reason some of Loongson's extensions make upstream unhappy.
> You need be always very careful when you design a CPU.
> 如履薄冰. No zuo no die.
>
> > From last year, compile option for mmi instruction has been standardized.
> > Just like -mmsa for mips MSA. (MMI,LSX,LASX is Loongson SIMD extention.)
> > -mloongson-mmi   for MMI (-march=loongson3a still works, but -mloongson-mmi is recommended for new processors except Loongson2f. )
> > -mloongson-sx     for LSX
> > -mloongson-asx    for LASX
>
> That is good news.
>
> >
> > Second, back to this patch itself.
> > I meet a problem when compile pixman on my Loongson3a with gcc, MMI can't be enabled.
> > configure check failure: " linking mips:loongson_2f module with previous mips:gs464 modules"
> > It can be solved by assign LS_CFLAGS="-mloongson-mmi" while config.
> > So I submit this patch in hope that no need to assign LS_CFLAGS explicitly.
> > This won't have much impact on performance as I know.
>
> Here is not about performance. You made a bad design, that is burden of history.

If you're referring to using -march=loongson2f in configure.ac, then I
should point out that that was my choice, and I don't really know what
other options I had -- or even have today. As far as I know,
-march=loongson* was, until recently, the only way to enable the SIMD
instructions, and worse, if I recall correctly Loongson 2E and 2F are
not entirely binary compatible themselves!

The only stable Loongson system I've ever had is a Yeeloong -- 2F, so
it's what I chose. Like I said in another email, I even tried building
pixman-mmx.c multiple times with different -march=... values, linking
them all into libpixman, and choosing which to execute at runtime, but
binutils does not allow linking object files that are compiled with
different -march=... values on mips for reasons I do not know.