[{"id":3683811,"web_url":"http://patchwork.ozlabs.org/comment/3683811/","msgid":"","list_archive_url":null,"date":"2026-04-29T05:48:23","subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","submitter":{"id":808,"url":"http://patchwork.ozlabs.org/api/people/808/","name":"Uros Bizjak","email":"ubizjak@gmail.com"},"content":"On Wed, Apr 29, 2026 at 4:26 AM Kewen Lin wrote:\n>\n> Hi Uros,\n>\n> 在 2026/4/28 15:46, Uros Bizjak 写道:\n> > On Wed, Mar 25, 2026 at 7:17 AM Kewen Lin wrote:\n> >>\n> >> Hi,\n> >>\n> >> This patch enables new x86 CPU vendor HYGON ID detection\n> >> and adds c86-4g series c86-4g-m{4,6,7} processor supports.\n> >> Without such support, if users use -march=native option on\n> >> HYGON machines, they can get some old arch like core2, it\n> >> would be suboptimal. It also enables -m{arch,tune}=c86-4g\n> >> -m{4,6,7} supports. Based on the hardware characteristics,\n> >> appropriate cost models and tuning parameters are provided.\n> >>\n> >> New machine description files are introduced: c86-4g.md is\n> >> used to describe the pipeline for c86-4g-m4 and c86-4g-m6,\n> >> while c86-4g-m7.md describes the pipeline for c86-4g-m7.\n> >> To better model some pipeline information, it introduces\n> >> new attrs c86_attr and c86_decode by following existing\n> >> practice.\n> >>\n> >> Bootstrapped and regtested on hygon c86-4g-m4 and c86-4g-m7\n> >> machine, as well as a cfarm x86-64 machine.\n> >>\n> >> It's late stage 4 now, I guess it has to be next stage 1\n> >> materials? If so, is it ok for trunk once gcc-17 stage1\n> >> opens?\n> >>\n> >> BR,\n> >> Kewen\n> >> -----\n> >>\n> >> From: Xin Liu \n> >> Co-authored-by: Zhaoling Bao \n> >> Signed-off-by: Xin Liu \n> >> Signed-off-by: Zhaoling Bao \n> >>\n> >> gcc/ChangeLog:\n> [snip]\n> >> gcc/testsuite/ChangeLog:\n> >>\n> >> * gcc.target/i386/builtin_target.c: Add handling for HYGON CPUs by\n> >> validating the vendor and invoking HYGON-specific CPU detection.\n> >> * gcc.target/i386/funcspec-56.inc: Test function target attribute on\n> >> {arch,tune}=c86-4g-m{4,6,7}.\n> >> * g++.target/i386/mv33.C: New test.\n> >\n> > I didn't look at the new .md files and mostly mechanical changes in\n> > .md files in detail, they all look good to me modulo some issues,\n> > noticed below. Target specific tune definitions and costs also LGTM.\n> > Common code follows established practices and is also well tested in\n> > the testsuite.\n> >\n> > + (set (attr \"c86_attr\")\n> > + (cond [(eq_attr \"alternative\" \"2,3\")\n> > + (const_string \"sselogic\")\n> > + ]\n> > + (const_string \"*\")))\n> >\n> > the above can be simplified with if_then_else, which is preferred RTX\n> > for single cond RTX:\n> >\n> > (set (attr \"c86_attr\")\n> > (if_then_else (eq_attr \"alternative\" \"2,3\")\n> > (const_string \"sselogic\")\n> > (const_string \"*\")))\n> >\n> > here and at other places.\n> >\n> > + (set (attr \"c86_attr\")\n> > + (cond [(eq_attr \"alternative\" \"8,9,10,11\")\n> > + (if_then_else (and (match_test \"SSE_REG_P (operands[0])\")\n> > + (match_test \"SSE_REG_P (operands[1])\"))\n> > + (const_string \"vpmovx\")\n> > + (const_string \"*\"))\n> > + ]\n> > + (const_string \"*\")))\n> >\n> > The above change applies to:\n> >\n> > (define_insn \"*zero_extendsidi2\"\n> > [(set (match_operand:DI 0 \"nonimmediate_operand\"\n> > \"=r,?r,?o,r ,o,?*y,?!*y,$r,$v,$x,*x,*v,?r,?k\")\n> > (zero_extend:DI\n> > (match_operand:SI 1 \"x86_64_zext_operand\"\n> > \"0 ,rm,r ,rmWz,0,r ,m ,v ,r ,m ,*x,*v,?k,?km\")))]\n> >\n> > but both operands are SSE_REG_P only for alternatives 10 and 11, so\n> > the above test can be simplified to just:\n> >\n> > (set (attr \"c86_attr\")\n> > (if_then_else (eq_attr \"alternative\" \"10,11\")\n> > (const_string \"vpmovx\")\n> > (const_string \"*\")))\n> >\n> > Other than that, the patch is OK.\n>\n> Thanks for the review!!\n>\n> There are some changes in v2 comparing to v1:\n> - In function host_detect_local_cpu: relaxed CPU model check\n> from model == 7 to model >= 7 to make any potential future\n> model adopt M7 at least.\n> - Replaced multiple uses of cond with if_then_else where only\n> a single condition is involved as suggested.\n> - Removed redundant checks as alternative constraints ensure\n> as suggested.\n> - Fixed a few alignment formatting issues on c86_attr lines in mds.\n> - Removed some unnecessary empty lines.\n>\n> Bootstrapped and regtested as before.\n>\n> Is it ok for trunk?\n\nOK.\n\nThanks,\nUros.","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=Y8+qyV4r;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (2048-bit key,\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=Y8+qyV4r","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com","sourceware.org; spf=pass smtp.mailfrom=gmail.com","server2.sourceware.org;\n arc=pass smtp.remote-ip=209.85.208.169"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g55w92xjzz1yHv\n\tfor ; Wed, 29 Apr 2026 15:49:11 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 9C5DD4BBC0CA\n\tfor ; Wed, 29 Apr 2026 05:49:06 +0000 (GMT)","from mail-lj1-f169.google.com (mail-lj1-f169.google.com\n [209.85.208.169])\n by sourceware.org (Postfix) with ESMTPS id 706D84BA2E11\n for ; Wed, 29 Apr 2026 05:48:37 +0000 (GMT)","by mail-lj1-f169.google.com with SMTP id\n 38308e7fff4ca-3922b35e69cso31427821fa.0\n for ; Tue, 28 Apr 2026 22:48:37 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 9C5DD4BBC0CA","OpenDKIM Filter v2.11.0 sourceware.org 706D84BA2E11"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 706D84BA2E11","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 706D84BA2E11","ARC-Seal":["i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1777441717; cv=pass;\n b=ATLR0cSrmkya2PUqWYN46HX5faAEqOkofJCiqM/010aP0rIvM2Sy+ptQCum+iFNQmW9J4FXZ5ONBSV8Axg47njzjMQ4tVRuYmYzZjJmShI+UQQ2fA1zqlP8TH7UAmSiQadQ9sxSWL4OvTC+Ybbs9JMjx0X5GGV5xx90GkcZxYPc=","i=1; a=rsa-sha256; t=1777441716; cv=none;\n d=google.com; s=arc-20240605;\n b=EN2kpUT/ZYSDBlH0qDwoVagSaoWqbMHjlL/rprE+JyiXh/q5aNl5gxcBJow8sccB/I\n Lh1mjkPQb/cmUF9aggwrHKitYVNiGD8qglqwIFuwIu3sdGezORHQHlzWiBdypsueNq/q\n Z1tOvstsZqjVhS6DOtL8YmK2AwQxHzzrPGKGz1llb867UPxXa/V7r3DqBxAhhDSe5PQq\n GZGHzhmuBQrlarCxIM47RT258ey4ekOrQWGcsnHG1C5B6GgtZrCOpOiYQTWI7w/Up1GE\n Q3pmTxbclHSgCTCxilMhAdCfzqkF7m771Gya/ffz1567a73ytJYrc9LVJp4IqhrWpVJk\n BTVA=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777441717; c=relaxed/simple;\n bh=JRF1O6ynK1Pv4LV3OENLyQfokxOYPLx1UNl1SF2pdhc=;\n h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;\n b=UN65G707XpUDPa/3kfWMlZctyorGQRTLb4EQjx/da2GkvWGVF1lJoPDFUJxViJs8j6P4YqIAHGYwJBq7900Ac5WBc6mB0UCGOdQ+ER+6B7mCaVbq1i1+VG8P6r3knNxzIaYZTz0brLloH609eSu6Cerxwi6BmjZEC0qfKYRBmYM=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=P7Q0kq9rFBFY8sWVHDjwJEzMnIR6tXhsDr+qBjjVugA=;\n fh=dUXPNm/oCgruhME2pgG9vlsmDpjzJC28qZ8zocppvCI=;\n b=iiZLDoUX7b82JWYqtJX5nvuP+v1ew1cAJQWNZmhzOm9NmigF2dijr9SkKzp3je4RCs\n FXertyAj3lf0zjMHaIVyHvOFjh8DwnEVVL1anbxOJTrEwzcsovfsek9VWDtxilBls5yk\n Q7V4DrCT/E+3S+Ek/jo2l23NyMPOY63r/auRQQ3O9QTv7VUrw3M1FW5p0RFHA7upx3rY\n GodgK641IltSAr0Xmb9XLIxhWK1gro+RwEwQbg6Kh3CUw876DaOtfVkrwFkof3NXhyPr\n DHxZwS2WQX+FIZVGn9C0AJJ/M1VPN1lvipvFmOtQWuAe+fg5x9Uv4leWf78TS612Ye5d\n T8NQ==; darn=gcc.gnu.org"],"ARC-Authentication-Results":["i=2; server2.sourceware.org","i=1; mx.google.com; arc=none"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1777441716; x=1778046516; darn=gcc.gnu.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=P7Q0kq9rFBFY8sWVHDjwJEzMnIR6tXhsDr+qBjjVugA=;\n b=Y8+qyV4roNmRXl3NtEAJZcDbJuskP3YXaeTyHoaaKby6E0G8j80/9b5Rvc9WZ+zDPF\n ODWPghqn5kILPyRaRKa2wAz/E6tL7PSRzZz6HMe2xYAQik7O+Od2/SuzZ6e1FmpQ2/yw\n Nrs9GQ6B2ALNHcXPN/atOkuqgPPj/s3UHEGqiQWUa+YN1w8iVy8Aoap2IGoKgTox4IGw\n LaBfgMA0Sh0ubSQQ1V08+R5rv68CNdSL34ZFSVtAB4FJlBMYNIUnD0qbNvZ5w+UtnMK7\n dPC/gY/UhpwCdrSbotcreJ6GZe4IJa0zh6ekwtFreLI1KXtUjwaf1Omw4HHJJBeM3qLD\n vY5A==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1777441716; x=1778046516;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=P7Q0kq9rFBFY8sWVHDjwJEzMnIR6tXhsDr+qBjjVugA=;\n b=fpesgSVwC4nfmn4OLr4wUsKfz8F48Fq6yCDzZ809IAdVDBnXr4Es44HZ4rhO4XR0zU\n 9XnJE58x3q03PK1DpGjbV09zQiqeArZghBtefjHoxFdvq/JlsrcSA1JG7DAnQz3OZvnz\n gKon4AyqYXKx0n9LFPOr8HGs5XMZp0QQwNbWG41gX86pYjqMpJEH5vJtcM1tTRk6lQz1\n YGgFSp1Gh34giXE9WTINipfACuuXfWmFVkYuBIrXxxJTZSuDK7ol7S3nO6EFSinBD9Mg\n zmyvu5o3GIl125rgZraBmWRorWyY1AbW2+fDisEs5HqR+iaw1i9Phnfk+Z/y8D5OfN2D\n OC2w==","X-Gm-Message-State":"AOJu0Yxn9hzhM4erSsYNp1eWEazrRHKFSgswgtJaFO8p+gVVAhbMff28\n LiXMTusTxr7NGAxP0jSzygXs1B+K3Vuu2R5lxYJvJYRa9SGO2JSamuPS3gtrvQhwiXPqtUfLolB\n hy6s+cI2n6ywmxDcrjGh5jP3FBCTwfRk=","X-Gm-Gg":"AeBDiesIxMOFeWYMs/U//TWuDl5KmUBoGHt8gBNnqmKZDh4qOdopDBJSBIFfk3RQGQE\n mF68Dm/cCqi5IWm/tAHoAa+hsWtBXuIUyJ4N+Jqu0ah1A13T/QhstpI/MUf/XgtptRB+h4wQetv\n pKougJ9prltc5IuEPne0gy73w9RjEPfAedhsgXCKJERq0aLwRFG+81/yM56kVOnwOv5U5YRYcRw\n WeGl49Y23dG2nPqi2dQ5+eYwx0i2Lr5me70lMqCfdvRhJr3Ts8Xra6wtn0XEHA2eM/O9jz3tjxS\n FztFXOSbrJ8Ti9uDnXkepe+a8kB9WkeTV5zVucatTp1L8Fd/l8gkPYgwYxrq4mHbM+2tUwSYWVi\n 6JGicksQUoOopSvBgBoT9oCnW+16bqd7qlUMnREoZ8kVhqw==","X-Received":"by 2002:a2e:bc8a:0:b0:38e:4810:4f36 with SMTP id\n 38308e7fff4ca-39240d08ccfmr19960291fa.9.1777441715729; Tue, 28 Apr 2026\n 22:48:35 -0700 (PDT)","MIME-Version":"1.0","References":"<387794d9-199a-4373-97be-5e70e772e014@hygon.cn>\n \n ","In-Reply-To":"","From":"Uros Bizjak ","Date":"Wed, 29 Apr 2026 07:48:23 +0200","X-Gm-Features":"AVHnY4LTZ43yJsymnA9WK69wtAFR1mSTJrQk0Cqq1G4ZB0IhKpProFqm5-pSO54","Message-ID":"\n ","Subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","To":"Kewen Lin ","Cc":"\"gcc-patches@gcc.gnu.org\" ,\n Liulxx ,\n Qingkuan Lai , Feng Xue ,\n \"hubicka@ucw.cz\" ,\n \"hongtao.liu@intel.com\" ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3684278,"web_url":"http://patchwork.ozlabs.org/comment/3684278/","msgid":"","list_archive_url":null,"date":"2026-04-29T21:24:03","subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","submitter":{"id":4362,"url":"http://patchwork.ozlabs.org/api/people/4362/","name":"Rainer Orth","email":"ro@CeBiTec.Uni-Bielefeld.DE"},"content":"Hi Uros,\n\n>> There are some changes in v2 comparing to v1:\n>> - In function host_detect_local_cpu: relaxed CPU model check\n>> from model == 7 to model >= 7 to make any potential future\n>> model adopt M7 at least.\n>> - Replaced multiple uses of cond with if_then_else where only\n>> a single condition is involved as suggested.\n>> - Removed redundant checks as alternative constraints ensure\n>> as suggested.\n>> - Fixed a few alignment formatting issues on c86_attr lines in mds.\n>> - Removed some unnecessary empty lines.\n>>\n>> Bootstrapped and regtested as before.\n>>\n>> Is it ok for trunk?\n>\n> OK.\n\nbetween yesterday and today, I saw an increase in bootstrap times\nbetween 37 and 75%:\n\n* i686-pc-linux-gnu, -j128\t1:03:03 -> 1:50:00\n\n* i386-pc-solaris2.11, -j28\t3:08:11.19 -> 4:18:22.77\n\nwhile the x86_64-pc-linux-gnu times are virtually unchanged. It seems\nlikely that this patch is the culprit. Is anyone else seeing the same?\n\nThanks.\n\tRainer","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=cebitec.uni-bielefeld.de header.i=@cebitec.uni-bielefeld.de\n header.a=rsa-sha256 header.s=20200306 header.b=S72HELUK;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (2048-bit key,\n unprotected) header.d=cebitec.uni-bielefeld.de header.i=@cebitec.uni-bielefeld.de\n header.a=rsa-sha256 header.s=20200306 header.b=S72HELUK","sourceware.org; dmarc=none (p=none dis=none)\n header.from=CeBiTec.Uni-Bielefeld.DE","sourceware.org;\n spf=pass smtp.mailfrom=cebitec.uni-bielefeld.de","server2.sourceware.org;\n arc=none smtp.remote-ip=129.70.160.84"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g5VgX44Wtz1yHv\n\tfor ; Thu, 30 Apr 2026 07:24:39 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id E163E4BB8F71\n\tfor ; Wed, 29 Apr 2026 21:24:36 +0000 (GMT)","from smtp.CeBiTec.Uni-Bielefeld.DE (smtp.CeBiTec.Uni-Bielefeld.DE\n [129.70.160.84])\n by sourceware.org (Postfix) with ESMTPS id DF0C74BB24F0\n for ; Wed, 29 Apr 2026 21:24:05 +0000 (GMT)","from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1])\n by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id AE65FC2DC4;\n Wed, 29 Apr 2026 23:24:04 +0200 (CEST)","from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1])\n by localhost (smtp.cebitec.uni-bielefeld.de [127.0.0.1]) (amavisd-new,\n port 10026)\n with ESMTP id 9-yvT-uirYNt; Wed, 29 Apr 2026 23:24:04 +0200 (CEST)","from manam.CeBiTec.Uni-Bielefeld.DE (p508551ea.dip0.t-ipconnect.de\n [80.133.81.234]) (Authenticated sender: ro)\n by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPSA id 36854C2DC3;\n Wed, 29 Apr 2026 23:24:04 +0200 (CEST)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org E163E4BB8F71","OpenDKIM Filter v2.11.0 sourceware.org DF0C74BB24F0"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org DF0C74BB24F0","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org DF0C74BB24F0","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777497851; cv=none;\n b=TfEHfXgwA/43FuIVDKib9cgpjWRbFsS/AeKzxL2m/Q8a4BCaZVziQZ4FqLa9V1+6nh8lpvgg4j116Eu7Aw97epWsDLB0nxaUp+l2tzXaY6LrNZHV4cpSf/6B107/pDtVd5V5AB0Jrk3ePQL2iljVcV/njLM121ZDhhYtqN5K1L4=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777497851; c=relaxed/simple;\n bh=HV4kbOyITKyvbnhXL/UfS7fkoEkLKQsedPmBoONLi7M=;\n h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version;\n b=MzF9f+so+owDxyG8eXWoTwRVR+QzUtMAXAmfaoUYHRFt5JHbdaD1yTHd5uRtmMfVB8WK0QIrIpHz36Grqed62sGp4cgli1TevXPTDeSbUxatXi0u2gCgA33CBBvDccllBbA2G5Agcq6g4miv9K0rae3QFRUSsOJYDY3X4Z7FNL8=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=\n cebitec.uni-bielefeld.de; h=content-type:content-type\n :mime-version:user-agent:message-id:date:date:references\n :in-reply-to:subject:subject:from:from:received:received; s=\n 20200306; t=1777497844; bh=HV4kbOyITKyvbnhXL/UfS7fkoEkLKQsedPmBo\n ONLi7M=; b=S72HELUKhHJuJ+H3rXEN/eZzZhmaWGHi7S9gc10DFxwTsDXTUyZD1\n E5I3bmD79XpKd3zzS3R/bXBDF7XEvB6NzGtMcdZiEUOtOJlqGbeX+w19s+swI7dp\n OqcwRR/UPRxkDn876rMfQNmSbImLAHhG8EMqjFrMwNw/0CFVCV/D+CpFR7nvef/A\n V0GTYtl0DYIlvXubzQ733XtUtjCrY4fdJ4SqM5lsPJbD5vZTX8FzkhFUnAlbiSYz\n g/jznXRUZouQepPjcr6HBiS1e4foF5NPmT/rp4FB33zO/IL2OW+ZZuV4mEmuDCJH\n DGurAbNmx6oCqM4SwIW9ieaWY9Dmd8uvg==","X-Virus-Scanned":"amavisd-new at cebitec.uni-bielefeld.de","From":"Rainer Orth ","To":"Uros Bizjak ","Cc":"Kewen Lin , \"gcc-patches@gcc.gnu.org\"\n , Liulxx , Qingkuan Lai\n , Feng Xue , \"hubicka@ucw.cz\"\n , \"hongtao.liu@intel.com\" ","Subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","In-Reply-To":"\n \n (Uros Bizjak's message of \"Wed, 29 Apr 2026 07:48:23 +0200\")","References":"<387794d9-199a-4373-97be-5e70e772e014@hygon.cn>\n \n \n ","Date":"Wed, 29 Apr 2026 23:24:03 +0200","Message-ID":"","User-Agent":"Gnus/5.13 (Gnus v5.13)","MIME-Version":"1.0","Content-Type":"text/plain","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3684306,"web_url":"http://patchwork.ozlabs.org/comment/3684306/","msgid":"","list_archive_url":null,"date":"2026-04-29T22:31:58","subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","submitter":{"id":4387,"url":"http://patchwork.ozlabs.org/api/people/4387/","name":"H.J. Lu","email":"hjl.tools@gmail.com"},"content":"On Thu, Apr 30, 2026 at 5:24 AM Rainer Orth wrote:\n>\n> Hi Uros,\n>\n> >> There are some changes in v2 comparing to v1:\n> >> - In function host_detect_local_cpu: relaxed CPU model check\n> >> from model == 7 to model >= 7 to make any potential future\n> >> model adopt M7 at least.\n> >> - Replaced multiple uses of cond with if_then_else where only\n> >> a single condition is involved as suggested.\n> >> - Removed redundant checks as alternative constraints ensure\n> >> as suggested.\n> >> - Fixed a few alignment formatting issues on c86_attr lines in mds.\n> >> - Removed some unnecessary empty lines.\n> >>\n> >> Bootstrapped and regtested as before.\n> >>\n> >> Is it ok for trunk?\n> >\n> > OK.\n>\n> between yesterday and today, I saw an increase in bootstrap times\n> between 37 and 75%:\n>\n> * i686-pc-linux-gnu, -j128 1:03:03 -> 1:50:00\n>\n> * i386-pc-solaris2.11, -j28 3:08:11.19 -> 4:18:22.77\n>\n> while the x86_64-pc-linux-gnu times are virtually unchanged. It seems\n> likely that this patch is the culprit. Is anyone else seeing the same?\n>\n\nYes, I have seen a similar compile time increase on Linux/i686.","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=QkoSTeyv;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (2048-bit key,\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=QkoSTeyv","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com","sourceware.org; spf=pass smtp.mailfrom=gmail.com","server2.sourceware.org;\n arc=pass smtp.remote-ip=209.85.215.173"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g5XCT45TZz1yGq\n\tfor ; Thu, 30 Apr 2026 08:33:57 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 916674320FD3\n\tfor ; Wed, 29 Apr 2026 22:33:55 +0000 (GMT)","from mail-pg1-f173.google.com (mail-pg1-f173.google.com\n [209.85.215.173])\n by sourceware.org (Postfix) with ESMTPS id CB5B04320FD4\n for ; Wed, 29 Apr 2026 22:32:35 +0000 (GMT)","by mail-pg1-f173.google.com with SMTP id\n 41be03b00d2f7-c795f096fa5so80487a12.3\n for ; Wed, 29 Apr 2026 15:32:35 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 916674320FD3","OpenDKIM Filter v2.11.0 sourceware.org CB5B04320FD4"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org CB5B04320FD4","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org CB5B04320FD4","ARC-Seal":["i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1777501956; cv=pass;\n b=kIFToANDYMJOb0Yc7j/21tpHuiUtTofEclx4XnnoY3gMFq13cTRzy5Z4mjc1VGGM57DEgbHnwOh/eIi7R8vvTht/r7uhUmCIdna41KzFwR5YzPLAjU39NdMivCa+P7tMCmcqE1wpxdC4MBHP/fX2SrQDfsB0ZCdsu0SpM66GOxk=","i=1; a=rsa-sha256; t=1777501955; cv=none;\n d=google.com; s=arc-20240605;\n b=CG3uNX7t2kxuKG+z7rNG9N1fOn4Kn0To9PRmDdNCxUY958mycZC+fGilFAx8Uou8cH\n 50rr0D/QACQbDQApymlC0rZ1FdAottXnZILxHKB4ZT8h8Ktd9nD/jzuAWN1BIGm9FrfC\n NRT+dEadG4rjgmlTKFDVzfHHT/AlGdjbBCujxxH6pUhxMIRlYOBardkslUDG/kOPolnY\n PHj/iMx8fQZz+ErKe6QNojvcX0AGj+QpsGYYXChssAv9rWCerQTMZu3dTdI7C5KYCd4u\n 2V6lzNsy+3LYTz092PycQJRsMDqLN8Tugq/8xdFM6O7fnZB+pUFje8rR+TjnumEdPME8\n 67zg=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777501956; c=relaxed/simple;\n bh=8caRsjAWsSFdB2jUFxQRaiX5NyQbsPG0Qx3oVKKURKw=;\n h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;\n b=jPn6Cuzw/uXIa5i/R0WmwkTQh58JaLYSCm96CzJacWjMU8q4fBJ19lDi8vnjY+L23emxJl51pWyLRnPZhKKUN+PJlc5/GXOA1Xq8a5CPITiWeVjJ/jSgnOr3Q6ilutnfKmBj5QIY30dkzknZpzHLPEag9dN+NLZig7JivGlNGuw=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=FVeZ6EdJ8wF0x/B4wJPOqq8U8jupNUG57ecZ2RwOef0=;\n fh=DX2jUmsSVQV/pppmJDY6inqcC9hefN9PzenQ4T8z90Q=;\n b=Yg4b5rmZWdB9D+HASkr/D9hLfoa0F56LEf4BceNukju8+qCyAWwlMnFXMtNbWHh+/G\n hsiYvSzPFvi3NxyD6oeJyWQkXeN/pj48qX5jrXQ4jXZSMv9pBUFFs0JNam0+VISH0NT+\n S577S1PLMvcu9faN1f/oVe/aQq9RTsSH33DuWImSYDklZEunzFgUmP+hy0VFeGIVo0N+\n jWciUJdwzaqkxfYUho/5JC27MZUBuitfKlVQLpF2CS7QQhIq4hHxE9Lk549TJ8v+7ie6\n /u0PUBpLe++ykwj2LHqpHbjufo++7ro4A/LL87i98DPfzOs/t42sbVk37ELctt4qF0KK\n roNA==; darn=gcc.gnu.org"],"ARC-Authentication-Results":["i=2; server2.sourceware.org","i=1; mx.google.com; arc=none"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1777501955; x=1778106755; darn=gcc.gnu.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=FVeZ6EdJ8wF0x/B4wJPOqq8U8jupNUG57ecZ2RwOef0=;\n b=QkoSTeyvRuKeo5uwnVA0+vAk21tl34slWuZQvqSgMFMUHXNS/mj2AfK/NIIDDnp1ip\n lMGMQPOSOIR8q6ZoHr5eyPjzb4HeD9PNQWqZQRXXR9tRcsXGt7RtPvS3Ttwst9j+Kn6G\n vLNw9DGMkbGSmBQZfiMymsR95dWdyPyCOnlEdSJu52gPenoVp+E4PGeIireLl+qiy+s0\n gjPEzK7UV+SCyORbfEilX4mX5OdCUKdJIcnt0IlbKCoG0KbP3GvTkeaUzF2hFRDcUwFx\n rZfgxj3YfA/M5wtveXr00C6oxPQjaHgi7Q2OvsN77uMrM8wU2hV2X5JSAqh8H6lSDynv\n XO3A==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1777501955; x=1778106755;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=FVeZ6EdJ8wF0x/B4wJPOqq8U8jupNUG57ecZ2RwOef0=;\n b=HfLQ3PGlGYxdiq/RSD8RqsJlA6IFmpQ9eP8s23xmt0PCuSGLeAXw42kGwmDXcL7frm\n 5FjWCJxQJvGIFP/j6g/cEzzrnti3NLzLCN90FIqW5s/5K+A4I8+mqVXggW85A9bzxu0X\n llUG1IhxSQM8AXhY8krC29Lb0zH/NDz0BcHqw1le8d88/ThHEnjg6sx6eQbxKeMA01Y6\n PHTqp1cLLA+1S+hn6c75AQEuj80ZCsnntvg5rNynytAZ4dzpMTJxxWw1SeyKUNzFb1+g\n lSE3pFfpmSw1Mqjkb/fJ7lWStnCfzMyhRokU9p/fYdiisJ+mQ3XFhds164ZfGrn1k7ix\n uu3g==","X-Forwarded-Encrypted":"i=1;\n AFNElJ9d+QVC2QTbrsBQOoGbIVF9Uh3SXjD16NucXvnFZIswZDJfqCSgrBIck2yUqksW6xcQcJ+hOdT3CvmcWw==@gcc.gnu.org","X-Gm-Message-State":"AOJu0Yxtd/mWiqjGirqCzv2O3XbqeXiBWCJouN8zor1/CB9I4iE/j7Wl\n CYr2hU6nMdsNtCJpo/QJTHJUppU2hFX78wXNwdEiVun/4O3bxXOy6/S9xfc1qUN5yD2kdtrxZlz\n Oc6E6zOaZIvZAyHJqHmr2+HchvAA+kZo=","X-Gm-Gg":"AeBDieuiRR8SWnDPmYqKNHNe9+LXfFC58v3ZmgxWjBpdenpe4W6cxXOofFLXU6tBRPm\n vG613bODJ6OJz3mliHsFrz5IY7x9yi+/p9mZYMtv7y3/uBpDpAwU5N8iCqahI5xs/qOi1ZAlk8t\n 7Kv7MroyZNvbUTWwsCI5Ef9t3tYJqD/kzDhJ/TZ7YXpWpAn7hJb34UQNnRTj/yqn3F8OPDrdhFr\n 5BERMK8wBt8HTMiDDpg49vK8qvhP2Yn+bZl4Kh7uborn4KMjHNati9osniiajeLvP/qe0mTD8Ei\n h4OkXHkEmJq23QxE7eVm","X-Received":"by 2002:a05:6a20:e292:b0:398:6ea8:21d2 with SMTP id\n adf61e73a8af0-3a3cf50a22fmr325637637.19.1777501954731; Wed, 29 Apr 2026\n 15:32:34 -0700 (PDT)","MIME-Version":"1.0","References":"<387794d9-199a-4373-97be-5e70e772e014@hygon.cn>\n \n \n \n ","In-Reply-To":"","From":"\"H.J. Lu\" ","Date":"Thu, 30 Apr 2026 06:31:58 +0800","X-Gm-Features":"AVHnY4JBFjzWLVqMnRgTJ7mckC_CQMHPjnG2Wk3M4pf6c59rjKfKgopdpb4rnII","Message-ID":"\n ","Subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","To":"Rainer Orth ","Cc":"Uros Bizjak , Kewen Lin ,\n \"gcc-patches@gcc.gnu.org\" ,\n Liulxx ,\n Qingkuan Lai , Feng Xue ,\n \"hubicka@ucw.cz\" ,\n \"hongtao.liu@intel.com\" ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3684373,"web_url":"http://patchwork.ozlabs.org/comment/3684373/","msgid":"<9e20997c-d94e-4115-b0bc-72c5c0744542@126.com>","list_archive_url":null,"date":"2026-04-30T02:09:10","subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","submitter":{"id":93285,"url":"http://patchwork.ozlabs.org/api/people/93285/","name":"Kewen Lin","email":"linkw_gcc@126.com"},"content":"Hi Rainer & H.J.,\n\n在 2026/4/30 6:31, H.J. Lu 写道:\n> On Thu, Apr 30, 2026 at 5:24 AM Rainer Orth wrote:\n>>\n>> Hi Uros,\n>>\n>>>> There are some changes in v2 comparing to v1:\n>>>> - In function host_detect_local_cpu: relaxed CPU model check\n>>>> from model == 7 to model >= 7 to make any potential future\n>>>> model adopt M7 at least.\n>>>> - Replaced multiple uses of cond with if_then_else where only\n>>>> a single condition is involved as suggested.\n>>>> - Removed redundant checks as alternative constraints ensure\n>>>> as suggested.\n>>>> - Fixed a few alignment formatting issues on c86_attr lines in mds.\n>>>> - Removed some unnecessary empty lines.\n>>>>\n>>>> Bootstrapped and regtested as before.\n>>>>\n>>>> Is it ok for trunk?\n>>>\n>>> OK.\n>>\n>> between yesterday and today, I saw an increase in bootstrap times\n>> between 37 and 75%:\n>>\n>> * i686-pc-linux-gnu, -j128 1:03:03 -> 1:50:00\n>>\n>> * i386-pc-solaris2.11, -j28 3:08:11.19 -> 4:18:22.77\n>>\n>> while the x86_64-pc-linux-gnu times are virtually unchanged. It seems\n>> likely that this patch is the culprit. Is anyone else seeing the same?\n>>\n> \n> Yes, I have seen a similar compile time increase on Linux/i686.\n\nThanks for the information, we didn't test for i686 before, are trying to\nreproduce this locally first. Did you happen to notice which part inceased\nmuch or any suspicious point like automation gen etc.?\n\nBR,\nKewen","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=126.com header.i=@126.com header.a=rsa-sha256\n header.s=s110527 header.b=gkZjJS+N;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=126.com header.i=@126.com header.a=rsa-sha256\n header.s=s110527 header.b=gkZjJS+N","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=126.com","sourceware.org; spf=pass smtp.mailfrom=126.com","server2.sourceware.org;\n arc=none smtp.remote-ip=220.197.31.9"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g5d11372Bz1yHv\n\tfor ; Thu, 30 Apr 2026 12:10:13 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 6EACD42D3768\n\tfor ; Thu, 30 Apr 2026 02:10:11 +0000 (GMT)","from m16.mail.126.com (m16.mail.126.com [220.197.31.9])\n by sourceware.org (Postfix) with ESMTPS id D403C4AA0947\n for ; Thu, 30 Apr 2026 02:09:40 +0000 (GMT)","from [172.19.23.14] (unknown [])\n by gzga-smtp-mtada-g0-1 (Coremail) with SMTP id\n _____wD3dxHWufJprXgPAg--.47463S2;\n Thu, 30 Apr 2026 10:09:27 +0800 (CST)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 6EACD42D3768","OpenDKIM Filter v2.11.0 sourceware.org D403C4AA0947"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org D403C4AA0947","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org D403C4AA0947","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777514982; cv=none;\n b=pEIHOSy3hkvAjSLlj5yLDFW8E6utfA8dG+nLbOAK8wy27X3Zlg+fBnzgysnsWRRAUWCTT75Snon8WrY1Rqoa1yaN+ZK4GR+3gor9DnUJCJ8X2EthTXUSVfWgbErhfn951+I1+v2tKEtb/lhwRn3tEsLgQsrj2RRElo9mvDOWx2M=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777514982; c=relaxed/simple;\n bh=jL+qvusRjbatQb/WqvdaaAl+9iFXDjM0Bs0KUrXXGZo=;\n h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From;\n b=ceXYe8OTuTTeIVvs4K6/G+j3xrRMrm+xDJHgEyyY+8OQEJjzUst4AJZDuoClu8hXYGo1viEkdG5qdoBMP+T61wwAsvec8ZAEplqHd+d3sb3Y18jDs/2I3taGQZifON5PLoRjV4a2H0/NsLdwbsgYK2JyCViy4hFD8OzkzdAsno4=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;\n s=s110527; h=Message-ID:Date:MIME-Version:Subject:To:From:\n Content-Type; bh=BDswvl19E39VvqaKY7f6ml8+6rWmQ12clcbF0MPrr6I=;\n b=gkZjJS+NJrop6B6peLwTh0F08/I0+Ts8NsJ+f07QN+22b6QqevBbE+3MLmibgB\n SmeNq7QPRqysRjQqvltlkqBb4afZYSoBirYlsVZQtfA1VTsedDwFxSvPl0HekMo9\n SrYqc/k9PU3eQqgm20GUeQzUdeuWh1CYr0pFsovTiZoRY=","Message-ID":"<9e20997c-d94e-4115-b0bc-72c5c0744542@126.com>","Date":"Thu, 30 Apr 2026 10:09:10 +0800","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","To":"\"H.J. Lu\" , Rainer Orth ","Cc":"Uros Bizjak , Kewen Lin ,\n \"gcc-patches@gcc.gnu.org\" , Liulxx\n , Qingkuan Lai ,\n Feng Xue , \"hubicka@ucw.cz\" ,\n \"hongtao.liu@intel.com\" ","References":"<387794d9-199a-4373-97be-5e70e772e014@hygon.cn>\n \n \n \n \n ","From":"Kewen Lin ","In-Reply-To":"\n ","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"8bit","X-CM-TRANSID":"_____wD3dxHWufJprXgPAg--.47463S2","X-Coremail-Antispam":"1Uf129KBjvJXoW7AryrGF13uFW5uFykGw4DJwb_yoW8GFWUpr\n WDK3Z8KFs5tr1jvFyktwnxXa1Sq395trZrXF98t34UAFn0y34rtr9rKryY9F93GF1kAr1x\n Zw4jya4xuFyjvaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2\n 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07UDHUgUUUUU=","X-Originating-IP":"[112.64.138.194]","X-CM-SenderInfo":"5olqy4pbjfuqqrswhudrp/xtbBrhi7R2nyudgeNgAA3Y","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3684382,"web_url":"http://patchwork.ozlabs.org/comment/3684382/","msgid":"","list_archive_url":null,"date":"2026-04-30T03:07:55","subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","submitter":{"id":4387,"url":"http://patchwork.ozlabs.org/api/people/4387/","name":"H.J. Lu","email":"hjl.tools@gmail.com"},"content":"On Thu, Apr 30, 2026 at 10:10 AM Kewen Lin wrote:\n>\n> Hi Rainer & H.J.,\n>\n> 在 2026/4/30 6:31, H.J. Lu 写道:\n> > On Thu, Apr 30, 2026 at 5:24 AM Rainer Orth wrote:\n> >>\n> >> Hi Uros,\n> >>\n> >>>> There are some changes in v2 comparing to v1:\n> >>>> - In function host_detect_local_cpu: relaxed CPU model check\n> >>>> from model == 7 to model >= 7 to make any potential future\n> >>>> model adopt M7 at least.\n> >>>> - Replaced multiple uses of cond with if_then_else where only\n> >>>> a single condition is involved as suggested.\n> >>>> - Removed redundant checks as alternative constraints ensure\n> >>>> as suggested.\n> >>>> - Fixed a few alignment formatting issues on c86_attr lines in mds.\n> >>>> - Removed some unnecessary empty lines.\n> >>>>\n> >>>> Bootstrapped and regtested as before.\n> >>>>\n> >>>> Is it ok for trunk?\n> >>>\n> >>> OK.\n> >>\n> >> between yesterday and today, I saw an increase in bootstrap times\n> >> between 37 and 75%:\n> >>\n> >> * i686-pc-linux-gnu, -j128 1:03:03 -> 1:50:00\n> >>\n> >> * i386-pc-solaris2.11, -j28 3:08:11.19 -> 4:18:22.77\n> >>\n> >> while the x86_64-pc-linux-gnu times are virtually unchanged. It seems\n> >> likely that this patch is the culprit. Is anyone else seeing the same?\n> >>\n> >\n> > Yes, I have seen a similar compile time increase on Linux/i686.\n>\n> Thanks for the information, we didn't test for i686 before, are trying to\n> reproduce this locally first. Did you happen to notice which part inceased\n> much or any suspicious point like automation gen etc.?\n>\n\nYou can build i686 gcc on Fedora/x86-64 to see it yourselves.","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=UDL1aX49;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=38.145.34.32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (2048-bit key,\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=UDL1aX49","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com","sourceware.org; spf=pass smtp.mailfrom=gmail.com","server2.sourceware.org;\n arc=pass smtp.remote-ip=209.85.215.179"],"Received":["from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g5fKP3CSNz1yHZ\n\tfor ; Thu, 30 Apr 2026 13:09:07 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 93D184900322\n\tfor ; Thu, 30 Apr 2026 03:09:02 +0000 (GMT)","from mail-pg1-f179.google.com (mail-pg1-f179.google.com\n [209.85.215.179])\n by sourceware.org (Postfix) with ESMTPS id 027D44B9208C\n for ; Thu, 30 Apr 2026 03:08:34 +0000 (GMT)","by mail-pg1-f179.google.com with SMTP id\n 41be03b00d2f7-c736261ee8dso122354a12.1\n for ; Wed, 29 Apr 2026 20:08:34 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 93D184900322","OpenDKIM Filter v2.11.0 sourceware.org 027D44B9208C"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 027D44B9208C","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 027D44B9208C","ARC-Seal":["i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1777518515; cv=pass;\n b=vGClN5ieGF6xZfvBcnjC6gK/P1nn2PqFNZcGtddcPjYiHYZeo8TjC3JRBKQZrEyr9EoHutPPcndeLT4+yECR1CLagT4aiORNT+EfM85mpFW+dj/2jGlWJsQqghwOxxjrQQ59un1eyy0/dszEcs6HYweL6M8Zgd4ltVmJRt/b5Os=","i=1; a=rsa-sha256; t=1777518514; cv=none;\n d=google.com; s=arc-20240605;\n b=GhVwq0DOadUy/fShWmf8xaSwVR96fQnDER/oLWxZdTQv1RAM4nQzMR2tmC8Ydcmmze\n R8mBnm05jLBrS4QqDTURs5Xil/BKiAC9eEeJ14XUP5Mvk6CauGyHyCTauYreKoX3rJC4\n P6B7k+sLWBsdGaaIbk2+SKoazWIJIE13jcy7Qw6xlN84im6t2XqI2kOjWoG5KzRRD3ZE\n voNDipEGcs4tczW5q+8QfeDLG58B2iOmoxYnYc47fmVdS0TVs8h9mF/li6huk/LYgoJb\n ij/9YrGj81GvHwavEayIG/Vhiw3qQqWXmH7evoA+ubmSzyjpJe2kmrD53TVT0z1TWos/\n bPSA=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777518515; c=relaxed/simple;\n bh=IO4/hLgPtXcP1xkP+7jFfShGpdWFKm0l3XfJIZ+DX3w=;\n h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;\n b=cIRjovRFu6nn2nQ7LlUXODcVY2sRW6znnKbwVbGqhIfvzYcAr6L6haqKJOr0Up6q+xAD8AWiXT7JHgi57wABCS0ADHi05+4oI5shFncjOIxri6ZSmC5PsaeJrVK/gSrrU0iMFKxYsledh5vyEArXJrfXyC+8N2f8v5I7hpbWbWI=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=oRJsN7W5Sj7jsgdPMJ3wfL72zehYdrHcv56rc3RotEA=;\n fh=PufHHrf2F0GyRHBzR4AsdVo70wk1VsHUkzkDHPSpexE=;\n b=LIhkMF0DXZZ7VhI1FpZVZi9+v2Yhj2OFeA/IKtQo+F/dtTk3gTiiOYd3uyjbDM3EnG\n pY+Ssz5KVuy1bu/CBplKdAGXtFpqeRGZRXaKVkyxEmbYKWXqg0bONIerb7XPhdVpX8Nm\n qQaHt1bDf+PrfIrRk+3QjdEi2up2Ju2bMtfsoOLumMo5RaLivR5kIkLoDBm/rtj5RYc5\n t/covi1ojos3SNvzKqr7X5ill2KQd4R58O2pAWvRDevKGYbbDbdF1rvj1X+hOJ25K/wD\n KuskCqAHENT4DqcDmGhKm6YCZHXRPRz1e0QisgnudE14+vvJo6V8QifNJGR8YoKxhXi4\n 3iRg==; darn=gcc.gnu.org"],"ARC-Authentication-Results":["i=2; server2.sourceware.org","i=1; mx.google.com; arc=none"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1777518514; x=1778123314; darn=gcc.gnu.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=oRJsN7W5Sj7jsgdPMJ3wfL72zehYdrHcv56rc3RotEA=;\n b=UDL1aX49TMHaHvNH2hkfeunKK1UaCu0TAS1f/YDixkv6nRp3P25pIolaM1f1kLWMqZ\n xkNjuBoB3p+a6rMTHz0mun/eGXaBRqOoPrCy8IXULuRySwPiatIfhJxaWnlOqHb++TaF\n xHjoAhjxwVVWyUinTSxvlFHX7EVDjAaeezvhxesGO7vqWzW4ZgBY/b/mEk+ctrNRi3Zr\n ZRYst4yR/cXpNDC4U+775anKDE9DWBUyJouYDuMnTQOHYmPGJ299hHmM2OF5e3p6Z9Eo\n 3+i7thSVGHP2PYX4FeLcaiteZPz1bZNmlqSnrXfPgz2t7H39wFGeDR8LqMBWHYswTg/p\n 8/yQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1777518514; x=1778123314;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=oRJsN7W5Sj7jsgdPMJ3wfL72zehYdrHcv56rc3RotEA=;\n b=gxAs80v1gu5b9xK4xsjyJSAIk/dBmVCayftDwA8WjoRqPyLe0ay+aBT5b51ETY2pUg\n sEIL5kZJcJAZK5pzZfz/+qhb8ADzBI3gml+NvFNqM7rXtWlh2MsdB4k0IqoHvce5GDFI\n mGzLBf90XHZ3aYPKcVYmRRcQYotyCntcAZOymeytSquexxv1E3NMllDKSkkUQ0sxGPeL\n yvgI4a9klwOKuiP4qORjlrAr0SxWVrREkXAiY/nEuxId7yLbBwT5/V40SnGDLvl0nikP\n 6JgZFDGicv41mpP6xLFMH1vXTcOZ7IIcaMs/bs6iohlCC3ylZdIcHSgypXTpvrlsmGc3\n +L3Q==","X-Forwarded-Encrypted":"i=1;\n AFNElJ+cvCI/9nxGqN5Av9qRtGiQb2Pwds80yB18DtleUk6A7IDa8seeXRhNest6SljTPpnp2rS8fFovOczI2A==@gcc.gnu.org","X-Gm-Message-State":"AOJu0YwcBY7txeYvKzhAsRfuiSt/U4KiGGmICMak4J8vI5rG7i77RVpQ\n dBhIVMeoby2Wxjw2+M587sU5xpdYi2H5f0jR4Qtz+a/nQxmCiHQv8DBp+1CZT/g0T/U2xNvh2lv\n 5mvMJsyoomcn+qj9OGTIGZzkNMtui5Zg=","X-Gm-Gg":"AeBDievoqGC1SzvRXqTwdkvko2pQg7ofp6f7393Rh+vyXV/FwJ+k98RNM2a2YRcOccd\n j1tjpD4YGhK/S+7KHLrsdrmmNDyrKv0o1T676e5c16+hTIu1W/xNVetV78L8MLqIQkoZsZmfkZH\n XbHhNWVM7WRGtyuZel3NOwJ9U/N1+LIvXH6vnMQlGFoDmrHRJkb+Ik+6jWgD0RCcdtosgHr6lyz\n MGC+MoYFRQyhaTlRPXZHcKyGWPc6MiTQZpZk/d6NY8oP49gqqqskVYfFrgcGNS2rLsv0WH1sCqD\n sNJbZCIYULbsBlusww==","X-Received":"by 2002:a05:6a20:9188:b0:398:a934:9be6 with SMTP id\n adf61e73a8af0-3a3cf85a036mr1302380637.43.1777518513538; Wed, 29 Apr 2026\n 20:08:33 -0700 (PDT)","MIME-Version":"1.0","References":"<387794d9-199a-4373-97be-5e70e772e014@hygon.cn>\n \n \n \n \n \n <9e20997c-d94e-4115-b0bc-72c5c0744542@126.com>","In-Reply-To":"<9e20997c-d94e-4115-b0bc-72c5c0744542@126.com>","From":"\"H.J. Lu\" ","Date":"Thu, 30 Apr 2026 11:07:55 +0800","X-Gm-Features":"AVHnY4KSJ50rJl5GhV6G8sgwTiGVHN86-DrkYr9aXa7cV4mdzWIzHFMwwuJSW_k","Message-ID":"\n ","Subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","To":"Kewen Lin ","Cc":"Rainer Orth ,\n Uros Bizjak ,\n Kewen Lin ,\n \"gcc-patches@gcc.gnu.org\" ,\n Liulxx ,\n Qingkuan Lai , Feng Xue ,\n \"hubicka@ucw.cz\" ,\n \"hongtao.liu@intel.com\" ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3684471,"web_url":"http://patchwork.ozlabs.org/comment/3684471/","msgid":"","list_archive_url":null,"date":"2026-04-30T06:37:43","subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","submitter":{"id":1765,"url":"http://patchwork.ozlabs.org/api/people/1765/","name":"Richard Biener","email":"richard.guenther@gmail.com"},"content":"On Thu, Apr 30, 2026 at 4:10 AM Kewen Lin wrote:\n>\n> Hi Rainer & H.J.,\n>\n> 在 2026/4/30 6:31, H.J. Lu 写道:\n> > On Thu, Apr 30, 2026 at 5:24 AM Rainer Orth wrote:\n> >>\n> >> Hi Uros,\n> >>\n> >>>> There are some changes in v2 comparing to v1:\n> >>>> - In function host_detect_local_cpu: relaxed CPU model check\n> >>>> from model == 7 to model >= 7 to make any potential future\n> >>>> model adopt M7 at least.\n> >>>> - Replaced multiple uses of cond with if_then_else where only\n> >>>> a single condition is involved as suggested.\n> >>>> - Removed redundant checks as alternative constraints ensure\n> >>>> as suggested.\n> >>>> - Fixed a few alignment formatting issues on c86_attr lines in mds.\n> >>>> - Removed some unnecessary empty lines.\n> >>>>\n> >>>> Bootstrapped and regtested as before.\n> >>>>\n> >>>> Is it ok for trunk?\n> >>>\n> >>> OK.\n> >>\n> >> between yesterday and today, I saw an increase in bootstrap times\n> >> between 37 and 75%:\n> >>\n> >> * i686-pc-linux-gnu, -j128 1:03:03 -> 1:50:00\n> >>\n> >> * i386-pc-solaris2.11, -j28 3:08:11.19 -> 4:18:22.77\n> >>\n> >> while the x86_64-pc-linux-gnu times are virtually unchanged. It seems\n> >> likely that this patch is the culprit. Is anyone else seeing the same?\n> >>\n> >\n> > Yes, I have seen a similar compile time increase on Linux/i686.\n>\n> Thanks for the information, we didn't test for i686 before, are trying to\n> reproduce this locally first. Did you happen to notice which part inceased\n> much or any suspicious point like automation gen etc.?\n\ngenautomata now takes ages for me.\n\n> BR,\n> Kewen\n>","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=XoiehMfJ;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (2048-bit key,\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=XoiehMfJ","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com","sourceware.org; spf=pass smtp.mailfrom=gmail.com","server2.sourceware.org;\n arc=pass smtp.remote-ip=209.85.208.54"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g5kyT6rMmz1yGq\n\tfor ; Thu, 30 Apr 2026 16:38:25 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id EA1704BB588E\n\tfor ; Thu, 30 Apr 2026 06:38:23 +0000 (GMT)","from mail-ed1-f54.google.com (mail-ed1-f54.google.com\n [209.85.208.54])\n by sourceware.org (Postfix) with ESMTPS id 16A424BB590B\n for ; Thu, 30 Apr 2026 06:37:57 +0000 (GMT)","by mail-ed1-f54.google.com with SMTP id\n 4fb4d7f45d1cf-66e8cf72a93so735598a12.0\n for ; Wed, 29 Apr 2026 23:37:57 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org EA1704BB588E","OpenDKIM Filter v2.11.0 sourceware.org 16A424BB590B"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 16A424BB590B","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 16A424BB590B","ARC-Seal":["i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1777531077; cv=pass;\n b=pdSl0O2Blv3hk3UdUSDmbBRiLC65dM+EC5+BT94lcU//uAZsle4s9d81dL54CSQUpFuSV5yU2hnqjQb5naqocjScQRhLtzD9RsR57nT0gpIqSnrv3VCWfuw3b0MczZFr4Hnwj1pNPEc3E08Z44TlY2hpTTbXIKh4vMzd0gfVDTg=","i=1; a=rsa-sha256; t=1777531076; cv=none;\n d=google.com; s=arc-20240605;\n b=cbPbtQSYRkWyGuVhfV+OoI8O2aFBYkdcgAVnrzsWe0pV0OH8UPLGUfhYjks83xJtqB\n 3klI4whE608Ya1XA9q4WHTcUXzbVb5aakVC1OvfSWXDoPN/65NRMqlsJPequmNIvNJJ4\n xtpuE0Ztdh56P0wknfLJV3UsoJAGqNO1x7BL94vM1njeJteDJ0TJVy6/pi0Hxh7nq9MQ\n CzQDySdbSanwgbJS3Rs8BePs4OW/kiVvL856dP/PjhkaJxbomLVLhzsEs8lzxU46OWQ4\n BKa/NJcWQJnEwW61L5kSioJllO0ZY9adnT2Bh/FgutYFliq7bLd4V69LGjoVAoTGvJcF\n s+2Q=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777531077; c=relaxed/simple;\n bh=9JaAHfXMVZyTyKTLHcqUW5SFsP1QUrdbFYyc5ntY0s4=;\n h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;\n b=hXPALKEITk96UQgKcLS4a2BlrP1ygHVrArnKrsKG+QbtP6xHLjtTukyT+qoKPAsZ5/kCB6N7RkTM77q7SE7IJiWYQ+4vyzTrP7o9PiZ5cFfGcPL+bZCazK0NTVTrpr59PCgPp7FZA3p5OuJwXzg/J53ZN+boxcpKKb3OVvIgEmw=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=XvG6w4veGTwwR+7ojkpS5AznPCnF6Nah1V0VYHuUkG0=;\n fh=jfFqj9n7G3qgHoVBc2EBR9y9TSwcTTQx+wDWOpeZ1GU=;\n b=LfcINSnfYy3driKSuiO+bvmZ/1OxIxt9XPr4o3/bYX7UHxS+Hi6V0TpCIoE4Zx1EY9\n BWmOYxWIQE86miNWZnJeeat0/qhhj4mZvYuzoZjvFWeOoSJ/68a92KgRThRsjiyaus5P\n GRjTIWYXclD0qL1QSFRC9E63eLTgVscbyC8JdzQkyB44CnnP40KMa7xJvxcyYDnD5/J2\n qOkUCkOuVkWoYTLTcaNNpz19QqHyKCpMa+codFKHbdCf77I5cJQrFLW57r48ZG7ziKEr\n Y35xo2CYVWiWtrI1zEZU+Cm6sCi6VfV7OR7wUSfHc62a+D2KEtcosGM1XJ/8s0dOhnMD\n JROA==; darn=gcc.gnu.org"],"ARC-Authentication-Results":["i=2; server2.sourceware.org","i=1; mx.google.com; arc=none"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1777531076; x=1778135876; darn=gcc.gnu.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=XvG6w4veGTwwR+7ojkpS5AznPCnF6Nah1V0VYHuUkG0=;\n b=XoiehMfJ1+9GIcscxsZYK1blPmplfng6t3dTd31lgHoe3lfetPDjd4pZC/IOeoh96c\n oqGT4wj63950VcznyubE2XKeZ6E6qPKvi68R6taOBKXhkfMOqp39TDgrEIlbnEkJQGtE\n NJtEZEIRW5a4kMeQjtI0z7ZlF5P8uT5CjGJeEo79K0CQUy30iAyuiH0PXbqDj33e1Tsa\n dN0nFEJQHwWls2AWdHvEv5hZAsM1WzYMvVQGg9HcFZ3cG+oZnCZQ9iKOvqFt0xy5zpt2\n 0qr+e7RXyiVVpW9kig6KAMK65p0yKFijMaejeQ8RKG/c+kiTL7p5c8cirCySswxzZNBE\n wK9Q==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1777531076; x=1778135876;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=XvG6w4veGTwwR+7ojkpS5AznPCnF6Nah1V0VYHuUkG0=;\n b=SyJZWnl0B9fAE5aR0qNye0HH6o+D00M7OVCAcSbzgO3wmo8dL/+5dNAOVq2/WoAjLM\n +5BvqRFzGeWK+puqtqld6acdecEv42IIP8IkmM6UqsoISYD/kn1yQycaoDUjjcTC8Jnm\n 2VBn5oL2SResED6alzoLsMx085EOTc1nHqtLZdvCbgSav3qH7vEuudU+5X9QO4kIQ8ES\n ACxYH3SnK5FwOfmRRzwmfnRfGJKR7/lk7/TiQM3JTVRJzb5iLd8OCtc9JyXNWpfbhkac\n 98fVgza2kxqP4D5DnEuHsUrPV/hd7lHySTVIhIwL5ZoAV1ovhvD6FbjsSIQvyuN7AGdm\n SRIw==","X-Forwarded-Encrypted":"i=1;\n AFNElJ/VvtEqJb0hFRdvp72lRLNQuO4Wg5jpSkamwckfCQiJAqMo7TlVB7QAOZyvuGYUsr4LiN6+SSjI7dS6mg==@gcc.gnu.org","X-Gm-Message-State":"AOJu0YzODGvC33odikcoZojjS6OLKwSQjYVi0t6ICivZ8OFHktgIUJsR\n /CvbXZCDDRGaWnCdp501ZEZgdAKBzS7vGHf0hH+af1UgrogiKwaw90hwTAtTyWEfgHZ9p3ZLaet\n qkA/BiIOLp2rZu4DtS9roy/ZZ9hEgOiY=","X-Gm-Gg":"AeBDiet2Ai3KdrcfvtMMmT9qxoJMlyku3UO6DPzKb7F72xBuc09qgbTzMZ6860Wh5nT\n q5vnFhTo1S+eURcZDFJBEw+o121rSrqINrEmSL4Klr5s0spmRPtMgo28GJRS9rfUykO3nQs7tz7\n BzU5exusnCmVqkThvFnzadV91W8BsqPk9I0NeuX/Bfq0C/eBjTjRsAlS/zjCNhmRywvgk6jlEQI\n IRAqqGRWMZ1pDptFrQI1mFe6v2knIqUvFl1mJnpLfxwtmpnrwRQCTa6LpVzBV+Lalj38PgYAh6q\n ATcAlNyFUJyOM1S5","X-Received":"by 2002:a05:6402:3581:b0:670:62dd:e2f4 with SMTP id\n 4fb4d7f45d1cf-67b5d7d6be1mr667977a12.8.1777531075600; Wed, 29 Apr 2026\n 23:37:55 -0700 (PDT)","MIME-Version":"1.0","References":"<387794d9-199a-4373-97be-5e70e772e014@hygon.cn>\n \n \n \n \n \n <9e20997c-d94e-4115-b0bc-72c5c0744542@126.com>","In-Reply-To":"<9e20997c-d94e-4115-b0bc-72c5c0744542@126.com>","From":"Richard Biener ","Date":"Thu, 30 Apr 2026 08:37:43 +0200","X-Gm-Features":"AVHnY4L6_1vpmuJ5hlY0AuEusbhLJ2L95jc1WW34DEpT25FtD9vNZbAi-jNDge0","Message-ID":"\n ","Subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","To":"Kewen Lin ","Cc":"\"H.J. Lu\" ,\n Rainer Orth ,\n Uros Bizjak , Kewen Lin ,\n \"gcc-patches@gcc.gnu.org\" ,\n Liulxx ,\n Qingkuan Lai , Feng Xue ,\n \"hubicka@ucw.cz\" ,\n \"hongtao.liu@intel.com\" ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3684497,"web_url":"http://patchwork.ozlabs.org/comment/3684497/","msgid":"","list_archive_url":null,"date":"2026-04-30T07:27:53","subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","submitter":{"id":4387,"url":"http://patchwork.ozlabs.org/api/people/4387/","name":"H.J. Lu","email":"hjl.tools@gmail.com"},"content":"On Thu, Apr 30, 2026 at 2:37 PM Richard Biener\n wrote:\n>\n> On Thu, Apr 30, 2026 at 4:10 AM Kewen Lin wrote:\n> >\n> > Hi Rainer & H.J.,\n> >\n> > 在 2026/4/30 6:31, H.J. Lu 写道:\n> > > On Thu, Apr 30, 2026 at 5:24 AM Rainer Orth wrote:\n> > >>\n> > >> Hi Uros,\n> > >>\n> > >>>> There are some changes in v2 comparing to v1:\n> > >>>> - In function host_detect_local_cpu: relaxed CPU model check\n> > >>>> from model == 7 to model >= 7 to make any potential future\n> > >>>> model adopt M7 at least.\n> > >>>> - Replaced multiple uses of cond with if_then_else where only\n> > >>>> a single condition is involved as suggested.\n> > >>>> - Removed redundant checks as alternative constraints ensure\n> > >>>> as suggested.\n> > >>>> - Fixed a few alignment formatting issues on c86_attr lines in mds.\n> > >>>> - Removed some unnecessary empty lines.\n> > >>>>\n> > >>>> Bootstrapped and regtested as before.\n> > >>>>\n> > >>>> Is it ok for trunk?\n> > >>>\n> > >>> OK.\n> > >>\n> > >> between yesterday and today, I saw an increase in bootstrap times\n> > >> between 37 and 75%:\n> > >>\n> > >> * i686-pc-linux-gnu, -j128 1:03:03 -> 1:50:00\n> > >>\n> > >> * i386-pc-solaris2.11, -j28 3:08:11.19 -> 4:18:22.77\n> > >>\n> > >> while the x86_64-pc-linux-gnu times are virtually unchanged. It seems\n> > >> likely that this patch is the culprit. Is anyone else seeing the same?\n> > >>\n> > >\n> > > Yes, I have seen a similar compile time increase on Linux/i686.\n> >\n> > Thanks for the information, we didn't test for i686 before, are trying to\n> > reproduce this locally first. Did you happen to notice which part inceased\n> > much or any suspicious point like automation gen etc.?\n>\n> genautomata now takes ages for me.\n\nSame here.","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=m1+JEfA0;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (2048-bit key,\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=m1+JEfA0","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com","sourceware.org; spf=pass smtp.mailfrom=gmail.com","server2.sourceware.org;\n arc=pass smtp.remote-ip=209.85.215.171"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g5m4w3pgsz1xqf\n\tfor ; Thu, 30 Apr 2026 17:29:02 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id B93654BBC0CA\n\tfor ; Thu, 30 Apr 2026 07:28:58 +0000 (GMT)","from mail-pg1-f171.google.com (mail-pg1-f171.google.com\n [209.85.215.171])\n by sourceware.org (Postfix) with ESMTPS id 1E9D04BB3BFF\n for ; Thu, 30 Apr 2026 07:28:32 +0000 (GMT)","by mail-pg1-f171.google.com with SMTP id\n 41be03b00d2f7-c648bc907ebso364710a12.3\n for ; Thu, 30 Apr 2026 00:28:32 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org B93654BBC0CA","OpenDKIM Filter v2.11.0 sourceware.org 1E9D04BB3BFF"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 1E9D04BB3BFF","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 1E9D04BB3BFF","ARC-Seal":["i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1777534112; cv=pass;\n b=Pt9++Z2H89+WZdmIi96mMpgxv2G5NDsdhX7c8d9F5eDzQ6KHl2l3RQ4eb74NPukdOLWVaHhwxNeirqF4tMjjiF/nxjtgRiPf+U/LIzncb2z+PNbzZe2T8gMfG8tm5LIG7hhZ88aP4AFMLps+vx16sXugvsjzuWh06WBfe7xGwVo=","i=1; a=rsa-sha256; t=1777534111; cv=none;\n d=google.com; s=arc-20240605;\n b=jwlegGx3dF4uIabAH+X3vavKg5NyF2J8c9ArtyKrhw8B+bH6xTw5tWHoC4iquyAOUt\n gzT1VQ8cOPdjtPSMJehEMMoKhQMgxN3Zvbs0w0TU+cXVV0dSwPgRjgEW8pyBhoy7MiaA\n 06beHIKKfgjE/DkBGx8NXUDjExRg6OFqQqutBAHoOcqU3gDNcdfSoNyiw/yXmSViFzAi\n fldTrBbA2wj2s4E1L6Cyn0VaCUanKBXLri6vx0RP55U7AuVPfEYY9bEcvDOrOx3lv0MY\n eQea54GwC9rrkenMf7JljIk+JqfbzaDf3s6umvlZdt32v77P/99qVSVYLElpWgpzWngW\n uWpg=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777534112; c=relaxed/simple;\n bh=A5KB6day8Sozo6QOQUeVx37E3D60YF4leKmuKduAe8w=;\n h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;\n b=ns21bsXediIknjuT1HCV4i0/QSYZSSKq7R5Y7A24itCmlod373DAJ3O1L7L4nL8T+67Igr+QsUx7fVTDOzgzNMZJ/rnBTyIImCXLjqNHmzEkT9HAIb2LSh1m5rv2QXtgeLC+Rea+V1ynE5tgxl3xVSAKxaKgw4XYQoAe4ltOKQM=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=O4873R3zzx8Mq/xpdMjBCt0xs2wg/mfadgbv4Yz+yBw=;\n fh=Q7PwXhNzUqSaUkNwhxiCA7Q8KeSqHQNDbKsOv4T2WnI=;\n b=Yk6l/KG2sASnuho3AUiFWmC4GonBZo4Qy5wEFh0U6irdrTMYrlvvur0nRkK8AO8bLF\n q5YxW3EuZYjCdTeZQroBdVF4IpZhJiOCp7wSu2gRDUI7ceu6Mb1scMBnnZBPb2l1+Fny\n BUCl+HAE2yzukouLHOfGYE2qM7r5SBs04GXuE0msmdifFPcUikAqX8QCzVRqsbQmhkZy\n GQraOe9Q0WzjIjHndUkoZk9b8XDowMOawKccMtMzCLmReobQXB0OCQlqvhyW7A/AuqwV\n GyAA/x8AUcxmYNvhBk/a1yEJL7/Wju/rHtVrBN2WMwiLh8enrvSPKKyqeLxabNA+Qoiz\n 89WQ==; darn=gcc.gnu.org"],"ARC-Authentication-Results":["i=2; server2.sourceware.org","i=1; mx.google.com; arc=none"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1777534111; x=1778138911; darn=gcc.gnu.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=O4873R3zzx8Mq/xpdMjBCt0xs2wg/mfadgbv4Yz+yBw=;\n b=m1+JEfA00BGNUB4+w+4O6xqOgvZNTlzS3A/wJ54pWalbLF/D+DgfStWcDMz4EAZ0My\n 0XDQHY1TDafOxbp9UnpEW4hhWUDWOWCTpbYmJ5jwl/DCebFMT8muRPSG9EvAR7YaDxC4\n ZpnMgNLhfvm5JIbXEKc05Pou730oYuIvd9l5GQi0M1yhNdjvweYDTICu+6Rpu7IBQ4De\n MFDUylYoNx9hYuzc5JysuIAZvlPW9t9owhoq9OYGdj5kQipqnLHSVOteQ06akdpsjiTK\n K3PsoJ+jLePhFI00H9cHujS8QvatTQhUwgnp4ruk7O6uBw0GNpIKOLh/+txDFr5DRELU\n Kh6g==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1777534111; x=1778138911;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=O4873R3zzx8Mq/xpdMjBCt0xs2wg/mfadgbv4Yz+yBw=;\n b=R+y3hMCqQyTGufC7VIf+1ndWDSnjXo9/8V6BKO40TNpqJqvTxhHNGdp2CFzPkPGJQq\n A8ScC4Ug1sJ6N0EH/oK+HkLeY7HmA0ljQU09YE8/atQh0DA63r64pnyYaRF5OwZT3dMg\n uCril7UE1Law0yFdRmB+vFn7z8wN2Gn8Zv4l04F52sgnoW13NY4L4jge4X9Qqb/Xp9yz\n 2PXwp8HNMMDqPDSQRSVihVZStH+wjismORpcV1PU2IJqHviFqiFA2WybuymrI4KO1dvV\n xY3UnKGHHK4/ERIwQ65Woz6A36fhguZkrta0htEKyzw5+o2+3mUscEYAS2zZZzwZf8zW\n wMmw==","X-Forwarded-Encrypted":"i=1;\n AFNElJ9EDZncv+R0UQiEUhk29UcfmQaafDrMju1mNN1iaIdMbEPloLTgUl9LaOPy3JwksvbBsIcTA2F2HVspqw==@gcc.gnu.org","X-Gm-Message-State":"AOJu0YzWSsbJL4Airek1hyx9UUyNjuiLvjKGKuiwg0057znjzKbpt051\n V6ouwdhgsRaj413+j52Uv7SsbEzwCN93cSdapMnYM92wIvkiDXfDV24u6dlgkKrQe/ba18KP3eB\n 2QSyuHY0K9gtygWMtitktbERAdC7vVYA=","X-Gm-Gg":"AeBDieuST/rHdby2WRxogSxxunnh/I+UtEjda8rnLsyvIoMXDMYMlS9YXaNZGIkTYZE\n mXHopMtgOVNbSki+XhuExdyDdbkk+SsjBpd+UEy5uqjXBjppDytkAS3zssmzc1rqJihks5JntO6\n tJRZAMjbf5XsBV07VneX4Ch90vf8aWugoqLN3Gg/4I+IVHU0DhwGuQ5OD2evb/erz/C/t6jf0wH\n 72ljTeMvgGSMBZkh4TJ/D1YtO16ohH80DZy+c6lVj3SK15bd131/sjNZIPrX9YHOVykqwLvX3na\n YL09E59vjAGRgHsBKN49","X-Received":"by 2002:a05:6a20:914c:b0:3a2:f402:50fb with SMTP id\n adf61e73a8af0-3a3cf79e90fmr2060453637.34.1777534110701; Thu, 30 Apr 2026\n 00:28:30 -0700 (PDT)","MIME-Version":"1.0","References":"<387794d9-199a-4373-97be-5e70e772e014@hygon.cn>\n \n \n \n \n \n <9e20997c-d94e-4115-b0bc-72c5c0744542@126.com>\n ","In-Reply-To":"\n ","From":"\"H.J. Lu\" ","Date":"Thu, 30 Apr 2026 15:27:53 +0800","X-Gm-Features":"AVHnY4LfzYEKBvuYat5iwnMXVKWkaKKbAE-dmsjnOEglxre_83akj7MyK5UYJ-E","Message-ID":"\n ","Subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","To":"Richard Biener ","Cc":"Kewen Lin , Rainer Orth ,\n Uros Bizjak , Kewen Lin ,\n \"gcc-patches@gcc.gnu.org\" ,\n Liulxx ,\n Qingkuan Lai , Feng Xue ,\n \"hubicka@ucw.cz\" ,\n \"hongtao.liu@intel.com\" ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3684500,"web_url":"http://patchwork.ozlabs.org/comment/3684500/","msgid":"<243544d5-afa2-effa-d336-c4c78f52d1a6@ispras.ru>","list_archive_url":null,"date":"2026-04-30T07:42:09","subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","submitter":{"id":5136,"url":"http://patchwork.ozlabs.org/api/people/5136/","name":"Alexander Monakov","email":"amonakov@ispras.ru"},"content":"On Thu, 30 Apr 2026, Richard Biener wrote:\n\n> On Thu, Apr 30, 2026 at 4:10 AM Kewen Lin wrote:\n> >\n> > Hi Rainer & H.J.,\n> >\n> > 在 2026/4/30 6:31, H.J. Lu 写道:\n> > > On Thu, Apr 30, 2026 at 5:24 AM Rainer Orth wrote:\n> > >> between yesterday and today, I saw an increase in bootstrap times\n> > >> between 37 and 75%:\n> > >>\n> > >> * i686-pc-linux-gnu, -j128 1:03:03 -> 1:50:00\n> > >>\n> > >> * i386-pc-solaris2.11, -j28 3:08:11.19 -> 4:18:22.77\n> > >>\n> > >> while the x86_64-pc-linux-gnu times are virtually unchanged. It seems\n> > >> likely that this patch is the culprit. Is anyone else seeing the same?\n> > >>\n> > >\n> > > Yes, I have seen a similar compile time increase on Linux/i686.\n> >\n> > Thanks for the information, we didn't test for i686 before, are trying to\n> > reproduce this locally first. Did you happen to notice which part inceased\n> > much or any suspicious point like automation gen etc.?\n> \n> genautomata now takes ages for me.\n\nI strongly suspect a part of it is improper divider unit modeling that was fixed\nfor other pipeline models in context of bug 87832. In particular, I see\n\n+;; IDIV\n+(define_insn_reservation \"c86_4g_m7_idiv_DI\" 41\n+\t\t\t (and (eq_attr \"cpu\" \"c86_4g_m7\")\n+\t\t\t (and (eq_attr \"type\" \"idiv\")\n+\t\t\t\t (and (eq_attr \"mode\" \"DI\")\n+\t\t\t\t\t(eq_attr \"memory\" \"none\"))))\n+\t\t\t \"c86-4g-m7-double,c86-4g-m7-ieu3*41\")\n\nand ieu3 appears to be an ALU used for other instructions, not the divider. This\nlikely blows up the automaton, and doesn't properly model the pipeline anyway.\n\nKewen, please have a look at the patches linked from PR 87832, they all have\ncommit messages, and the strategy is not complicated (create a separate cpu_unit\nfor the partially-pipelined divider, use it in reservations, use throughput, not\nlatency figures ('*41' above is wrong): https://gcc.gnu.org/pr87832\n\nAlexander","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=ispras.ru header.i=@ispras.ru header.a=rsa-sha256\n header.s=default header.b=gftA3X+J;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=38.145.34.32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=ispras.ru header.i=@ispras.ru header.a=rsa-sha256\n header.s=default header.b=gftA3X+J","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=ispras.ru","sourceware.org; spf=pass smtp.mailfrom=ispras.ru","server2.sourceware.org;\n arc=none smtp.remote-ip=83.149.199.84"],"Received":["from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g5mNk0KnMz1xqf\n\tfor ; Thu, 30 Apr 2026 17:42:44 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 6AF7D4315053\n\tfor ; Thu, 30 Apr 2026 07:42:42 +0000 (GMT)","from mail.ispras.ru (mail.ispras.ru [83.149.199.84])\n by sourceware.org (Postfix) with ESMTPS id EF3054BA23D1\n for ; Thu, 30 Apr 2026 07:42:14 +0000 (GMT)","from monopod.intra.ispras.ru (unknown [10.10.3.121])\n by mail.ispras.ru (Postfix) with ESMTPSA id EDEA345F72ED;\n Thu, 30 Apr 2026 07:42:11 +0000 (UTC)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 6AF7D4315053","OpenDKIM Filter v2.11.0 sourceware.org EF3054BA23D1","OpenDKIM Filter v2.11.0 mail.ispras.ru EDEA345F72ED"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org EF3054BA23D1","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org EF3054BA23D1","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777534935; cv=none;\n b=QPXWkRo+T2RvIYkp39s7EHiM4ZdOClJ/csJLlQ6fpaR5AuNE3fL44Dv65CJaSjKEoDD6oKlRu2CRKSNy6Qwt7bsJZjx3eshl0KCsKC7TaXX0RiQX1sLH7Pd6DbnlUdTkVE93sGPipvvBA1pZnVfh1aBaLukyP2hhvo9UGZv9eSc=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777534935; c=relaxed/simple;\n bh=Df1PW7zdbRAmdkYMO6CDLCyzDVQ/WIqpnivm/VmtkBk=;\n h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version;\n b=r4Uyqom9hV+Hkj2vc5FsKSvzATagrviVemjHcGrnXEy5GFod3j9It5zRs8BG3+XdPpMZVIPYqig1wbSbPp/Iwh1xz2gCXGlv76R8KoZlc5qitqzRXSgFErjlQ/vl0l59FO4kXoboDV0o9BnAeJkHSYa91dYvsC0qBSMovD17bU0=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=ispras.ru;\n s=default; t=1777534932;\n bh=BvU3qhgJ0/usKZObBY21qUc8OUqkCaEH8OLb/jyrC1U=;\n h=Date:From:To:cc:Subject:In-Reply-To:References:From;\n b=gftA3X+JlDNEygPLePBK2v3gareiIJXlq+08FMRuU90RGpcEfgwgtsMwKOKzbtCrC\n BBx/4J+unsz3A8SCWPYqbrCUFuXKHzh4XCj940vtuJLW2rAqw6Y5BegSXE7Fo2Sxyf\n M703fQX1NNYZPvy4JDizEPpUKMZN7Yqqt5ytdC7g=","Date":"Thu, 30 Apr 2026 10:42:09 +0300 (MSK)","From":"Alexander Monakov ","To":"Richard Biener ","cc":"Kewen Lin , \"H.J. Lu\" ,\n Rainer Orth , Uros Bizjak ,\n Kewen Lin ,\n \"gcc-patches@gcc.gnu.org\" ,\n Liulxx , Qingkuan Lai ,\n Feng Xue , \"hubicka@ucw.cz\" ,\n \"hongtao.liu@intel.com\" ","Subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","In-Reply-To":"\n ","Message-ID":"<243544d5-afa2-effa-d336-c4c78f52d1a6@ispras.ru>","References":"<387794d9-199a-4373-97be-5e70e772e014@hygon.cn>\n \n \n \n \n \n <9e20997c-d94e-4115-b0bc-72c5c0744542@126.com>\n ","MIME-Version":"1.0","Content-Type":"multipart/mixed; boundary=\"8323328-2085129079-1777534932=:7805\"","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3684512,"web_url":"http://patchwork.ozlabs.org/comment/3684512/","msgid":"","list_archive_url":null,"date":"2026-04-30T08:02:57","subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","submitter":{"id":93285,"url":"http://patchwork.ozlabs.org/api/people/93285/","name":"Kewen Lin","email":"linkw_gcc@126.com"},"content":"在 2026/4/30 14:37, Richard Biener 写道:\n> On Thu, Apr 30, 2026 at 4:10 AM Kewen Lin wrote:\n>>\n>> Hi Rainer & H.J.,\n>>\n>> 在 2026/4/30 6:31, H.J. Lu 写道:\n>>> On Thu, Apr 30, 2026 at 5:24 AM Rainer Orth wrote:\n>>>>\n>>>> Hi Uros,\n>>>>\n>>>>>> There are some changes in v2 comparing to v1:\n>>>>>> - In function host_detect_local_cpu: relaxed CPU model check\n>>>>>> from model == 7 to model >= 7 to make any potential future\n>>>>>> model adopt M7 at least.\n>>>>>> - Replaced multiple uses of cond with if_then_else where only\n>>>>>> a single condition is involved as suggested.\n>>>>>> - Removed redundant checks as alternative constraints ensure\n>>>>>> as suggested.\n>>>>>> - Fixed a few alignment formatting issues on c86_attr lines in mds.\n>>>>>> - Removed some unnecessary empty lines.\n>>>>>>\n>>>>>> Bootstrapped and regtested as before.\n>>>>>>\n>>>>>> Is it ok for trunk?\n>>>>>\n>>>>> OK.\n>>>>\n>>>> between yesterday and today, I saw an increase in bootstrap times\n>>>> between 37 and 75%:\n>>>>\n>>>> * i686-pc-linux-gnu, -j128 1:03:03 -> 1:50:00\n>>>>\n>>>> * i386-pc-solaris2.11, -j28 3:08:11.19 -> 4:18:22.77\n>>>>\n>>>> while the x86_64-pc-linux-gnu times are virtually unchanged. It seems\n>>>> likely that this patch is the culprit. Is anyone else seeing the same?\n>>>>\n>>>\n>>> Yes, I have seen a similar compile time increase on Linux/i686.\n>>\n>> Thanks for the information, we didn't test for i686 before, are trying to\n>> reproduce this locally first. Did you happen to notice which part inceased\n>> much or any suspicious point like automation gen etc.?\n> \n> genautomata now takes ages for me.\n\nSorry for that. In some previous local revision, we noticed that some modeling\non long latency instructions which can execute on more than one units, like:\n\n(define_insn_reservation \"c86_4g_m7_avx512_sse_sqrt\" 16\n (and (eq_attr \"cpu\" \"c86_4g_m7\")\n (and (eq_attr \"type\" \"sse\")\n (and (eq_attr \"c86_attr\" \"sqrt\")\n (eq_attr \"memory\" \"none\"))))\n \"c86-4g-m7-direct,c86-4g-m7-fpu1*7|c86-4g-m7-fpu3*7\")\n\ncan cause compilation time to increase much on x86-64 build with big N, so we\ntried to reduce the number by sacrificing exact modeling. It looks that this issue\nis still obvious on 32-bit environment.\n\nI think (automata_option \"no-comb-vect\") is a quick workaround here, I wonder\nif it can be a fix though there isn't any port adopting it now.\n\nBR,\nKewen","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=126.com header.i=@126.com header.a=rsa-sha256\n header.s=s110527 header.b=aPWujNMI;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=126.com header.i=@126.com header.a=rsa-sha256\n header.s=s110527 header.b=aPWujNMI","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=126.com","sourceware.org; spf=pass smtp.mailfrom=126.com","server2.sourceware.org;\n arc=none smtp.remote-ip=220.197.31.7"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g5msP2Ggcz1yHZ\n\tfor ; Thu, 30 Apr 2026 18:04:07 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id A37444BA9010\n\tfor ; Thu, 30 Apr 2026 08:04:04 +0000 (GMT)","from m16.mail.126.com (m16.mail.126.com [220.197.31.7])\n by sourceware.org (Postfix) with ESMTPS id BB6434BA2E2B\n for ; Thu, 30 Apr 2026 08:03:32 +0000 (GMT)","from [172.19.23.14] (unknown [])\n by gzga-smtp-mtada-g0-2 (Coremail) with SMTP id\n _____wDn1+7CDPNpcck_Ag--.3962S2;\n Thu, 30 Apr 2026 16:03:15 +0800 (CST)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org A37444BA9010","OpenDKIM Filter v2.11.0 sourceware.org BB6434BA2E2B"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org BB6434BA2E2B","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org BB6434BA2E2B","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777536214; cv=none;\n b=HE5YgmTAe8EVFPZiMB5AnGhxJ1pPStD+uQ6cE96gAVtSst2w71BE00mcyDbLZKkiTysJ++jUTI0YQivwlYle5IKbNFzVXP+IrtAGPxUZrVK/K5By79PhGGJ/3dTfvySiNFcRRBULu8PejBoQl24jB1k337TEWN1AF22mS//KNrA=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777536214; c=relaxed/simple;\n bh=iVatQI1GY4f1/uLPd4ZoRVr34OPGQ7tbYeAnSgFz0TQ=;\n h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From;\n b=u8nS9wv5wm1bkyos3Axv6r8gWxMNsSQXsKv2bmU6hi1OMjbXd60Qe7r4FiCZFY9FvA1tcPN7t1hXL/gcNuAjnli6Q5SRdDXFZrHEjb0DP4W01it9c0f1yKtrtnWUOxqEpnodmYemokl6dhbLcDZkycRcJKKwJ2tg4HbTrpRZpKk=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;\n s=s110527; h=Message-ID:Date:MIME-Version:Subject:To:From:\n Content-Type; bh=4fWd4VWyAlXY9EhY+VOpb/o1c3dCL5viTPxHqvLG3x0=;\n b=aPWujNMIEFBJNUorcuh1g6F+N5Yt0Jb+n2CgFGx4aFc6F0f+Nn/FtFtG6ocF+6\n 3zmCRMOVfq4/HYMRavtxbZIHa2D8jPYo0LgYX3lg96XAc5R0wsc4fen/t93OE3uu\n c4cOQ/RapNXM6cGQWiHvKOY4L8eOmQWRQ6S/gAWXyfmZQ=","Message-ID":"","Date":"Thu, 30 Apr 2026 16:02:57 +0800","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","To":"Richard Biener ,\n Uros Bizjak ","Cc":"\"H.J. Lu\" , Rainer Orth\n , Kewen Lin ,\n \"gcc-patches@gcc.gnu.org\" , Liulxx\n , Qingkuan Lai ,\n Feng Xue , \"hubicka@ucw.cz\" ,\n \"hongtao.liu@intel.com\" ","References":"<387794d9-199a-4373-97be-5e70e772e014@hygon.cn>\n \n \n \n \n \n <9e20997c-d94e-4115-b0bc-72c5c0744542@126.com>\n ","From":"Kewen Lin ","In-Reply-To":"\n ","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"8bit","X-CM-TRANSID":"_____wDn1+7CDPNpcck_Ag--.3962S2","X-Coremail-Antispam":"1Uf129KBjvJXoW7Cw4rXr1xCry7JryDAFWfAFb_yoW5Jr1rpr\n ZrG3Z8tFs8tr1qvF1ktwsxJw1Fqa1rGw4UXrn8J34UAF90krn3trnrKryY9F93Gr1kAr12\n vw4jq343Xw1UZaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2\n 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07UD9N3UUUUU=","X-Originating-IP":"[112.64.138.194]","X-CM-SenderInfo":"5olqy4pbjfuqqrswhudrp/xtbBrwOKFmnzDMMmiAAA3L","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3684525,"web_url":"http://patchwork.ozlabs.org/comment/3684525/","msgid":"<40624ddb-f767-42b4-8b13-1f9225df98dd@126.com>","list_archive_url":null,"date":"2026-04-30T08:16:20","subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","submitter":{"id":93285,"url":"http://patchwork.ozlabs.org/api/people/93285/","name":"Kewen Lin","email":"linkw_gcc@126.com"},"content":"Hi Alexander,\n\n在 2026/4/30 15:42, Alexander Monakov 写道:\n> On Thu, 30 Apr 2026, Richard Biener wrote:\n> \n>> On Thu, Apr 30, 2026 at 4:10 AM Kewen Lin wrote:\n>>>\n>>> Hi Rainer & H.J.,\n>>>\n>>> 在 2026/4/30 6:31, H.J. Lu 写道:\n>>>> On Thu, Apr 30, 2026 at 5:24 AM Rainer Orth wrote:\n>>>>> between yesterday and today, I saw an increase in bootstrap times\n>>>>> between 37 and 75%:\n>>>>>\n>>>>> * i686-pc-linux-gnu, -j128 1:03:03 -> 1:50:00\n>>>>>\n>>>>> * i386-pc-solaris2.11, -j28 3:08:11.19 -> 4:18:22.77\n>>>>>\n>>>>> while the x86_64-pc-linux-gnu times are virtually unchanged. It seems\n>>>>> likely that this patch is the culprit. Is anyone else seeing the same?\n>>>>>\n>>>>\n>>>> Yes, I have seen a similar compile time increase on Linux/i686.\n>>>\n>>> Thanks for the information, we didn't test for i686 before, are trying to\n>>> reproduce this locally first. Did you happen to notice which part inceased\n>>> much or any suspicious point like automation gen etc.?\n>>\n>> genautomata now takes ages for me.\n> \n> I strongly suspect a part of it is improper divider unit modeling that was fixed\n> for other pipeline models in context of bug 87832. In particular, I see\n> \n> +;; IDIV\n> +(define_insn_reservation \"c86_4g_m7_idiv_DI\" 41\n> +\t\t\t (and (eq_attr \"cpu\" \"c86_4g_m7\")\n> +\t\t\t (and (eq_attr \"type\" \"idiv\")\n> +\t\t\t\t (and (eq_attr \"mode\" \"DI\")\n> +\t\t\t\t\t(eq_attr \"memory\" \"none\"))))\n> +\t\t\t \"c86-4g-m7-double,c86-4g-m7-ieu3*41\")\n> \n> and ieu3 appears to be an ALU used for other instructions, not the divider. This\n> likely blows up the automaton, and doesn't properly model the pipeline anyway.\n\nThanks for the insightful comments! I double checked the latency/through of this\ninstruction, it's 41 and 0.2 (1/41 = 0.2439....), so it can not pipelined (even partially).\nBut you raised a good point, I will revisit all other long latency instructions again.\n\n> \n> Kewen, please have a look at the patches linked from PR 87832, they all have\n> commit messages, and the strategy is not complicated (create a separate cpu_unit\n> for the partially-pipelined divider, use it in reservations, use throughput, not\n> latency figures ('*41' above is wrong): https://gcc.gnu.org/pr87832\n\nSure, thanks for the suggestion and explanation!!\n\nBR,\nKewen","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=126.com header.i=@126.com header.a=rsa-sha256\n header.s=s110527 header.b=oL0gp2Kg;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=38.145.34.32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=126.com header.i=@126.com header.a=rsa-sha256\n header.s=s110527 header.b=oL0gp2Kg","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=126.com","sourceware.org; spf=pass smtp.mailfrom=126.com","server2.sourceware.org;\n arc=none smtp.remote-ip=220.197.31.7"],"Received":["from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g5n9T3400z1yHZ\n\tfor ; Thu, 30 Apr 2026 18:18:05 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 6BF0C4310D48\n\tfor ; Thu, 30 Apr 2026 08:18:03 +0000 (GMT)","from m16.mail.126.com (m16.mail.126.com [220.197.31.7])\n by sourceware.org (Postfix) with ESMTPS id 6FE564310D55\n for ; Thu, 30 Apr 2026 08:16:48 +0000 (GMT)","from [172.19.23.14] (unknown [])\n by gzga-smtp-mtada-g0-4 (Coremail) with SMTP id\n _____wDXHyHlD_NpSQ9jAg--.52848S2;\n Thu, 30 Apr 2026 16:16:38 +0800 (CST)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 6BF0C4310D48","OpenDKIM Filter v2.11.0 sourceware.org 6FE564310D55"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 6FE564310D55","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 6FE564310D55","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777537009; cv=none;\n b=FN5t9NUGEZ0z+e1/EwvI1UyRFFyMLNblwIbqoliOkRpiw9GjnIBOHeS5JiZ8/P0jdp/q6hEqrxQGlnChVYIjbPNsIPCkdsJ9wHvIMz/mhT8VYQwGcXnudAXo7Ku+6rKEqXT2Y3uibnyi3iKyIw4cBiFN3hD9hf3L2bpL50h46bg=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777537009; c=relaxed/simple;\n bh=yAJQoOtkVNLSgJim6sZ8SeD6FRjuykC7d/7j70ZDZKo=;\n h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From;\n b=CIbolJXDUPW/KtwCIGvQR26CFlSq4yYjMRKVCD+AguguB2+hJgFuTAH2tJ2ZcAcWm5XssKs3GoI4N9152OSW6GsJj1iC2blUgKUtxb/r5DNep3wIav/5ZKjVglKEJv7Za060giWmED0KStG4+Aymnlag8F/ZKQqLNXUT+1Eywlc=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;\n s=s110527; h=Message-ID:Date:MIME-Version:Subject:To:From:\n Content-Type; bh=TQoDreVM3ElqhnwAoNa84ATQ75qyYB4bUqGIFO09pws=;\n b=oL0gp2KgmcOvzT9WNYb7E9P9hfnmlGj2RwhZUrWoJfdo32HAMGw3ozCCtVBddv\n RM2Grk1KVNeqCmMvUc0Z4+5Ww0xBk+TqJ+o+YF58j9DonVieju12Yj5VUgPULeHN\n ADUMj17m/wMBOV7eQocY0XKnSBU628utI8GtKbuJJz9Uc=","Message-ID":"<40624ddb-f767-42b4-8b13-1f9225df98dd@126.com>","Date":"Thu, 30 Apr 2026 16:16:20 +0800","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","To":"Alexander Monakov ,\n Richard Biener ","Cc":"\"H.J. Lu\" , Rainer Orth\n , Uros Bizjak ,\n Kewen Lin ,\n \"gcc-patches@gcc.gnu.org\" , Liulxx\n , Qingkuan Lai ,\n Feng Xue , \"hubicka@ucw.cz\" ,\n \"hongtao.liu@intel.com\" ","References":"<387794d9-199a-4373-97be-5e70e772e014@hygon.cn>\n \n \n \n \n \n <9e20997c-d94e-4115-b0bc-72c5c0744542@126.com>\n \n <243544d5-afa2-effa-d336-c4c78f52d1a6@ispras.ru>","From":"Kewen Lin ","In-Reply-To":"<243544d5-afa2-effa-d336-c4c78f52d1a6@ispras.ru>","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"8bit","X-CM-TRANSID":"_____wDXHyHlD_NpSQ9jAg--.52848S2","X-Coremail-Antispam":"1Uf129KBjvJXoW7ZFWfAr4rWw1DJFWfCF17KFg_yoW8tw18pr\n ZrZ3WkKr4Dtr1v9FykKws0q3WFqa95GFWUWrn8J34UAF9Yyw1Fqr92grWY9FyfXr18Aw17\n Aw4YvF9xW3WUAaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2\n 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07U6SoXUUUUU=","X-Originating-IP":"[112.64.138.194]","X-CM-SenderInfo":"5olqy4pbjfuqqrswhudrp/xtbBoQZU32nzD+Y-gQAA3h","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3684534,"web_url":"http://patchwork.ozlabs.org/comment/3684534/","msgid":"","list_archive_url":null,"date":"2026-04-30T08:32:07","subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","submitter":{"id":93285,"url":"http://patchwork.ozlabs.org/api/people/93285/","name":"Kewen Lin","email":"linkw_gcc@126.com"},"content":"在 2026/4/30 16:16, Kewen Lin 写道:\n> Hi Alexander,\n> \n> 在 2026/4/30 15:42, Alexander Monakov 写道:\n>> On Thu, 30 Apr 2026, Richard Biener wrote:\n>>\n>>> On Thu, Apr 30, 2026 at 4:10 AM Kewen Lin wrote:\n>>>>\n>>>> Hi Rainer & H.J.,\n>>>>\n>>>> 在 2026/4/30 6:31, H.J. Lu 写道:\n>>>>> On Thu, Apr 30, 2026 at 5:24 AM Rainer Orth wrote:\n>>>>>> between yesterday and today, I saw an increase in bootstrap times\n>>>>>> between 37 and 75%:\n>>>>>>\n>>>>>> * i686-pc-linux-gnu, -j128 1:03:03 -> 1:50:00\n>>>>>>\n>>>>>> * i386-pc-solaris2.11, -j28 3:08:11.19 -> 4:18:22.77\n>>>>>>\n>>>>>> while the x86_64-pc-linux-gnu times are virtually unchanged. It seems\n>>>>>> likely that this patch is the culprit. Is anyone else seeing the same?\n>>>>>>\n>>>>>\n>>>>> Yes, I have seen a similar compile time increase on Linux/i686.\n>>>>\n>>>> Thanks for the information, we didn't test for i686 before, are trying to\n>>>> reproduce this locally first. Did you happen to notice which part inceased\n>>>> much or any suspicious point like automation gen etc.?\n>>>\n>>> genautomata now takes ages for me.\n>>\n>> I strongly suspect a part of it is improper divider unit modeling that was fixed\n>> for other pipeline models in context of bug 87832. In particular, I see\n>>\n>> +;; IDIV\n>> +(define_insn_reservation \"c86_4g_m7_idiv_DI\" 41\n>> +\t\t\t (and (eq_attr \"cpu\" \"c86_4g_m7\")\n>> +\t\t\t (and (eq_attr \"type\" \"idiv\")\n>> +\t\t\t\t (and (eq_attr \"mode\" \"DI\")\n>> +\t\t\t\t\t(eq_attr \"memory\" \"none\"))))\n>> +\t\t\t \"c86-4g-m7-double,c86-4g-m7-ieu3*41\")\n>>\n>> and ieu3 appears to be an ALU used for other instructions, not the divider. This\n>> likely blows up the automaton, and doesn't properly model the pipeline anyway.\n> \n> Thanks for the insightful comments! I double checked the latency/through of this\n> instruction, it's 41 and 0.2 (1/41 = 0.2439....), so it can not pipelined (even partially).\n\nSorry for the typos, it's 0.02 (1/41 = 0.02439....).\n\nBR,\nKewen","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=126.com header.i=@126.com header.a=rsa-sha256\n header.s=s110527 header.b=QbbqZCCB;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=126.com header.i=@126.com header.a=rsa-sha256\n header.s=s110527 header.b=QbbqZCCB","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=126.com","sourceware.org; spf=pass smtp.mailfrom=126.com","server2.sourceware.org;\n arc=none smtp.remote-ip=220.197.31.9"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g5nZh5gQQz1yGq\n\tfor ; Thu, 30 Apr 2026 18:36:26 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id C173D4BABF25\n\tfor ; Thu, 30 Apr 2026 08:36:24 +0000 (GMT)","from m16.mail.126.com (m16.mail.126.com [220.197.31.9])\n by sourceware.org (Postfix) with ESMTPS id 8E398436A058\n for ; Thu, 30 Apr 2026 08:32:34 +0000 (GMT)","from [172.19.23.14] (unknown [])\n by gzga-smtp-mtada-g1-4 (Coremail) with SMTP id\n _____wD3X_WXE_NpnSflAg--.7154S2;\n Thu, 30 Apr 2026 16:32:24 +0800 (CST)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org C173D4BABF25","OpenDKIM Filter v2.11.0 sourceware.org 8E398436A058"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 8E398436A058","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 8E398436A058","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777537955; cv=none;\n b=UWh1jDB5rSvdik1/WJL/7dgjxMxHI0+rgrA3IjPUDsB5nzZN+iQoNmBHzJww8Ia0P0TA7QQFJtrShMi/NVt39vFsysD3oQ9xj+E5OOz6Js23yoeRV1Y5UeaRF+OiZCqvkJrWV81tIOGhrQftuLPHxvTQuvnXUVrAGx8EG+aImFs=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777537955; c=relaxed/simple;\n bh=OYPmw7uCycmaithTF2OlVWQUEhqy0nf7C+Aq1uJzRjQ=;\n h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From;\n b=HASbSxUcfPBMGbeO9793NwBhdUuztb+WNkTgAAawooLxIDgYe/jEL7EAF8C/IKTD1XXUX2eRTgvIZ8GfojncLCbHOvZU5te6sJkjaZDWlasSLu9JS+f3vkk28X6w6/0NFUSh9O4IrqbbhRKS8fm2YQHBuTDy8MSR9tD1frikEGI=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;\n s=s110527; h=Message-ID:Date:MIME-Version:Subject:To:From:\n Content-Type; bh=qBZ3C8h8OKlPAs+dvocUcAzWygU+gz3tHwmLnDaVI48=;\n b=QbbqZCCBwXNjJc/JkR+zfDANY6rT8XadAeJqpA09vKY7RWo0yA7ulkf2N66Jm/\n Jk2u1W1RHAUfwyV11zGNH0Ytc2RS+gnE7C40r7morKAKv+A8sVu6JeY1rhlCBYTF\n fBuFu4MOCf+0qGNHba3DAHWXJRHJa8D54cF1o0RhdhdNM=","Message-ID":"","Date":"Thu, 30 Apr 2026 16:32:07 +0800","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","To":"Alexander Monakov ,\n Richard Biener ","Cc":"\"H.J. Lu\" , Rainer Orth\n , Uros Bizjak ,\n Kewen Lin ,\n \"gcc-patches@gcc.gnu.org\" , Liulxx\n , Qingkuan Lai ,\n Feng Xue , \"hubicka@ucw.cz\" ,\n \"hongtao.liu@intel.com\" ","References":"<387794d9-199a-4373-97be-5e70e772e014@hygon.cn>\n \n \n \n \n \n <9e20997c-d94e-4115-b0bc-72c5c0744542@126.com>\n \n <243544d5-afa2-effa-d336-c4c78f52d1a6@ispras.ru>\n <40624ddb-f767-42b4-8b13-1f9225df98dd@126.com>","From":"Kewen Lin ","In-Reply-To":"<40624ddb-f767-42b4-8b13-1f9225df98dd@126.com>","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"8bit","X-CM-TRANSID":"_____wD3X_WXE_NpnSflAg--.7154S2","X-Coremail-Antispam":"1Uf129KBjvJXoW7tw4kGry8WF48ZFW7JF4DXFb_yoW8Zr4kpr\n WUJ3WkKr4DtryqkFyvqws0q3WYqFZ5ta1UWrn8J34UAF9Yyw13trn7KryY9FyfXr18Ar17\n Aw4jqry3X3WDAaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2\n 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07UD9N3UUUUU=","X-Originating-IP":"[112.64.138.194]","X-CM-SenderInfo":"5olqy4pbjfuqqrswhudrp/xtbBrxhCzWnzE5h1kAAA3M","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3684830,"web_url":"http://patchwork.ozlabs.org/comment/3684830/","msgid":"<69dfc47c-c14d-4c66-9fc7-4c28d2a4528b@126.com>","list_archive_url":null,"date":"2026-04-30T16:23:21","subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","submitter":{"id":93285,"url":"http://patchwork.ozlabs.org/api/people/93285/","name":"Kewen Lin","email":"linkw_gcc@126.com"},"content":"Hi Alexander,\n\n在 2026/4/30 15:42, Alexander Monakov 写道:\n> On Thu, 30 Apr 2026, Richard Biener wrote:\n> \n>> On Thu, Apr 30, 2026 at 4:10 AM Kewen Lin wrote:\n>>>\n>>> Hi Rainer & H.J.,\n>>>\n>>> 在 2026/4/30 6:31, H.J. Lu 写道:\n>>>> On Thu, Apr 30, 2026 at 5:24 AM Rainer Orth wrote:\n>>>>> between yesterday and today, I saw an increase in bootstrap times\n>>>>> between 37 and 75%:\n>>>>>\n>>>>> * i686-pc-linux-gnu, -j128 1:03:03 -> 1:50:00\n>>>>>\n>>>>> * i386-pc-solaris2.11, -j28 3:08:11.19 -> 4:18:22.77\n>>>>>\n>>>>> while the x86_64-pc-linux-gnu times are virtually unchanged. It seems\n>>>>> likely that this patch is the culprit. Is anyone else seeing the same?\n>>>>>\n>>>>\n>>>> Yes, I have seen a similar compile time increase on Linux/i686.\n>>>\n>>> Thanks for the information, we didn't test for i686 before, are trying to\n>>> reproduce this locally first. Did you happen to notice which part inceased\n>>> much or any suspicious point like automation gen etc.?\n>>\n>> genautomata now takes ages for me.\n> \n> I strongly suspect a part of it is improper divider unit modeling that was fixed\n> for other pipeline models in context of bug 87832. In particular, I see\n> \n> +;; IDIV\n> +(define_insn_reservation \"c86_4g_m7_idiv_DI\" 41\n> +\t\t\t (and (eq_attr \"cpu\" \"c86_4g_m7\")\n> +\t\t\t (and (eq_attr \"type\" \"idiv\")\n> +\t\t\t\t (and (eq_attr \"mode\" \"DI\")\n> +\t\t\t\t\t(eq_attr \"memory\" \"none\"))))\n> +\t\t\t \"c86-4g-m7-double,c86-4g-m7-ieu3*41\")\n> \n> and ieu3 appears to be an ALU used for other instructions, not the divider. This\n> likely blows up the automaton, and doesn't properly model the pipeline anyway.\n> \n> Kewen, please have a look at the patches linked from PR 87832, they all have\n> commit messages, and the strategy is not complicated (create a separate cpu_unit\n> for the partially-pipelined divider, use it in reservations, use throughput, not\n> latency figures ('*41' above is wrong): https://gcc.gnu.org/pr87832\n\nI went through the commits and made a draft patch as the bottom by\nfollowing commit r13-4956-gec1db9017939bb for not pipelined division.\nIt did make the compilation time issue gone, and it turned out the\ndivision etc. modeling caused a combinatorial explosion in the automaton\nas you suspected, see the details below:\n\nWith r17-202:\n\n *Tested stage-1 i686 build -j 32: 255 seconds*\n\n $ nm -CS -t d --defined-only gcc/insn-automata.o | sed 's/^[0-9]* 0*//' \\\n\t | sort -n | tail -20\n\t13896 r slm_transitions\n\t15360 r znver4_fp_store_transitions\n\t16760 r znver4_ieu_transitions\n\t17776 r bdver1_ieu_transitions\n\t20068 r bdver1_fp_check\n\t20068 r bdver1_fp_transitions\n\t20983 t internal_state_transition(int, DFA_chip*)\n\t22270 t internal_min_issue_delay(int, DFA_chip*)\n\t26208 r slm_min_issue_delay\n\t27244 r bdver1_fp_min_issue_delay\n\t28518 r glm_check\n\t28518 r glm_transitions\n\t33690 r geode_min_issue_delay\n\t45436 r znver4_fpu_min_issue_delay\n\t46980 r bdver3_fp_min_issue_delay\n\t49428 r glm_min_issue_delay\n\t53730 r btver2_fp_min_issue_delay\n\t53760 r znver1_fp_transitions\n\t93960 r bdver3_fp_transitions\n\t181744 r znver4_fpu_transitions\n\nWith culprit commit r17-203:\n\n *Tested stage-1 i686 build -j 32: 787 seconds*\n\n\t$ nm -CS -t d --defined-only gcc/insn-automata.o | sed 's/^[0-9]* 0*//' \\\n\t | sort -n | tail -20\n\t28518 r glm_check\n\t28518 r glm_transitions\n\t33690 r geode_min_issue_delay\n\t45436 r znver4_fpu_min_issue_delay\n\t46980 r bdver3_fp_min_issue_delay\n\t49428 r glm_min_issue_delay\n\t53730 r btver2_fp_min_issue_delay\n\t53760 r znver1_fp_transitions\n\t68160 r c86_4g_ieu_min_issue_delay\n\t93960 r bdver3_fp_transitions\n\t110080 r c86_4g_fp_min_issue_delay\n\t136320 r c86_4g_ieu_transitions\n\t181744 r znver4_fpu_transitions\n\t220160 r c86_4g_fp_transitions\n\t262988 r c86_4g_m7_fpu_base\n\t475225 r c86_4g_m7_ieu_min_issue_delay\n\t950450 r c86_4g_m7_ieu_transitions\n\t4010567 r c86_4g_m7_fpu_min_issue_delay\n\t5496908 r c86_4g_m7_fpu_check\n\t5496908 r c86_4g_m7_fpu_transitions\n\nWith this adjustment:\n\n *Tested stage-1 i686 build -j 32: 257 seconds*\n\n\t$ nm -CS -t d --defined-only gcc/insn-automata.o | sed 's/^[0-9]* 0*//' \\\n\t | sort -n | tail -20\n\n\t20068 r bdver1_fp_transitions\n\t22354 r c86_4g_m7_ieu_min_issue_delay\n\t25705 t internal_state_transition(int, DFA_chip*)\n\t26208 r slm_min_issue_delay\n\t27164 t internal_min_issue_delay(int, DFA_chip*)\n\t27244 r bdver1_fp_min_issue_delay\n\t28518 r glm_check\n\t28518 r glm_transitions\n\t33690 r geode_min_issue_delay\n\t33728 r c86_4g_fp_transitions\n\t45436 r znver4_fpu_min_issue_delay\n\t46980 r bdver3_fp_min_issue_delay\n\t49428 r glm_min_issue_delay\n\t53730 r btver2_fp_min_issue_delay\n\t53760 r znver1_fp_transitions\n\t89414 r c86_4g_m7_ieu_transitions\n\t93960 r bdver3_fp_transitions\n\t181744 r znver4_fpu_transitions\n\t326322 r c86_4g_m7_fpu_min_issue_delay\n\t1305288 r c86_4g_m7_fpu_transitions\n\nI have a question on this solution with \"fpu*N -> fpu,divider*N\",\nIIUC, the former means the insn occupies fpu for N cycles while\nthe later means it occupies fpu for 1 cycle and then divider for\nN cycles. From what I got from our hardware team colleages\nmonths ago, I think the former matches our hardware behavior\nbetter, we want scheduling to consider fpu unavailable for N cycles.\nFrom this perspective, does it mean this kind of adjustment is actually\na trade-off between exact modeling and automaton explosion?\n\nBR,\nKewen\n-----\nDraft patch:\n\ndiff --git a/gcc/config/i386/c86-4g-m7.md b/gcc/config/i386/c86-4g-m7.md\nindex 7eda123acaa..1fe23539b05 100644\n--- a/gcc/config/i386/c86-4g-m7.md\n+++ b/gcc/config/i386/c86-4g-m7.md\n@@ -19,8 +19,9 @@\n \n ;; HYGON c86-4g-m7 Scheduling\n ;; Modeling automatons for decoders, integer execution pipes,\n-;; AGU pipes, branch, floating point execution and fp store units.\n-(define_automaton \"c86_4g_m7, c86_4g_m7_ieu, c86_4g_m7_agu, c86_4g_m7_fpu\")\n+;; AGU pipes, branch, floating point execution, fp store units,\n+;; integer and floating point dividers.\n+(define_automaton \"c86_4g_m7, c86_4g_m7_ieu, c86_4g_m7_agu, c86_4g_m7_fpu, c86_4g_m7_idiv, c86_4g_m7_fdiv\")\n \n ;; Decoders unit has 4 decoders and all of them can decode fast path\n ;; and vector type instructions.\n@@ -29,6 +30,10 @@ (define_cpu_unit \"c86-4g-m7-decode1\" \"c86_4g_m7\")\n (define_cpu_unit \"c86-4g-m7-decode2\" \"c86_4g_m7\")\n (define_cpu_unit \"c86-4g-m7-decode3\" \"c86_4g_m7\")\n \n+;; Two separated dividers\n+(define_cpu_unit \"c86-4g-m7-idiv\" \"c86_4g_m7_idiv\")\n+(define_cpu_unit \"c86-4g-m7-fdiv\" \"c86_4g_m7_fdiv\")\n+\n ;; Currently blocking all decoders for vector path instructions as\n ;; they are dispatched separetely as microcode sequence.\n (define_reservation \"c86-4g-m7-vector\" \"c86-4g-m7-decode0+c86-4g-m7-decode1+c86-4g-m7-decode2+c86-4g-m7-decode3\")\n@@ -168,56 +173,56 @@ (define_insn_reservation \"c86_4g_m7_idiv_DI\" 41\n \t\t\t (and (eq_attr \"type\" \"idiv\")\n \t\t\t\t (and (eq_attr \"mode\" \"DI\")\n \t\t\t\t\t(eq_attr \"memory\" \"none\"))))\n-\t\t\t \"c86-4g-m7-double,c86-4g-m7-ieu3*41\")\n+\t\t\t \"c86-4g-m7-double,c86-4g-m7-ieu3,c86-4g-m7-idiv*41\")\n \n (define_insn_reservation \"c86_4g_m7_idiv_SI\" 25\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m7\")\n \t\t\t (and (eq_attr \"type\" \"idiv\")\n \t\t\t\t (and (eq_attr \"mode\" \"SI\")\n \t\t\t\t\t(eq_attr \"memory\" \"none\"))))\n-\t\t\t \"c86-4g-m7-double,c86-4g-m7-ieu3*25\")\n+\t\t\t \"c86-4g-m7-double,c86-4g-m7-ieu3,c86-4g-m7-idiv*25\")\n \n (define_insn_reservation \"c86_4g_m7_idiv_HI\" 17\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m7\")\n \t\t\t (and (eq_attr \"type\" \"idiv\")\n \t\t\t\t (and (eq_attr \"mode\" \"HI\")\n \t\t\t\t\t(eq_attr \"memory\" \"none\"))))\n-\t\t\t \"c86-4g-m7-double,c86-4g-m7-ieu3*17\")\n+\t\t\t \"c86-4g-m7-double,c86-4g-m7-ieu3,c86-4g-m7-idiv*17\")\n \n (define_insn_reservation \"c86_4g_m7_idiv_QI\" 15\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m7\")\n \t\t\t (and (eq_attr \"type\" \"idiv\")\n \t\t\t\t (and (eq_attr \"mode\" \"QI\")\n \t\t\t\t\t(eq_attr \"memory\" \"none\"))))\n-\t\t\t \"c86-4g-m7-direct,c86-4g-m7-ieu3*15\")\n+\t\t\t \"c86-4g-m7-direct,c86-4g-m7-ieu3,c86-4g-m7-idiv*15\")\n \n (define_insn_reservation \"c86_4g_m7_idiv_DI_load\" 45\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m7\")\n \t\t\t (and (eq_attr \"type\" \"idiv\")\n \t\t\t\t (and (eq_attr \"mode\" \"DI\")\n \t\t\t\t\t(eq_attr \"memory\" \"load\"))))\n-\t\t\t \"c86-4g-m7-double,c86-4g-m7-load,c86-4g-m7-ieu3*41\")\n+\t\t\t \"c86-4g-m7-double,c86-4g-m7-load,c86-4g-m7-ieu3,c86-4g-m7-idiv*41\")\n \n (define_insn_reservation \"c86_4g_m7_idiv_SI_load\" 29\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m7\")\n \t\t\t (and (eq_attr \"type\" \"idiv\")\n \t\t\t\t (and (eq_attr \"mode\" \"SI\")\n \t\t\t\t\t(eq_attr \"memory\" \"load\"))))\n-\t\t\t \"c86-4g-m7-double,c86-4g-m7-load,c86-4g-m7-ieu3*25\")\n+\t\t\t \"c86-4g-m7-double,c86-4g-m7-load,c86-4g-m7-ieu3,c86-4g-m7-idiv*25\")\n \n (define_insn_reservation \"c86_4g_m7_idiv_HI_load\" 21\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m7\")\n \t\t\t (and (eq_attr \"type\" \"idiv\")\n \t\t\t\t (and (eq_attr \"mode\" \"HI\")\n \t\t\t\t\t(eq_attr \"memory\" \"load\"))))\n-\t\t\t \"c86-4g-m7-double,c86-4g-m7-load,c86-4g-m7-ieu3*17\")\n+\t\t\t \"c86-4g-m7-double,c86-4g-m7-load,c86-4g-m7-ieu3,c86-4g-m7-idiv*17\")\n \n (define_insn_reservation \"c86_4g_m7_idiv_QI_load\" 19\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m7\")\n \t\t\t (and (eq_attr \"type\" \"idiv\")\n \t\t\t\t (and (eq_attr \"mode\" \"QI\")\n \t\t\t\t\t(eq_attr \"memory\" \"load\"))))\n-\t\t\t \"c86-4g-m7-direct,c86-4g-m7-load,c86-4g-m7-ieu3*15\")\n+\t\t\t \"c86-4g-m7-direct,c86-4g-m7-load,c86-4g-m7-ieu3,c86-4g-m7-idiv*15\")\n \n ;; Integer/genaral Instructions\n (define_insn_reservation \"c86_4g_m7_insn\" 1\n@@ -439,7 +444,7 @@ (define_insn_reservation \"c86_4g_m7fp_sqrt\" 22\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m7\")\n \t\t\t (and (eq_attr \"type\" \"fpspc\")\n \t\t\t\t (eq_attr \"c86_attr\" \"sqrt\")))\n-\t\t\t \"c86-4g-m7-direct,c86-4g-m7-fpu1*22\")\n+\t\t\t \"c86-4g-m7-direct,c86-4g-m7-fpu1,c86-4g-m7-fdiv*22\")\n \n ;; FPSPC\n (define_insn_reservation \"c86_4g_m7_fp_spc_direct\" 5\n@@ -482,21 +487,21 @@ (define_insn_reservation \"c86_4g_m7_fp_div\" 15\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m7\")\n \t\t\t (and (eq_attr \"type\" \"fdiv\")\n \t\t\t\t (eq_attr \"memory\" \"none\")))\n-\t\t\t \"c86-4g-m7-direct,c86-4g-m7-fpu1*7\")\n+\t\t\t \"c86-4g-m7-direct,c86-4g-m7-fpu1,c86-4g-m7-fdiv*15\")\n \n (define_insn_reservation \"c86_4g_m7_fp_div_load\" 22\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m7\")\n \t\t\t (and (eq_attr \"type\" \"fdiv\")\n \t\t\t\t (and (eq_attr \"fp_int_src\" \"false\")\n \t\t\t\t\t(eq_attr \"memory\" \"!none\"))))\n-\t\t\t \"c86-4g-m7-direct,c86-4g-m7-load,c86-4g-m7-fpu1*7\")\n+\t\t\t \"c86-4g-m7-direct,c86-4g-m7-load,c86-4g-m7-fpu1,c86-4g-m7-fdiv*15\")\n \n (define_insn_reservation \"c86_4g_m7_fp_idiv_load\" 26\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m7\")\n \t\t\t (and (eq_attr \"type\" \"fdiv\")\n \t\t\t\t (and (eq_attr \"fp_int_src\" \"true\")\n \t\t\t\t\t(eq_attr \"memory\" \"!none\"))))\n-\t\t\t \"c86-4g-m7-double,c86-4g-m7-load,c86-4g-m7-fpu1*7\")\n+\t\t\t \"c86-4g-m7-double,c86-4g-m7-load,c86-4g-m7-fpu1,c86-4g-m7-fdiv*15\")\n \n (define_insn_reservation \"c86_4g_m7_fp_fsgn\" 1\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m7\")\n@@ -1531,28 +1536,28 @@ (define_insn_reservation \"c86_4g_m7_avx512_ssediv\" 13\n \t\t\t (and (eq_attr \"type\" \"ssediv\")\n \t\t\t\t (and (not (eq_attr \"mode\" \"V16SF,V8DF\"))\n \t\t\t\t\t(eq_attr \"memory\" \"none\"))))\n-\t\t\t \"c86-4g-m7-direct,c86-4g-m7-fpu3*7\")\n+\t\t\t \"c86-4g-m7-direct,c86-4g-m7-fpu3,c86-4g-m7-fdiv*13\")\n \n (define_insn_reservation \"c86_4g_m7_avx512_ssediv_mem\" 20\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m7\")\n \t\t\t (and (eq_attr \"type\" \"ssediv\")\n \t\t\t\t (and (not (eq_attr \"mode\" \"V16SF,V8DF\"))\n \t\t\t\t\t(eq_attr \"memory\" \"load\"))))\n-\t\t\t \"c86-4g-m7-direct,c86-4g-m7-load,c86-4g-m7-fpu3*7\")\n+\t\t\t \"c86-4g-m7-direct,c86-4g-m7-load,c86-4g-m7-fpu3,c86-4g-m7-fdiv*13\")\n \n (define_insn_reservation \"c86_4g_m7_avx512_ssediv_z\" 24\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m7\")\n \t\t\t (and (eq_attr \"type\" \"ssediv\")\n \t\t\t\t (and (eq_attr \"mode\" \"V16SF,V8DF\")\n \t\t\t\t\t(eq_attr \"memory\" \"none\"))))\n-\t\t\t \"c86-4g-m7-double,c86-4g-m7-fpu3*7\")\n+\t\t\t \"c86-4g-m7-double,c86-4g-m7-fpu3,c86-4g-m7-fdiv*24\")\n \n (define_insn_reservation \"c86_4g_m7_avx512_ssediv_zmem\" 31\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m7\")\n \t\t\t (and (eq_attr \"type\" \"ssediv\")\n \t\t\t\t (and (eq_attr \"mode\" \"V16SF,V8DF\")\n \t\t\t\t\t (eq_attr \"memory\" \"load\"))))\n-\t\t\t \"c86-4g-m7-double,c86-4g-m7-load,c86-4g-m7-fpu3*7\")\n+\t\t\t \"c86-4g-m7-double,c86-4g-m7-load,c86-4g-m7-fpu3,c86-4g-m7-fdiv*24\")\n \n ;; SSECMP\n (define_insn_reservation \"c86_4g_m7_avx512_ssecmp\" 5\n@@ -1932,14 +1937,14 @@ (define_insn_reservation \"c86_4g_m7_avx512_sse_sqrt\" 16\n \t\t\t (and (eq_attr \"type\" \"sse\")\n \t\t\t\t (and (eq_attr \"c86_attr\" \"sqrt\")\n \t\t\t\t\t(eq_attr \"memory\" \"none\"))))\n-\t\t\t \"c86-4g-m7-direct,c86-4g-m7-fpu1*7|c86-4g-m7-fpu3*7\")\n+\t\t\t \"c86-4g-m7-direct,c86-4g-m7-fpu1|c86-4g-m7-fpu3,c86-4g-m7-fdiv*16\")\n \n (define_insn_reservation \"c86_4g_m7_avx512_sse_sqrt_load\" 23\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m7\")\n \t\t\t (and (eq_attr \"type\" \"sse\")\n \t\t\t\t (and (eq_attr \"c86_attr\" \"sqrt\")\n \t\t\t\t\t(eq_attr \"memory\" \"load\"))))\n-\t\t\t \"c86-4g-m7-direct,c86-4g-m7-load,c86-4g-m7-fpu1*7|c86-4g-m7-fpu3*7\")\n+\t\t\t \"c86-4g-m7-direct,c86-4g-m7-load,c86-4g-m7-fpu1|c86-4g-m7-fpu3,c86-4g-m7-fdiv*16\")\n \n ;; MSKLOG/MSKMOV\n (define_insn_reservation \"c86_4g_m7_avx512_msklog\" 1\ndiff --git a/gcc/config/i386/c86-4g.md b/gcc/config/i386/c86-4g.md\nindex 66c4e2cf744..c5669786e09 100644\n--- a/gcc/config/i386/c86-4g.md\n+++ b/gcc/config/i386/c86-4g.md\n@@ -29,8 +29,9 @@ (define_attr \"c86_attr\" \"other,abs,sqrt,maxmin,blend,blendv,rcp,movnt,avg,\n \n ;; HYGON Scheduling\n ;; Modeling automatons for decoders, integer execution pipes,\n-;; AGU pipes and floating point execution units.\n-(define_automaton \"c86_4g, c86_4g_ieu, c86_4g_fp, c86_4g_agu\")\n+;; AGU pipes, floating point execution units, integer and\n+;; floating point dividers.\n+(define_automaton \"c86_4g, c86_4g_ieu, c86_4g_fp, c86_4g_agu, c86_4g_idiv, c86_4g_fdiv\")\n \n ;; Decoders unit has 4 decoders and all of them can decode fast path\n ;; and vector type instructions.\n@@ -39,6 +40,10 @@ (define_cpu_unit \"c86-4g-decode1\" \"c86_4g\")\n (define_cpu_unit \"c86-4g-decode2\" \"c86_4g\")\n (define_cpu_unit \"c86-4g-decode3\" \"c86_4g\")\n \n+;; Two separated dividers\n+(define_cpu_unit \"c86-4g-idiv\" \"c86_4g_idiv\")\n+(define_cpu_unit \"c86-4g-fdiv\" \"c86_4g_fdiv\")\n+\n ;; Currently blocking all decoders for vector path instructions as\n ;; they are dispatched separetely as microcode sequence.\n ;; Fix me: Need to revisit this.\n@@ -146,28 +151,28 @@ (define_insn_reservation \"c86_4g_idiv_DI\" 41\n \t\t\t (and (eq_attr \"type\" \"idiv\")\n \t\t\t\t (and (eq_attr \"mode\" \"DI\")\n \t\t\t\t\t(eq_attr \"memory\" \"none\"))))\n-\t\t\t \"c86-4g-double,c86-4g-ieu2*41\")\n+\t\t\t \"c86-4g-double,c86-4g-ieu2,c86-4g-idiv*41\")\n \n (define_insn_reservation \"c86_4g_idiv_SI\" 25\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m4,c86_4g_m6\")\n \t\t\t (and (eq_attr \"type\" \"idiv\")\n \t\t\t\t (and (eq_attr \"mode\" \"SI\")\n \t\t\t\t\t(eq_attr \"memory\" \"none\"))))\n-\t\t\t \"c86-4g-double,c86-4g-ieu2*25\")\n+\t\t\t \"c86-4g-double,c86-4g-ieu2,c86-4g-idiv*25\")\n \n (define_insn_reservation \"c86_4g_idiv_HI\" 17\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m4,c86_4g_m6\")\n \t\t\t (and (eq_attr \"type\" \"idiv\")\n \t\t\t\t (and (eq_attr \"mode\" \"HI\")\n \t\t\t\t\t(eq_attr \"memory\" \"none\"))))\n-\t\t\t \"c86-4g-double,c86-4g-ieu2*17\")\n+\t\t\t \"c86-4g-double,c86-4g-ieu2,c86-4g-idiv*17\")\n \n (define_insn_reservation \"c86_4g_idiv_QI\" 15\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m4,c86_4g_m6\")\n \t\t\t (and (eq_attr \"type\" \"idiv\")\n \t\t\t\t (and (eq_attr \"mode\" \"QI\")\n \t\t\t\t\t(eq_attr \"memory\" \"none\"))))\n-\t\t\t \"c86-4g-direct,c86-4g-ieu2*15\")\n+\t\t\t \"c86-4g-direct,c86-4g-ieu2,c86-4g-idiv*15\")\n \n ;; Mem operands\n (define_insn_reservation \"c86_4g_idiv_mem_DI\" 45\n@@ -175,28 +180,28 @@ (define_insn_reservation \"c86_4g_idiv_mem_DI\" 45\n \t\t\t (and (eq_attr \"type\" \"idiv\")\n \t\t\t\t (and (eq_attr \"mode\" \"DI\")\n \t\t\t\t\t(eq_attr \"memory\" \"load\"))))\n-\t\t\t \"c86-4g-double,c86-4g-load,c86-4g-ieu2*41\")\n+\t\t\t \"c86-4g-double,c86-4g-load,c86-4g-ieu2,c86-4g-idiv*41\")\n \n (define_insn_reservation \"c86_4g_idiv_mem_SI\" 29\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m4,c86_4g_m6\")\n \t\t\t (and (eq_attr \"type\" \"idiv\")\n \t\t\t\t (and (eq_attr \"mode\" \"SI\")\n \t\t\t\t\t(eq_attr \"memory\" \"load\"))))\n-\t\t\t \"c86-4g-double,c86-4g-load,c86-4g-ieu2*25\")\n+\t\t\t \"c86-4g-double,c86-4g-load,c86-4g-ieu2,c86-4g-idiv*25\")\n \n (define_insn_reservation \"c86_4g_idiv_mem_HI\" 21\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m4,c86_4g_m6\")\n \t\t\t (and (eq_attr \"type\" \"idiv\")\n \t\t\t\t (and (eq_attr \"mode\" \"HI\")\n \t\t\t\t\t(eq_attr \"memory\" \"load\"))))\n-\t\t\t \"c86-4g-double,c86-4g-load,c86-4g-ieu2*17\")\n+\t\t\t \"c86-4g-double,c86-4g-load,c86-4g-ieu2,c86-4g-idiv*17\")\n \n (define_insn_reservation \"c86_4g_idiv_mem_QI\" 19\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m4,c86_4g_m6\")\n \t\t\t (and (eq_attr \"type\" \"idiv\")\n \t\t\t\t (and (eq_attr \"mode\" \"QI\")\n \t\t\t\t\t(eq_attr \"memory\" \"load\"))))\n-\t\t\t \"c86-4g-direct,c86-4g-load,c86-4g-ieu2*15\")\n+\t\t\t \"c86-4g-direct,c86-4g-load,c86-4g-ieu2,c86-4g-idiv*15\")\n \n ;; STR ISHIFT which are micro coded.\n ;; Fix me: Latency need to be rechecked.\n@@ -382,7 +387,7 @@ (define_insn_reservation \"c86_4g_fp_sqrt\" 22\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m4,c86_4g_m6\")\n \t\t\t (and (eq_attr \"type\" \"fpspc\")\n \t\t\t\t (eq_attr \"c86_attr\" \"sqrt\")))\n-\t\t\t \"c86-4g-direct,c86-4g-fp1*22\")\n+\t\t\t \"c86-4g-direct,c86-4g-fp1,c86-4g-fdiv*22\")\n \n (define_insn_reservation \"c86_4g_sse_sqrt_sf\" 14\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m4,c86_4g_m6\")\n@@ -390,7 +395,7 @@ (define_insn_reservation \"c86_4g_sse_sqrt_sf\" 14\n \t\t\t\t (and (eq_attr \"memory\" \"none,unknown\")\n \t\t\t\t\t(and (eq_attr \"c86_attr\" \"sqrt\")\n \t\t\t\t\t (eq_attr \"type\" \"sse\")))))\n-\t\t\t \"c86-4g-direct,c86-4g-fp1*14\")\n+\t\t\t \"c86-4g-direct,c86-4g-fp1,c86-4g-fdiv*14\")\n \n (define_insn_reservation \"c86_4g_sse_sqrt_sf_mem\" 21\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m4,c86_4g_m6\")\n@@ -398,7 +403,7 @@ (define_insn_reservation \"c86_4g_sse_sqrt_sf_mem\" 21\n \t\t\t\t (and (eq_attr \"memory\" \"load\")\n \t\t\t\t\t(and (eq_attr \"c86_attr\" \"sqrt\")\n \t\t\t\t\t (eq_attr \"type\" \"sse\")))))\n-\t\t\t \"c86-4g-direct,c86-4g-load,c86-4g-fp1*14\")\n+\t\t\t \"c86-4g-direct,c86-4g-load,c86-4g-fp1,c86-4g-fdiv*14\")\n \n (define_insn_reservation \"c86_4g_sse_sqrt_df\" 20\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m4,c86_4g_m6\")\n@@ -406,7 +411,7 @@ (define_insn_reservation \"c86_4g_sse_sqrt_df\" 20\n \t\t\t\t (and (eq_attr \"memory\" \"none,unknown\")\n \t\t\t\t\t(and (eq_attr \"c86_attr\" \"sqrt\")\n \t\t\t\t\t (eq_attr \"type\" \"sse\")))))\n-\t\t\t \"c86-4g-direct,c86-4g-fp1*20\")\n+\t\t\t \"c86-4g-direct,c86-4g-fp1,c86-4g-fdiv*20\")\n \n (define_insn_reservation \"c86_4g_sse_sqrt_df_mem\" 27\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m4,c86_4g_m6\")\n@@ -414,7 +419,7 @@ (define_insn_reservation \"c86_4g_sse_sqrt_df_mem\" 27\n \t\t\t\t (and (eq_attr \"memory\" \"load\")\n \t\t\t\t\t(and (eq_attr \"c86_attr\" \"sqrt\")\n \t\t\t\t\t (eq_attr \"type\" \"sse\")))))\n-\t\t\t \"c86-4g-direct,c86-4g-load,c86-4g-fp1*20\")\n+\t\t\t \"c86-4g-direct,c86-4g-load,c86-4g-fp1,c86-4g-fdiv*20\")\n \n ;; RCP\n (define_insn_reservation \"c86_4g_sse_rcp\" 5\n@@ -487,20 +492,20 @@ (define_insn_reservation \"c86_4g_fp_op_div\" 15\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m4,c86_4g_m6\")\n \t\t\t (and (eq_attr \"type\" \"fdiv\")\n \t\t\t\t (eq_attr \"memory\" \"none\")))\n-\t\t\t \"c86-4g-direct,c86-4g-fp1*15\")\n+\t\t\t \"c86-4g-direct,c86-4g-fp1,c86-4g-fdiv*15\")\n \n (define_insn_reservation \"c86_4g_fp_op_div_load\" 22\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m4,c86_4g_m6\")\n \t\t\t (and (eq_attr \"type\" \"fdiv\")\n \t\t\t\t (eq_attr \"memory\" \"load\")))\n-\t\t\t \"c86-4g-direct,c86-4g-load,c86-4g-fp1*15\")\n+\t\t\t \"c86-4g-direct,c86-4g-load,c86-4g-fp1,c86-4g-fdiv*15\")\n \n (define_insn_reservation \"c86_4g_fp_op_idiv_load\" 27\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m4,c86_4g_m6\")\n \t\t\t (and (eq_attr \"type\" \"fdiv\")\n \t\t\t\t (and (eq_attr \"fp_int_src\" \"true\")\n \t\t\t\t\t(eq_attr \"memory\" \"load\"))))\n-\t\t\t \"c86-4g-double,c86-4g-load,c86-4g-fp1*19\")\n+\t\t\t \"c86-4g-double,c86-4g-load,c86-4g-fp1,c86-4g-fdiv*19\")\n \n ;; MMX, SSE, SSEn.n, AVX, AVX2 instructions\n (define_insn_reservation \"c86_4g_fp_insn\" 1\n@@ -1019,28 +1024,28 @@ (define_insn_reservation \"c86_4g_ssediv_ss_ps\" 10\n \t\t\t\t\t(eq_attr \"mode\" \"V4SF,SF\"))\n \t\t\t (and (eq_attr \"type\" \"ssediv\")\n \t\t\t\t (eq_attr \"memory\" \"none\")))\n-\t\t\t \"c86-4g-direct,c86-4g-fp1*10\")\n+\t\t\t \"c86-4g-direct,c86-4g-fp1,c86-4g-fdiv*10\")\n \n (define_insn_reservation \"c86_4g_ssediv_ss_ps_load\" 17\n \t\t\t (and (and (eq_attr \"cpu\" \"c86_4g_m4,c86_4g_m6\")\n \t\t\t\t\t(eq_attr \"mode\" \"V4SF,SF\"))\n \t\t\t (and (eq_attr \"type\" \"ssediv\")\n \t\t\t\t (eq_attr \"memory\" \"load\")))\n-\t\t\t \"c86-4g-direct,c86-4g-load,c86-4g-fp1*10\")\n+\t\t\t \"c86-4g-direct,c86-4g-load,c86-4g-fp1,c86-4g-fdiv*10\")\n \n (define_insn_reservation \"c86_4g_ssediv_sd_pd\" 13\n \t\t\t (and (and (eq_attr \"cpu\" \"c86_4g_m4,c86_4g_m6\")\n \t\t\t\t\t(eq_attr \"mode\" \"V2DF,DF\"))\n \t\t\t (and (eq_attr \"type\" \"ssediv\")\n \t\t\t\t (eq_attr \"memory\" \"none\")))\n-\t\t\t \"c86-4g-direct,c86-4g-fp1*13\")\n+\t\t\t \"c86-4g-direct,c86-4g-fp1,c86-4g-fdiv*13\")\n \n (define_insn_reservation \"c86_4g_ssediv_sd_pd_load\" 20\n \t\t\t (and (and (eq_attr \"cpu\" \"c86_4g_m4,c86_4g_m6\")\n \t\t\t\t\t (eq_attr \"mode\" \"V2DF,DF\"))\n \t\t\t (and (eq_attr \"type\" \"ssediv\")\n \t\t\t\t (eq_attr \"memory\" \"load\")))\n-\t\t\t \"c86-4g-direct,c86-4g-load,c86-4g-fp1*13\")\n+\t\t\t \"c86-4g-direct,c86-4g-load,c86-4g-fp1,c86-4g-fdiv*13\")\n \n \n (define_insn_reservation \"c86_4g_ssediv_avx256_ps\" 10\n@@ -1048,28 +1053,28 @@ (define_insn_reservation \"c86_4g_ssediv_avx256_ps\" 10\n \t\t\t (and (eq_attr \"mode\" \"V8SF\")\n \t\t\t\t (and (eq_attr \"memory\" \"none\")\n \t\t\t\t\t(eq_attr \"type\" \"ssediv\"))))\n-\t\t\t \"c86-4g-double,c86-4g-fp1*10\")\n+\t\t\t \"c86-4g-double,c86-4g-fp1,c86-4g-fdiv*10\")\n \n (define_insn_reservation \"c86_4g_ssediv_avx256_ps_load\" 17\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m4,c86_4g_m6\")\n \t\t\t (and (eq_attr \"mode\" \"V8SF\")\n \t\t\t\t (and (eq_attr \"type\" \"ssediv\")\n \t\t\t\t\t(eq_attr \"memory\" \"load\"))))\n-\t\t\t \"c86-4g-double,c86-4g-load,c86-4g-fp1*10\")\n+\t\t\t \"c86-4g-double,c86-4g-load,c86-4g-fp1,c86-4g-fdiv*10\")\n \n (define_insn_reservation \"c86_4g_ssediv_avx256_pd\" 13\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m4,c86_4g_m6\")\n \t\t\t (and (eq_attr \"mode\" \"V4DF\")\n \t\t\t\t (and (eq_attr \"type\" \"ssediv\")\n \t\t\t\t\t(eq_attr \"memory\" \"none\"))))\n-\t\t\t \"c86-4g-double,c86-4g-fp1*13\")\n+\t\t\t \"c86-4g-double,c86-4g-fp1,c86-4g-fdiv*13\")\n \n (define_insn_reservation \"c86_4g_ssediv_avx256_pd_load\" 20\n \t\t\t (and (eq_attr \"cpu\" \"c86_4g_m4,c86_4g_m6\")\n \t\t\t (and (eq_attr \"mode\" \"V4DF\")\n \t\t\t\t (and (eq_attr \"type\" \"ssediv\")\n \t\t\t\t\t(eq_attr \"memory\" \"load\"))))\n-\t\t\t \"c86-4g-double,c86-4g-load,c86-4g-fp1*13\")\n+\t\t\t \"c86-4g-double,c86-4g-load,c86-4g-fp1,c86-4g-fdiv*13\")\n ;; SSE MUL\n (define_insn_reservation \"c86_4g_ssemul_ss_ps\" 3\n \t\t\t (and (and (eq_attr \"cpu\" \"c86_4g_m4,c86_4g_m6\")","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=126.com header.i=@126.com header.a=rsa-sha256\n header.s=s110527 header.b=EfOE88MA;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=38.145.34.32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=126.com header.i=@126.com header.a=rsa-sha256\n header.s=s110527 header.b=EfOE88MA","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=126.com","sourceware.org; spf=pass smtp.mailfrom=126.com","server2.sourceware.org;\n arc=none smtp.remote-ip=220.197.31.7"],"Received":["from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g5zyn0qzbz1xqf\n\tfor ; Fri, 01 May 2026 02:24:31 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id C6FD5436F3E1\n\tfor ; Thu, 30 Apr 2026 16:24:29 +0000 (GMT)","from m16.mail.126.com (m16.mail.126.com [220.197.31.7])\n by sourceware.org (Postfix) with ESMTPS id 46E2743B552A\n for ; Thu, 30 Apr 2026 16:23:54 +0000 (GMT)","from [192.168.50.216] (unknown [])\n by gzga-smtp-mtada-g1-4 (Coremail) with SMTP id\n _____wD3F3YKgvNpHDD+Ag--.39991S2;\n Fri, 01 May 2026 00:23:40 +0800 (CST)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org C6FD5436F3E1","OpenDKIM Filter v2.11.0 sourceware.org 46E2743B552A"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 46E2743B552A","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 46E2743B552A","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777566236; cv=none;\n b=he6SFbeufaiGbL1mY0SqUj9eLoTSoNeNquSYpFU8e2cLwWejWQuJxc8WUM8raKicd2Tty2w4KsLAhsPwJut3XM+x3rM/foljZNrotA8qW4geFlmA5nlnud0CxV7m6UfvZa+ZtnFkHZ6QRhtT6YFwexxhBNyuBzhkObaWXjtdqsY=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777566236; c=relaxed/simple;\n bh=Y9oVoh6LHszBpfvyBhC1jkdz6OxB9OMol3ELguNdSz4=;\n h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From;\n b=rDZQiN9Wi33c2kYLl3BSw4VmJBcJeP8ACSY66ZsaFyjkmr0xo56C1Ntv7BOteESH1EwNbBUXnZJZ8Ult9XP4eK4tqGmMSzibTwcVhV08dTc+TsRfMk0vhUiAxvUES8BIVGyhKxmAu8hnSkRyjUhYrDm0Hxd1j4OaFYG0V0SPvnE=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;\n s=s110527; h=Message-ID:Date:MIME-Version:Subject:To:From:\n Content-Type; bh=0WPRM9O16AQ9A1ZndutwRbinL6owqPcyxjEfSc7h1Mo=;\n b=EfOE88MAkJ/k5VXEmNvJc8Q7EZ172MofbNRhz05gs5YFzbT6OUkU/YVLDSv1dc\n rcIC053AIEtvPMZcGUidQZHlrUKuTfTTvvCIGqZC4ke0lPPj8vwQ7J7QWPdpETuA\n P8gL2f0VlenxnS67bNvAj/0CJjir+qf16JTO6bz1qA+Kk=","Message-ID":"<69dfc47c-c14d-4c66-9fc7-4c28d2a4528b@126.com>","Date":"Fri, 1 May 2026 00:23:21 +0800","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","To":"Alexander Monakov ","Cc":"\"H.J. Lu\" , Rainer Orth\n , Uros Bizjak ,\n Kewen Lin ,\n \"gcc-patches@gcc.gnu.org\" , Liulxx\n , Qingkuan Lai ,\n Feng Xue , \"hubicka@ucw.cz\" ,\n \"hongtao.liu@intel.com\" ,\n Richard Biener ","References":"<387794d9-199a-4373-97be-5e70e772e014@hygon.cn>\n \n \n \n \n \n <9e20997c-d94e-4115-b0bc-72c5c0744542@126.com>\n \n <243544d5-afa2-effa-d336-c4c78f52d1a6@ispras.ru>","From":"Kewen Lin ","In-Reply-To":"<243544d5-afa2-effa-d336-c4c78f52d1a6@ispras.ru>","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"8bit","X-CM-TRANSID":"_____wD3F3YKgvNpHDD+Ag--.39991S2","X-Coremail-Antispam":"1Uf129KBjvAXoWfKr43Zry5ArWUKr47JrWxXrb_yoW8trW8Ao\n WUAF17KrWUJan8t3sxKa4kt3WDuFyfGr4ktr4UKFy5AFyfWr4q93W7Xa15W34fZr48Gr4q\n yF4Fkry5JryFqFykn29KB7ZKAUJUUUU8529EdanIXcx71UUUUU7v73VFW2AGmfu7bjvjm3\n AaLaJ3UbIYCTnIWIevJa73UjIFyTuYvjxU5YL9UUUUU","X-Originating-IP":"[114.84.10.184]","X-CM-SenderInfo":"5olqy4pbjfuqqrswhudrp/xtbBoA36hmnzgg0nyAAA3r","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3684970,"web_url":"http://patchwork.ozlabs.org/comment/3684970/","msgid":"","list_archive_url":null,"date":"2026-04-30T22:28:29","subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","submitter":{"id":671,"url":"http://patchwork.ozlabs.org/api/people/671/","name":"Jakub Jelinek","email":"jakub@redhat.com"},"content":"On Thu, Apr 30, 2026 at 08:37:43AM +0200, Richard Biener wrote:\n> > >>>> Is it ok for trunk?\n> > >>>\n> > >>> OK.\n> > >>\n> > >> between yesterday and today, I saw an increase in bootstrap times\n> > >> between 37 and 75%:\n> > >>\n> > >> * i686-pc-linux-gnu, -j128 1:03:03 -> 1:50:00\n> > >>\n> > >> * i386-pc-solaris2.11, -j28 3:08:11.19 -> 4:18:22.77\n> > >>\n> > >> while the x86_64-pc-linux-gnu times are virtually unchanged. It seems\n> > >> likely that this patch is the culprit. Is anyone else seeing the same?\n> > >>\n> > >\n> > > Yes, I have seen a similar compile time increase on Linux/i686.\n> >\n> > Thanks for the information, we didn't test for i686 before, are trying to\n> > reproduce this locally first. Did you happen to notice which part inceased\n> > much or any suspicious point like automation gen etc.?\n> \n> genautomata now takes ages for me.\n\ni686-linux stage1 genautomata ran for more than 50 minutes on a pretty fast box.\nstage2 genautomata is still running for me, so far 9m.\n\n\tJakub","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=WvQJMW5C;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=38.145.34.32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=WvQJMW5C","sourceware.org; dmarc=pass (p=quarantine dis=none)\n header.from=redhat.com","sourceware.org; spf=pass smtp.mailfrom=redhat.com","server2.sourceware.org;\n arc=none smtp.remote-ip=170.10.129.124"],"Received":["from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g683j6q8wz1y1d\n\tfor ; Fri, 01 May 2026 08:29:21 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id C83E04374213\n\tfor ; Thu, 30 Apr 2026 22:29:14 +0000 (GMT)","from us-smtp-delivery-124.mimecast.com\n (us-smtp-delivery-124.mimecast.com [170.10.129.124])\n by sourceware.org (Postfix) with ESMTP id 7C5F64374213\n for ; Thu, 30 Apr 2026 22:28:48 +0000 (GMT)","from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com\n (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by\n relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,\n cipher=TLS_AES_256_GCM_SHA384) id us-mta-275-WKKY8PdKPoWn4Ruab3R9UA-1; Thu,\n 30 Apr 2026 18:28:41 -0400","from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com\n (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS\n id D7DB518002D1; Thu, 30 Apr 2026 22:28:38 +0000 (UTC)","from tucnak.zalov.cz (unknown [10.44.34.21])\n by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with\n ESMTPS\n id 8A6B91955D84; Thu, 30 Apr 2026 22:28:36 +0000 (UTC)","from tucnak.zalov.cz (localhost [127.0.0.1])\n by tucnak.zalov.cz (8.18.1/8.18.1) with ESMTPS id 63UMSXih1161641\n (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT);\n Fri, 1 May 2026 00:28:33 +0200","(from jakub@localhost)\n by tucnak.zalov.cz (8.18.1/8.18.1/Submit) id 63UMSUAJ1159424;\n Fri, 1 May 2026 00:28:30 +0200"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org C83E04374213","OpenDKIM Filter v2.11.0 sourceware.org 7C5F64374213"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 7C5F64374213","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 7C5F64374213","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777588128; cv=none;\n b=fvljSNhj9Y4512ih+ywDjcEh42r/+t2FQULLgzRmmiGj7ZXyplvZ82BkWpBLVv91/G+ogkdLvU+yooeDlyWZDlFcbfUoidQcPrAsTtViHU/aN/E2txiGSfrNY7Vi2GUkcdoFsKrFjBY5Di5kw1BEfFuOia80Vk8Yg8qS7zW70xs=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777588128; c=relaxed/simple;\n bh=ZuNIJZUJI45FfQbaD+yzkTNDLvsgIZqM7iUXkT4nxW0=;\n h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version;\n b=oyWyF4VMsq0FYWKye2l0108pahS0OOXzt9D0aWhPJHWjVmeF/iGkfdj23AW/u0nrt/hcFoyxC+gynwzF28X9e2xpTFAJTt6yWEhXpLX9i+HZkpzAknnSAghhWLXQZ7CMbquQS/NHjPrZWiJ3exq/Y9O7r6GZCoMwvjUh4fhK2Fo=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1777588128;\n h=from:from:reply-to:reply-to:subject:subject:date:date:\n message-id:message-id:to:to:cc:cc:mime-version:mime-version:\n content-type:content-type:in-reply-to:in-reply-to: references:references;\n bh=PaUwDe2ykacnU0TLP2+lwKvjh6Fmci3M7sCCCuRydms=;\n b=WvQJMW5CGuq+pK2mX4pC3Fr9Y1Po+jf3TlST6Lyj1dtWclpMmyoDC8cGIa3VHQnnrAMHly\n vL0AuezTjvfsCrfw8qwWFm6APvEuGDtDL49Z8NuUXjdL/FV11oQ3zt/asEwMeMagRVJQx8\n CiTvvnXy2r6zBO3mkXWQO3UfEvHaMSQ=","X-MC-Unique":"WKKY8PdKPoWn4Ruab3R9UA-1","X-Mimecast-MFC-AGG-ID":"WKKY8PdKPoWn4Ruab3R9UA_1777588119","Date":"Fri, 1 May 2026 00:28:29 +0200","From":"Jakub Jelinek ","To":"Richard Biener ","Cc":"Kewen Lin , \"H.J. Lu\" ,\n Rainer Orth ,\n Uros Bizjak , Kewen Lin ,\n \"gcc-patches@gcc.gnu.org\" ,\n Liulxx , Qingkuan Lai ,\n Feng Xue , \"hubicka@ucw.cz\" ,\n \"hongtao.liu@intel.com\" ","Subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","Message-ID":"","References":"<387794d9-199a-4373-97be-5e70e772e014@hygon.cn>\n \n \n \n \n \n <9e20997c-d94e-4115-b0bc-72c5c0744542@126.com>\n ","MIME-Version":"1.0","In-Reply-To":"\n ","X-Scanned-By":"MIMEDefang 3.0 on 10.30.177.17","X-Mimecast-Spam-Score":"0","X-Mimecast-MFC-PROC-ID":"z-yXpOsNTElAGetwlVuzflv9B3cFWQNbRGcbu7QUVEI_1777588119","X-Mimecast-Originator":"redhat.com","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Reply-To":"Jakub Jelinek ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3684990,"web_url":"http://patchwork.ozlabs.org/comment/3684990/","msgid":"<87cxzgf0zp.fsf@gentoo.org>","list_archive_url":null,"date":"2026-05-01T00:05:14","subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","submitter":{"id":83216,"url":"http://patchwork.ozlabs.org/api/people/83216/","name":"Sam James","email":"sam@gentoo.org"},"content":"Kewen Lin writes:\n\n> 在 2026/4/30 14:37, Richard Biener 写道:\n>> On Thu, Apr 30, 2026 at 4:10 AM Kewen Lin wrote:\n>>>\n>>> Hi Rainer & H.J.,\n>>>\n>>> 在 2026/4/30 6:31, H.J. Lu 写道:\n>>>> On Thu, Apr 30, 2026 at 5:24 AM Rainer Orth wrote:\n>>>>>\n>>>>> Hi Uros,\n>>>>>\n>>>>>>> There are some changes in v2 comparing to v1:\n>>>>>>> - In function host_detect_local_cpu: relaxed CPU model check\n>>>>>>> from model == 7 to model >= 7 to make any potential future\n>>>>>>> model adopt M7 at least.\n>>>>>>> - Replaced multiple uses of cond with if_then_else where only\n>>>>>>> a single condition is involved as suggested.\n>>>>>>> - Removed redundant checks as alternative constraints ensure\n>>>>>>> as suggested.\n>>>>>>> - Fixed a few alignment formatting issues on c86_attr lines in mds.\n>>>>>>> - Removed some unnecessary empty lines.\n>>>>>>>\n>>>>>>> Bootstrapped and regtested as before.\n>>>>>>>\n>>>>>>> Is it ok for trunk?\n>>>>>>\n>>>>>> OK.\n>>>>>\n>>>>> between yesterday and today, I saw an increase in bootstrap times\n>>>>> between 37 and 75%:\n>>>>>\n>>>>> * i686-pc-linux-gnu, -j128 1:03:03 -> 1:50:00\n>>>>>\n>>>>> * i386-pc-solaris2.11, -j28 3:08:11.19 -> 4:18:22.77\n>>>>>\n>>>>> while the x86_64-pc-linux-gnu times are virtually unchanged. It seems\n>>>>> likely that this patch is the culprit. Is anyone else seeing the same?\n>>>>>\n>>>>\n>>>> Yes, I have seen a similar compile time increase on Linux/i686.\n>>>\n>>> Thanks for the information, we didn't test for i686 before, are trying to\n>>> reproduce this locally first. Did you happen to notice which part inceased\n>>> much or any suspicious point like automation gen etc.?\n>> \n>> genautomata now takes ages for me.\n>\n> Sorry for that. In some previous local revision, we noticed that some modeling\n> on long latency instructions which can execute on more than one units, like:\n>\n> (define_insn_reservation \"c86_4g_m7_avx512_sse_sqrt\" 16\n> (and (eq_attr \"cpu\" \"c86_4g_m7\")\n> (and (eq_attr \"type\" \"sse\")\n> (and (eq_attr \"c86_attr\" \"sqrt\")\n> (eq_attr \"memory\" \"none\"))))\n> \"c86-4g-m7-direct,c86-4g-m7-fpu1*7|c86-4g-m7-fpu3*7\")\n>\n> can cause compilation time to increase much on x86-64 build with big N, so we\n> tried to reduce the number by sacrificing exact modeling. It looks that this issue\n> is still obvious on 32-bit environment.\n>\n> I think (automata_option \"no-comb-vect\") is a quick workaround here, I wonder\n> if it can be a fix though there isn't any port adopting it now.\n\nKewen, would it be possible to revert the change for now? Such a\nsignificant increase in build time (observed by some on x86_64 too) will\nimpact regular testing.\n\n>\n> BR,\n> Kewen\n\nthanks,\nsam","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=38.145.34.32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=gentoo.org","sourceware.org; spf=pass smtp.mailfrom=gentoo.org","server2.sourceware.org;\n arc=none smtp.remote-ip=140.211.166.183"],"Received":["from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g6BCR2PmCz1yGq\n\tfor ; Fri, 01 May 2026 10:05:49 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id C5ED6436F3F6\n\tfor ; Fri, 1 May 2026 00:05:47 +0000 (GMT)","from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183])\n by sourceware.org (Postfix) with ESMTP id 7A2414374229\n for ; Fri, 1 May 2026 00:05:20 +0000 (GMT)","from mop.sam.mop\n (1.5.5.2.4.d.e.f.f.f.5.f.9.d.6.0.a.5.c.d.c.d.9.1.0.b.8.0.1.0.0.2.ip6.arpa\n [IPv6:2001:8b0:19dc:dc5a:6d9:f5ff:fed4:2551])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest\n SHA256)\n (No client certificate requested) (Authenticated sender: sam)\n by smtp.gentoo.org (Postfix) with ESMTPSA id B676A3415E4;\n Fri, 01 May 2026 00:05:17 +0000 (UTC)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org C5ED6436F3F6","OpenDKIM Filter v2.11.0 sourceware.org 7A2414374229"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 7A2414374229","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 7A2414374229","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777593920; cv=none;\n b=Z8VYggfDoVUzZ8aLaGqtsboBDHBxbE2f+2PaZafpqpWsoiDZcqp6ryb6pwK7xM6c2EfvHaH77mWDVAZthnDqt7pXce0ZELw+QtC/WVGSqPD+j1d9/Oy2+JGxzP38/1lCyYNKKzttDAlYob7y0rEDIEezwyEfxUDsrGcoyYuXe3o=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777593920; c=relaxed/simple;\n bh=z+8zcp7zlhBTQ29RUXXxWBrgg8qDhulh9eoyHKzdqCo=;\n h=From:To:Subject:Date:Message-ID:MIME-Version;\n b=qgysaAWhTyXwaovHmCZ0KItfWel7b/RPnJWpIyHiHfY9GeGPoJrc35yK/lyKZ6lvYR4qPP9WZdM2tT9wr5PmMj0LK9OEOtg0kyAVxtGT+wRwsMWNg0kahwEc094r/tH9xFkbFV+rL4pXoKTS/gG1xn/0397TU/P4zgcC52JZU0A=","ARC-Authentication-Results":"i=1; server2.sourceware.org","From":"Sam James ","To":"Kewen Lin ","Cc":"Richard Biener , Uros Bizjak\n , \"H.J. Lu\" , Rainer Orth\n , Kewen Lin ,\n \"gcc-patches@gcc.gnu.org\" , Liulxx\n , Qingkuan Lai , Feng Xue\n , \"hubicka@ucw.cz\" ,\n \"hongtao.liu@intel.com\" ","Subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","In-Reply-To":"","Organization":"Gentoo","References":"<387794d9-199a-4373-97be-5e70e772e014@hygon.cn>\n \n \n \n \n \n <9e20997c-d94e-4115-b0bc-72c5c0744542@126.com>\n \n ","User-Agent":"mu4e 1.14.1; emacs 31.0.50","Date":"Fri, 01 May 2026 01:05:14 +0100","Message-ID":"<87cxzgf0zp.fsf@gentoo.org>","MIME-Version":"1.0","Content-Type":"multipart/signed; boundary=\"=-=-=\";\n micalg=pgp-sha512; protocol=\"application/pgp-signature\"","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3685040,"web_url":"http://patchwork.ozlabs.org/comment/3685040/","msgid":"","list_archive_url":null,"date":"2026-05-01T07:27:50","subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","submitter":{"id":808,"url":"http://patchwork.ozlabs.org/api/people/808/","name":"Uros Bizjak","email":"ubizjak@gmail.com"},"content":"On Fri, May 1, 2026 at 2:05 AM Sam James wrote:\n>\n> Kewen Lin writes:\n>\n> > 在 2026/4/30 14:37, Richard Biener 写道:\n> >> On Thu, Apr 30, 2026 at 4:10 AM Kewen Lin wrote:\n> >>>\n> >>> Hi Rainer & H.J.,\n> >>>\n> >>> 在 2026/4/30 6:31, H.J. Lu 写道:\n> >>>> On Thu, Apr 30, 2026 at 5:24 AM Rainer Orth wrote:\n> >>>>>\n> >>>>> Hi Uros,\n> >>>>>\n> >>>>>>> There are some changes in v2 comparing to v1:\n> >>>>>>> - In function host_detect_local_cpu: relaxed CPU model check\n> >>>>>>> from model == 7 to model >= 7 to make any potential future\n> >>>>>>> model adopt M7 at least.\n> >>>>>>> - Replaced multiple uses of cond with if_then_else where only\n> >>>>>>> a single condition is involved as suggested.\n> >>>>>>> - Removed redundant checks as alternative constraints ensure\n> >>>>>>> as suggested.\n> >>>>>>> - Fixed a few alignment formatting issues on c86_attr lines in mds.\n> >>>>>>> - Removed some unnecessary empty lines.\n> >>>>>>>\n> >>>>>>> Bootstrapped and regtested as before.\n> >>>>>>>\n> >>>>>>> Is it ok for trunk?\n> >>>>>>\n> >>>>>> OK.\n> >>>>>\n> >>>>> between yesterday and today, I saw an increase in bootstrap times\n> >>>>> between 37 and 75%:\n> >>>>>\n> >>>>> * i686-pc-linux-gnu, -j128 1:03:03 -> 1:50:00\n> >>>>>\n> >>>>> * i386-pc-solaris2.11, -j28 3:08:11.19 -> 4:18:22.77\n> >>>>>\n> >>>>> while the x86_64-pc-linux-gnu times are virtually unchanged. It seems\n> >>>>> likely that this patch is the culprit. Is anyone else seeing the same?\n> >>>>>\n> >>>>\n> >>>> Yes, I have seen a similar compile time increase on Linux/i686.\n> >>>\n> >>> Thanks for the information, we didn't test for i686 before, are trying to\n> >>> reproduce this locally first. Did you happen to notice which part inceased\n> >>> much or any suspicious point like automation gen etc.?\n> >>\n> >> genautomata now takes ages for me.\n> >\n> > Sorry for that. In some previous local revision, we noticed that some modeling\n> > on long latency instructions which can execute on more than one units, like:\n> >\n> > (define_insn_reservation \"c86_4g_m7_avx512_sse_sqrt\" 16\n> > (and (eq_attr \"cpu\" \"c86_4g_m7\")\n> > (and (eq_attr \"type\" \"sse\")\n> > (and (eq_attr \"c86_attr\" \"sqrt\")\n> > (eq_attr \"memory\" \"none\"))))\n> > \"c86-4g-m7-direct,c86-4g-m7-fpu1*7|c86-4g-m7-fpu3*7\")\n> >\n> > can cause compilation time to increase much on x86-64 build with big N, so we\n> > tried to reduce the number by sacrificing exact modeling. It looks that this issue\n> > is still obvious on 32-bit environment.\n> >\n> > I think (automata_option \"no-comb-vect\") is a quick workaround here, I wonder\n> > if it can be a fix though there isn't any port adopting it now.\n>\n> Kewen, would it be possible to revert the change for now? Such a\n> significant increase in build time (observed by some on x86_64 too) will\n> impact regular testing.\n\nIf necessary, please disable/revert only parts that are causing\ntroubles, so we won't have to revert and then reapply the relatively\nlarge patch in whole.\n\nUros.","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=Qh5vWSTK;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=38.145.34.32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (2048-bit key,\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=Qh5vWSTK","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com","sourceware.org; spf=pass smtp.mailfrom=gmail.com","server2.sourceware.org;\n arc=pass smtp.remote-ip=209.85.208.180"],"Received":["from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g6N1s69rGz1y04\n\tfor ; Fri, 01 May 2026 17:28:32 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 638DE4BA798E\n\tfor ; Fri, 1 May 2026 07:28:30 +0000 (GMT)","from mail-lj1-f180.google.com (mail-lj1-f180.google.com\n [209.85.208.180])\n by sourceware.org (Postfix) with ESMTPS id 680824BA798E\n for ; Fri, 1 May 2026 07:28:02 +0000 (GMT)","by mail-lj1-f180.google.com with SMTP id\n 38308e7fff4ca-38def541b0bso14423311fa.1\n for ; Fri, 01 May 2026 00:28:02 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 638DE4BA798E","OpenDKIM Filter v2.11.0 sourceware.org 680824BA798E"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 680824BA798E","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 680824BA798E","ARC-Seal":["i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1777620482; cv=pass;\n b=YjHFoCEMX82Ru24v1hVkyOuI3GEUwoWfCx1BDASuJxzp6MwUoDQmOyhCNUy7s8Ux/2wJImqNAN3Ow4umVx1hNYDo3QYWq9IYX5E9XsgaLq/HwcFj42VXCsjlUNQj+I/l24CUjA82ZdOWz6jPfx4WAbsDNnQUt0Tc+og+2ersuCo=","i=1; a=rsa-sha256; t=1777620481; cv=none;\n d=google.com; s=arc-20240605;\n b=ZJOL2IoHOkc22D1rpRPWErzI5IomoOKs6mgvNhHbTJL7KxDRaN/UJnSfQVhjMWAecw\n 63XaZsgA4o8M5jT1WgRHxbVrdn0bEKMNrnGX+l4nLGwcrgSQG9axsWcW3WZPuO3AJOaC\n yGlNhZQT5epkNc9rO4oDdfr5yW3rwdwFpo30/7Ik5/KI2wDLNjF6e/7y6t2fJxBzq8/8\n NZ28PdReGFqBT72Qvnq/cpk2qLMcuQbP8qoZ3sl8y1Fum2bGKsVx9/rA1+twcoUE+bsq\n cDhjaDKvNDKDhJw6W3ojTfv+7xXDI6GvYc919pGXWV0GfMwUi1Di88ve5FSHKwd3hfuW\n ZX8w=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777620482; c=relaxed/simple;\n bh=gJeCgyVXoIMlND9cq8AjxFyEiwgarPx+TyrMpSR3TR0=;\n h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;\n b=tvSfaZw20i77CtrsUrkvR262D+KUTsDfeYkDBYxv5XIa6Ftf7PIELzso4QUzx/4Z6Z0QKGyZqaqtqYsRjLpwGaIa5bsTJDiOXpLlZVeCE2WUk1K3NQRMVdrRuW6vuy4qDfJ++jKfvvIB/gkfsc6aWkRSfNgkllIay4BczX4NZmI=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=y7Y/URoNKbsHLz2YkK1fHbS6cOJ7XXOsNYQ5Pt3kaYw=;\n fh=w9dkMsG2FWGatqy65FxqYQuOSKw77w1/quxFl6YNwoU=;\n b=be1xJD0K0aDWFdSijLbebeC+ZoFPUq6R14vyg2B020XkaSPIfI0Htr08UKcJcXunQL\n 2awawumuPIiuRJrsQNVQ9FKpM6FVcqAxFaD0YQV/upERDbejZR2TgOHLd+2Iqvi5Hy9c\n +1AVAufqyXoLeq+KmZmcJQlp7LmQX4/coEdIi8w8KE7pH9X53PHUhi1/FRkLPcgWrNY0\n 6JU41dzQSSayPGVLOn+p3xpC5DajXcF+cm94gB9SSGwlm1gVd6cYy2tnVUrrCGSAfopj\n AENQYbFyUCmCfPtzLLP4Ec0LrryrBfIbHyYQxg7jFh6DwUPrVeDUIZQBsQaPcmoRvXL1\n 2y2w==; darn=gcc.gnu.org"],"ARC-Authentication-Results":["i=2; server2.sourceware.org","i=1; mx.google.com; arc=none"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1777620481; x=1778225281; darn=gcc.gnu.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=y7Y/URoNKbsHLz2YkK1fHbS6cOJ7XXOsNYQ5Pt3kaYw=;\n b=Qh5vWSTK1D7AIJ95SRHCTT/QDvmYhcLzsBqYAWZ6+EeazoHKlfsqoqiKytlat2tpux\n niLPsJgqSUbkisugps5NSEtYj1FnHIVxyxikW0Sip6dGCMr3Abnh0kulZ1tRZTFJHo6p\n Vv4OmgVaXYdxeI261Hqiq0mhHgAL/dDHXgirbaArpYzOwppp2X3yInWAeWsT9xF75TFu\n FWSHTWhCur7vhVdhGXrxtm7w711XrlIr3FWlBxXwTkELptXCrmhrYIU8k6FmWXvg6V2D\n 5BeirNuIs3pWYciqozGdqLh2LUQd5Z7yZz8axH/kpG2JbbXkKrUeu5fcoFZZHTEeC4Sd\n 4XnQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1777620481; x=1778225281;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=y7Y/URoNKbsHLz2YkK1fHbS6cOJ7XXOsNYQ5Pt3kaYw=;\n b=RHJJ4BT23Qs8DdbDktwkPxuCAeQ97vhfHr21iiy34E5+Bte0DjDyUFbBTkZHtJUN86\n rfMp9BQ6puf3QVacNtPbbBvgjykOXRNutcKDzXvpSlqaeYTHxWh/7CAXVSNw7vi726hs\n 4pqj0RX/+TnUunhJwxYBPJuo/K+2u7Tqc4qOWS5IWPy3E06bUXixeyvsj/A51qSV4L6W\n MojEwq1CopJ54DBow+g8Z4b6mVVTvG3ySupb/KFH+Nn8KpcnTeM96Ncjr9UqvtTeG1Dg\n A/2ZLISJ5OOYYxeYnvKtivp1z34cYKj42VDWabYS9U8pE1JpeX0ASimzJ7Cimfw4+r86\n 5foQ==","X-Forwarded-Encrypted":"i=1;\n AFNElJ+IjjZwlRAzQkeTxMnliXeWQtwI8WKp+BPsvUd3qEjjHQ6l391Zoz8sANTeZ/mwk4wJoGt2S03iHk5G6Q==@gcc.gnu.org","X-Gm-Message-State":"AOJu0YwEOSrz992FnfEowLtlRMOnqBpABOyw+TXQanbllQgLkl48ZPZe\n T5jXxPMLBcVQbiyEoTyAfsL5vjuC4qmOgGKDqTTAQwCLujNXuhCby3G8kqzUwmmbhcr+UCxceIj\n fWuFLIpl8oVVp9ugWvoR0ndfR79DiZLM=","X-Gm-Gg":"AeBDietMbgHbGWWYYFRnJSvgDtVGm+0squKa5wP5VBBf3HuY+/2cYVFvI2l+S47UNq7\n p7uz4ZJxARPGsMU8plk7ofrRTRtv9QMWK4vK6mUk1GCarZHaK+02N1tpqGkE4alZ+4p65H0P1dL\n AOtt+QeLIfD81/NGXfj6ljYJv2v2GSjhfaKnDxHN99I/4bppS/Zdb3jLGC13FzA49GXSIij0hkF\n 9zsP2nuazAy1hh03p+UYN6qNNZlPR4uZ89qzVgczGRtfofqfBEAANVGgqvrqVxeQu0IEUX4hwIm\n 84f2w4Z22JUggSOklhEnUKv7SODNDrSIRzj8+pzI5Oyk5Tmo0vcGlH2nR0ib3kTiGqdukuyF0aR\n Yq2ByawGjaOeu65QINThOVXp6Wt1AOwXECGrMFsHDgfUp4OW49koCCA==","X-Received":"by 2002:a05:651c:150d:b0:38e:8503:6fb5 with SMTP id\n 38308e7fff4ca-3934e2ab6f8mr27604441fa.30.1777620480806; Fri, 01 May 2026\n 00:28:00 -0700 (PDT)","MIME-Version":"1.0","References":"<387794d9-199a-4373-97be-5e70e772e014@hygon.cn>\n \n \n \n \n \n <9e20997c-d94e-4115-b0bc-72c5c0744542@126.com>\n \n <87cxzgf0zp.fsf@gentoo.org>","In-Reply-To":"<87cxzgf0zp.fsf@gentoo.org>","From":"Uros Bizjak ","Date":"Fri, 1 May 2026 09:27:50 +0200","X-Gm-Features":"AVHnY4LIUmGyAzw3QAixJFHQlh7--6NVHYZ_9c--QVC2VTDjTRgrxFdJ5JD9Y5M","Message-ID":"\n ","Subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","To":"Sam James ","Cc":"Kewen Lin ,\n Richard Biener ,\n \"H.J. Lu\" , Rainer Orth ,\n Kewen Lin ,\n \"gcc-patches@gcc.gnu.org\" ,\n Liulxx ,\n Qingkuan Lai , Feng Xue ,\n \"hubicka@ucw.cz\" ,\n \"hongtao.liu@intel.com\" ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3685078,"web_url":"http://patchwork.ozlabs.org/comment/3685078/","msgid":"<24288932-60b4-d191-58af-e8626870b6a1@ispras.ru>","list_archive_url":null,"date":"2026-05-01T09:45:11","subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","submitter":{"id":5136,"url":"http://patchwork.ozlabs.org/api/people/5136/","name":"Alexander Monakov","email":"amonakov@ispras.ru"},"content":"On Fri, 1 May 2026, Kewen Lin wrote:\n\n> > I strongly suspect a part of it is improper divider unit modeling that was fixed\n> > for other pipeline models in context of bug 87832. In particular, I see\n> > \n> > +;; IDIV\n> > +(define_insn_reservation \"c86_4g_m7_idiv_DI\" 41\n> > +\t\t\t (and (eq_attr \"cpu\" \"c86_4g_m7\")\n> > +\t\t\t (and (eq_attr \"type\" \"idiv\")\n> > +\t\t\t\t (and (eq_attr \"mode\" \"DI\")\n> > +\t\t\t\t\t(eq_attr \"memory\" \"none\"))))\n> > +\t\t\t \"c86-4g-m7-double,c86-4g-m7-ieu3*41\")\n> > \n> > and ieu3 appears to be an ALU used for other instructions, not the divider. This\n> > likely blows up the automaton, and doesn't properly model the pipeline anyway.\n> > \n> > Kewen, please have a look at the patches linked from PR 87832, they all have\n> > commit messages, and the strategy is not complicated (create a separate cpu_unit\n> > for the partially-pipelined divider, use it in reservations, use throughput, not\n> > latency figures ('*41' above is wrong): https://gcc.gnu.org/pr87832\n> \n> I went through the commits and made a draft patch as the bottom by\n> following commit r13-4956-gec1db9017939bb for not pipelined division.\n> It did make the compilation time issue gone, and it turned out the\n> division etc. modeling caused a combinatorial explosion in the automaton\n> as you suspected, see the details below:\n> \n[snip]\n> \n> I have a question on this solution with \"fpu*N -> fpu,divider*N\",\n> IIUC, the former means the insn occupies fpu for N cycles while\n> the later means it occupies fpu for 1 cycle and then divider for\n> N cycles. From what I got from our hardware team colleages\n> months ago, I think the former matches our hardware behavior\n> better, we want scheduling to consider fpu unavailable for N cycles.\n> From this perspective, does it mean this kind of adjustment is actually\n> a trade-off between exact modeling and automaton explosion?\n\nAh, that is unexpected to me. My understanding is that Hygon microarchitecture\nis derived from first-generation AMD Zen, and Andreas Abel measured\nfloating-point division latency/throughput as 10c/3c for DIVSS instruction,\nindicating that it is partially pipelined:\nhttps://uops.info/html-instr/DIVSS_XMM_XMM.html#ZEN+\n\n(I misunderstood his measurements for the integer division though, it is not\npipelined on Zen, invalidating my claim above regarding '*41' being wrong;\nbut, at least on Zen2, it doesn't occupy a generic ALU for all N cycles)\n\nHis measurements also show that AMD PMU accounts only one uop for the FP3 pipe\nper one DIVSS, indicating that FP3 may be available for other instructions. I do\nnot have access to a first-generation Zen, but I can confirm that on Zen2 by\nrunning the following experiment:\n\n.intel_syntax noprefix\n.globl _start\n_start:\n\tmov ecx, 1000000\n\tvmovss xmm1, one\n.p2align 5\n.loop:\n\tvdivss xmm2, xmm1, xmm1\n\tvdivss xmm2, xmm1, xmm1\n\t.rept 25\n\tvorps xmm2, xmm1, xmm1\n\t.endr\n\n\tdec ecx\n\tjnz .loop\n\tud2\none:\n\t.long 0x3f800000\n\nThis loop runs at 7 cycles per iteration, so on four cycles the pipe that\nruns DIVSS also accepts ORPS. Similarly, if I change ORPS to CVTSS2SD, which\nonly runs on FP3, I see that with '.rept 4' the loop still runs at 7 cycles\nper iteration.\n\n(on Zen1 the two divisions would take 6 cycles, not 7, and .rept count\nwould have to be adjusted)\n\nA similar experiment with loop latency-bound on divisions:\n\n.intel_syntax noprefix\n.globl _start\n_start:\n\tmov ecx, 1000000\n\tvmovss xmm1, one\n\tvxorps xmm0, xmm0, xmm0\n.p2align 5\n.loop:\n\tvdivss xmm1, xmm1, xmm1\n\tvdivss xmm1, xmm1, xmm1\n\t.rept 74\n\tvorps xmm2, xmm0, xmm0\n\t.endr\n\n\tdec ecx\n\tjnz .loop\n\tud2\none:\n\t.long 0x3f800000\n\nruns at 20 cycles per iteration on Zen2, and there are 14 cycles when FP3\nhandles ORPS while DIVSS is in progress.\n\nIf this is not the case on Hygon and floating-point division actually makes \nan FP pipe completely unavailable for other instructions, then yes, the\nadjustment done by the patch would not describe the hardware accurately.\n\nAlexander","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=ispras.ru header.i=@ispras.ru header.a=rsa-sha256\n header.s=default header.b=gsEjbxd9;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=ispras.ru header.i=@ispras.ru header.a=rsa-sha256\n header.s=default header.b=gsEjbxd9","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=ispras.ru","sourceware.org; spf=pass smtp.mailfrom=ispras.ru","server2.sourceware.org;\n arc=none smtp.remote-ip=83.149.199.84"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g6R4C28zrz1xqf\n\tfor ; Fri, 01 May 2026 19:45:45 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id A58E94371D4C\n\tfor ; Fri, 1 May 2026 09:45:43 +0000 (GMT)","from mail.ispras.ru (mail.ispras.ru [83.149.199.84])\n by sourceware.org (Postfix) with ESMTPS id 5F4A34A968FE\n for ; Fri, 1 May 2026 09:45:14 +0000 (GMT)","from monopod.intra.ispras.ru (unknown [10.10.3.121])\n by mail.ispras.ru (Postfix) with ESMTPSA id 84C7745F7991;\n Fri, 1 May 2026 09:45:11 +0000 (UTC)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org A58E94371D4C","OpenDKIM Filter v2.11.0 sourceware.org 5F4A34A968FE","OpenDKIM Filter v2.11.0 mail.ispras.ru 84C7745F7991"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 5F4A34A968FE","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 5F4A34A968FE","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777628714; cv=none;\n b=sx4cdYsnPsitP41fkAWzlBJwIMYCr9RCGCL0M4SKIzioicHN404Qb0UFsHxB4puQ5EdhkwZreOnmNsGdfSOhTdS7O4cgHJ13HRHGrCR6al8J4keHSLB0E5Rnu89VxBhxG7sxRmscXskoLJctHKgncI3DX3EOH82xaldhOPcxlLo=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777628714; c=relaxed/simple;\n bh=bIITZYxE8joUV3D0x5o+vsnLDQNVbOsz5RTORVLQvho=;\n h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version;\n b=NO2dQ+QLUluCpEXyErXIIhfZCW/08gHWtwqajyd92+w/I1bNc+hrPswd+FJ0b9ThIoZzYekvJFBswYit3uoqF1xwUFZrUSP9STWm+6fjWEofkdKa+MEiI0hUharvcklOINWDsmjao1iAhORQhU0aKNyKn6ZyVsrnjBq0R2VR6rQ=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=ispras.ru;\n s=default; t=1777628711;\n bh=OzEZONbhWPc8pCZVGDz2dgqF7dgC+lcVXnNftETDvgY=;\n h=Date:From:To:cc:Subject:In-Reply-To:References:From;\n b=gsEjbxd9krW/3Dy/ZwRizwP6sdxjs/zKz2FEeaxUgbYSnyGBeCReL7fzQROL7Ddcl\n mXr8jhwfAa2hrG59ZSXuxY1c/L5OKFPIIXs16F0RBWr74X54y3KLO3EOQKcTs5l0KI\n XRikMkIyJRyEj1q22GZZPe9Wl9xdQYmzK6rRs3MQ=","Date":"Fri, 1 May 2026 12:45:11 +0300 (MSK)","From":"Alexander Monakov ","To":"Kewen Lin ","cc":"\"H.J. Lu\" ,\n Rainer Orth ,\n Uros Bizjak , Kewen Lin ,\n \"gcc-patches@gcc.gnu.org\" ,\n Liulxx , Qingkuan Lai ,\n Feng Xue , \"hubicka@ucw.cz\" ,\n \"hongtao.liu@intel.com\" ,\n Richard Biener ","Subject":"Re: [PATCH v2] i386: Support HYGON c86-4g series processors","In-Reply-To":"<69dfc47c-c14d-4c66-9fc7-4c28d2a4528b@126.com>","Message-ID":"<24288932-60b4-d191-58af-e8626870b6a1@ispras.ru>","References":"<387794d9-199a-4373-97be-5e70e772e014@hygon.cn>\n \n \n \n \n \n <9e20997c-d94e-4115-b0bc-72c5c0744542@126.com>\n \n <243544d5-afa2-effa-d336-c4c78f52d1a6@ispras.ru>\n <69dfc47c-c14d-4c66-9fc7-4c28d2a4528b@126.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}}]