On Sat, Feb 22, 2020 at 6:34 AM YunQiang Su <[email protected]> wrote: > > Shiyou Yin <[email protected]> 于2020年2月22日周六 下午9:26写道： > > > > >-----Original Message----- > > >From: Adam Jackson [mailto:[email protected]] > > >Sent: Friday, February 21, 2020 11:33 PM > > >To: Yin Shiyou; [email protected] > > >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. _______________________________________________ Pixman mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/pixman
