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

[Shiyou Yin]

>-----Original Message-----

>From: YunQiang Su [mailto:wzssyqa at gmail.com]

>Sent: Thursday, February 27, 2020 11:38 AM

>To: Shiyou Yin

>Cc: pixman at lists.freedesktop.org

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

> 

>在 2020-02-26三的 17:45 +0800，Shiyou Yin写道：

>> > -----Original Message-----

>> > From: YunQiang Su [mailto:wzssyqa at gmail.com]

>> > Sent: Saturday, February 22, 2020 10:20 PM

>> > To: Shiyou Yin

>> > Cc: pixman at lists.freedesktop.org

>> > Subject: Re: [Pixman] [PATCH v2 2/3] build: use '-mloongson-mmi'

>> > for Loongson MMI.

>> >

>> > Shiyou Yin <yinshiyou-hf at loongson.cn> 于2020年2月22日周六 下午9:19写道：

>> > > First let's clarify what exactly compatibility mean, or what

>> > > specific goals we want to achieve.

>> > >

>> > > If it's just ensure the features of new code consistent with old

>> > > compilation and hardware environment, then this patch will works

>> > > well.

>> > >

>> >

>> > Of course that is not enough. If it is the only your goal, why sent

>> > this patch?

>> >

>> > > If it is going to make sure MMI can be enabled and works well on

>> > > each cases, it may be not easy.

>> > >

>> > > Guess compiler? Compiler check can only ensure the compile option

>> > > is supported or not

>> >

>> > yq at ls3b1500:~$ gcc -march=loongson3a -dM -E - < /dev/null | grep mmi

>> > #define __mips_loongson_mmi 1

>> >

>> > So, you can try to compile (-c) the bellow code to test whether the

>> > compiler has MMI enabled

>> >

>> > #ifndef __mips_loongson_mmi

>> > # error "Loongson MMI is not supported"

>> > #endif

>> >

>> > For example, mipsel-linux-gnu-gcc is a generic mips compiler and

>> > target mips32r2; and the user set CC="mipsel-linux-gnu-gcc

>> > -march=loongson3", Your test can still pass.

>> >

>> >

>> > > and then MMI instruction can be compiled. We can't ensure the

>> > > binary can works well on each hardware, especially in the case of

>> > > cross-compilation.

>> >

>> > Sure, that why you need to obey users configure, by LS_CFLAGS or CC

>> > or the default configure of compiler.

>> >

>> > > Almost all latest gcc support "-march=loongson2f" and "-

>> > > march=loongson3a"

>> > > and "-mloongson-mmi". So which kind of compiler we will set

>> > > LS_CFLAGS as -mloongson-mmi?

>> >

>> > due to history reason, the default value of LS_CFLAGS should be keep

>> > as 2f, and user can set it by

>> >

>> > LS_CFLAGS="-mloongson-mmi" ./configure -- blabla

>> >

>> > > Guess CPU is always used in runtime check, it should be added in

>> > > the optimization code but not in configure. The configure just

>> > > need to ensure the compile process can finished successfully, So

>> > > it may check compiler support some options or not and then

>> > > enable/disable the features.

>> > >

>> >

>> > Generally, we don't need to guess the BUILD_MACHINE's cpu in

>> > buildtime.

>> >

>> 

>> If this is what you mean, I will agree and update the patch.

>> It should be noted that we still need to manually specify appropriate

>> option to enable MMI correctly.

>> The only change is now we have two new ways(2 & 3) to specify this

>> option:

>> 1) LS_CFLAGS

>> 2) CC

>> 3)compiler's default cflags, such as COLLECT_GCC_OPTIONS of gcc.

>> 

>> 

>> Diff is as follows:

>> 

>> diff --git a/configure.ac b/configure.ac index 1ca3974..be9212d 100644

>> --- a/configure.ac

>> +++ b/configure.ac

>> @@ -78,7 +78,7 @@ AC_C_BIGENDIAN

>>  AC_C_INLINE

>> 

>>  dnl PIXMAN_LINK_WITH_ENV(env-setup, program, true-action, false-

>> action)

>> -dnl

>> +

>>  dnl Compiles and links the given program in the environment setup by

>> env-setup  dnl and executes true-action on success and false-action on

>> failure.

>>  AC_DEFUN([PIXMAN_LINK_WITH_ENV],[dnl

>> @@ -273,7 +273,27 @@ dnl

>> =====================================================================

>> ======

>>  dnl Check for Loongson Multimedia Instructions

>> 

>>  if test "x$LS_CFLAGS" = "x" ; then

>> -    LS_CFLAGS="-march=loongson2f"

>> +  # check default cflags to set LS_CFLAGS  # Has -mloongson-mmi or

>> + -march=loongson3a : LS_CFLAGS="-mloongson-

>> mmi"

>> +  # else : LS_CFLAGS="-march=loongson2f"

>> +  xserver_save_CFLAGS=$CFLAGS

>> +  CFLAGS=" $LS_CFLAGS $CFLAGS -I$srcdir"

>> +AC_RUN_IFELSE([AC_LANG_SOURCE([[

>> +int main () {

>> +  /* check default cflags */

>> +  #ifndef __mips_loongson_mmi

>> +  /* No -mloongson-mmi,-march=loongson3a and -march=loongson2f */

>> +  return 0;

>> +  #else

>> +    #ifdef _MIPS_ARCH_LOONGSON2F

>> +    /* Has -march=loongson2f */

>> +    return 0;

>> +    #else

>> +    /* Has -mloongson-mmi or -march=loongson3a */

>> +    return 1;

>> +    #endif

>> +  #endif

>> +}]])], LS_CFLAGS="-mloongson-mmi", LS_CFLAGS="-march=loongson2f")

> 

>I am sorry. The setting to Loongson2f by default is not done by you.

>It is my mistake.

> 

>Anyway, since you are working on that patch:

> 

>In the first patch, you setting 3A/MMI default instead of 2F. If that patch was merged, Debian/OpenWrt

>etc will be broken just now.

>In fact in most case the set 2F, it will not broken Debian, since the the next link test will fail: 2F cannot

>interlink with mips64r2/mips32r2. aka LS_CFLAGS is set to 2F will only break

>mips3/mips2 OS.

>Set LS_CFLAGS to -mloongson-mmi will break almost *ALL* os.

>Is it your mistake?

> 

>In the second patch: you read CPU info from /proc/cpuinfo: WTF

> 

>I asked that you should keep loongson options not set by default serveral times.

>In your *3rd* patch, you still keep them set by default.

> 

>I told you that you can determine OS/CC behivors by predefined macros, You still cannot understand after I

>have a loooooong talk with you by wechat! WTF.

> 

>Almost (if not all) of Loongson guys are *RUBBISH*.

>Let me sign this mail by my PGP key.

> 

>>  fi

>> 

>>  have_loongson_mmi=no

>> 

>> 

 

I really don't know what's your problem.

Whether you're still going to be so rude or not, this will be my last reply to you.

What I've always trying to tell you is that there is no way to set up the right LS_CFLAGS to enable MMI

by compile check if the default CFLAGS doesn't contain MMI-related options.

So, that is why you added cc_enable_mmi_2f/3a in your patch, and it will not 

be set to yes if the default CFLAGS does not contain MMI-related options.

 

What I originally wanted to do was to automatically enable MMI without specifying LS_CFLAGS/CC, 

but not improving the whole default setting process, they are different things.

 

Your patch improved the MMI configure check, It’s good and I will submit it first.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/pixman/attachments/20200229/6eeeaba3/attachment-0001.htm>