From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 98DD9C433ED for ; Thu, 22 Apr 2021 04:56:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 698CC61437 for ; Thu, 22 Apr 2021 04:56:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229569AbhDVE53 (ORCPT ); Thu, 22 Apr 2021 00:57:29 -0400 Received: from mga04.intel.com ([192.55.52.120]:39194 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229568AbhDVE53 (ORCPT ); Thu, 22 Apr 2021 00:57:29 -0400 IronPort-SDR: u5pVqcOY5k1ZcnA2CcAHWzBUI1A1FJt5EYjUknh7CgrmC2r4mvCWEmLswqy4FgwJmgQo5demIU i+AGNNqNuKGw== X-IronPort-AV: E=McAfee;i="6200,9189,9961"; a="193706731" X-IronPort-AV: E=Sophos;i="5.82,241,1613462400"; d="scan'208";a="193706731" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Apr 2021 21:56:54 -0700 IronPort-SDR: pbzoieAdQorR3gyLkt0RwccDrXShMAFuMDtTcHEEX0c9RmKCxx5vGt+2HZxzLX1rooPqy9MJ+i qpcJWG249neg== X-IronPort-AV: E=Sophos;i="5.82,241,1613462400"; d="scan'208";a="427779549" Received: from shao2-debian.sh.intel.com (HELO [10.239.13.11]) ([10.239.13.11]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Apr 2021 21:56:51 -0700 Subject: Re: [kbuild-all] Re: [mips-linux:mips-next 98/101] arch/mips/include/asm/div64.h:74:3: error: inconsistent operand constraints in an 'asm' To: "Maciej W. Rozycki" , "Huang, Ying" , Thomas Bogendoerfer , kernel test robot Cc: kbuild-all@lists.01.org, linux-mips@vger.kernel.org References: <202104220420.qh7kOCR1-lkp@intel.com> From: Rong Chen Message-ID: <7cea940f-4d9d-2c5e-e2a6-ff3dfba220f5@intel.com> Date: Thu, 22 Apr 2021 12:55:49 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On 4/22/21 7:26 AM, Maciej W. Rozycki wrote: > On Thu, 22 Apr 2021, kernel test robot wrote: > >> fs/xfs/libxfs/xfs_alloc_btree.c: In function 'xfs_allocbt_free_block': >>>> arch/mips/include/asm/div64.h:74:3: error: inconsistent operand constraints in an 'asm' >> 74 | __asm__("divu $0, %z1, %z2" \ >> | ^~~~~~~ > Umm, I forgot we do support MIPSr6, unlike microMIPSr6. > > I think this asm can go and GCC will do equally well with plain C code. > Or actually marginally better, as preliminary benchmarking shows, owing to > a slightly better instruction scheduling. Code produced for test_div64 is > also slightly smaller for some reason. That's at least for the ISAs up to > R5, which do have DIVU. Well, I can't complain. > > For R6 compiled code will work, but separate DIVU and MODU instructions > will be produced, which are also interlocked, so scalar implementations > will likely not perform as well as older ISAs with their asynchronous MD > unit. Likely still faster then the generic algorithm though. > > Thomas: I'll collect new figures and respin the series. Please do drop > the original series then; I think there's no point to fix it up and we'll > be better by starting afresh. > > Ying: I take it you'll know what to do to get the bot updated. As it > happens it uses the old MIPS/Linux mailing > list address, which has been long deprecated and then stopped working > altogether mid Jan this year. I have updated the cc appropriately with > this reply, but would you please amend whatever the bot requires for > further notices to be sent to instead? > > Maciej Hi Maciej, Thanks for the advice, we have updated the mailing list. Best Regards, Rong Chen From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============7924591291623785442==" MIME-Version: 1.0 From: Rong Chen To: kbuild-all@lists.01.org Subject: Re: [mips-linux:mips-next 98/101] arch/mips/include/asm/div64.h:74:3: error: inconsistent operand constraints in an 'asm' Date: Thu, 22 Apr 2021 12:55:49 +0800 Message-ID: <7cea940f-4d9d-2c5e-e2a6-ff3dfba220f5@intel.com> In-Reply-To: List-Id: --===============7924591291623785442== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 4/22/21 7:26 AM, Maciej W. Rozycki wrote: > On Thu, 22 Apr 2021, kernel test robot wrote: > >> fs/xfs/libxfs/xfs_alloc_btree.c: In function 'xfs_allocbt_free_block= ': >>>> arch/mips/include/asm/div64.h:74:3: error: inconsistent operand constr= aints in an 'asm' >> 74 | __asm__("divu $0, %z1, %z2" \ >> | ^~~~~~~ > Umm, I forgot we do support MIPSr6, unlike microMIPSr6. > > I think this asm can go and GCC will do equally well with plain C code. > Or actually marginally better, as preliminary benchmarking shows, owing to > a slightly better instruction scheduling. Code produced for test_div64 is > also slightly smaller for some reason. That's at least for the ISAs up to > R5, which do have DIVU. Well, I can't complain. > > For R6 compiled code will work, but separate DIVU and MODU instructions > will be produced, which are also interlocked, so scalar implementations > will likely not perform as well as older ISAs with their asynchronous MD > unit. Likely still faster then the generic algorithm though. > > Thomas: I'll collect new figures and respin the series. Please do drop > the original series then; I think there's no point to fix it up and we'll > be better by starting afresh. > > Ying: I take it you'll know what to do to get the bot updated. As it > happens it uses the old MIPS/Linux mailing > list address, which has been long deprecated and then stopped working > altogether mid Jan this year. I have updated the cc appropriately with > this reply, but would you please amend whatever the bot requires for > further notices to be sent to instead? > > Maciej Hi Maciej, Thanks for the advice, we have updated the mailing list. Best Regards, Rong Chen --===============7924591291623785442==--