[{"id":3684131,"web_url":"http://patchwork.ozlabs.org/comment/3684131/","msgid":"","list_archive_url":null,"date":"2026-04-29T15:22:41","subject":"Re: [PATCH] RISC-V: -mrvv-max-lmul=m1-dynamic","submitter":{"id":86205,"url":"http://patchwork.ozlabs.org/api/people/86205/","name":"Robin Dapp","email":"rdapp.gcc@gmail.com"},"content":"> This patch adds a new dynamic LMUL mode that rejects LMUL>=2 when the\n> iteration count is unknown. For unknown loops with a known iteration\n> count, it behaves the same as -mrvv-max-lmul=dynamic.\n>\n> When the iteration count is unknown, the -mrvv-max-lmul=dynamic behavior\n> is also changed. Instead of blindly choosing the bigger LMUL as long as\n> no unexpected spills can occur, it calls the default cost comparing\n> function to compare loops based costs. This can prevent some cases\n> where -mrvv-max-lmul=dynamic emits worse code than -mrvv-max-lmul=m8.\n\nI'm unsure about this. It rather feels like a costing problem.\n\nFor an early-break-style search loop where the trip count can be data \ndependent, I'd understand and we're seeing this issue with the xz loop already.\n\npixel_avg IMHO is a different case. Sure, height and width are unknown (BTW \nwith lto we should be able to see them at link time since GCC 16), but the\nloop still has a runtime-known dynamic trip count.\nWe emit a length-controlled loop and at runtime, the length is small, mostly 8 \nor 16 for x264 which can be wasteful for larger vectors.\n\nSo I presume the issue is that your target uarch's LMUL latency is independent \nof VL and you pay the full price despite small VL? But if the runtime VL were \nlarge, wouldn't a larger LMUL be beneficial and your change would unnecessarily \npenalize it?\nTo me that rather sounds like a job for a heuristic and it's very difficult to \nachieve a proper trade-off.\n\nMaybe we could handle this with a tune-model property? Like \n\"vl_dependent_lmul_scaling\"? If this is false and a loop is length controlled \n(we could also have a non length-controlled VLS loop with unknown trip count), \npenalize larger LMULs accordingly.","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=dX4X/8Ha;\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=dX4X/8Ha","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=none smtp.remote-ip=209.85.128.46"],"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 4g5LfW4RbNz1xqf\n\tfor ; Thu, 30 Apr 2026 01:23:14 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 670D04BB5898\n\tfor ; Wed, 29 Apr 2026 15:23:12 +0000 (GMT)","from mail-wm1-f46.google.com (mail-wm1-f46.google.com\n [209.85.128.46])\n by sourceware.org (Postfix) with ESMTPS id 4691D4B99F5D\n for ; Wed, 29 Apr 2026 15:22:45 +0000 (GMT)","by mail-wm1-f46.google.com with SMTP id\n 5b1f17b1804b1-488e1a8ac40so154575805e9.2\n for ; Wed, 29 Apr 2026 08:22:45 -0700 (PDT)","from localhost (ip-085-216-098-084.um25.pools.vodafone-ip.de.\n [85.216.98.84]) by smtp.gmail.com with ESMTPSA id\n 5b1f17b1804b1-48a7c3058f6sm20614915e9.17.2026.04.29.08.22.42\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Wed, 29 Apr 2026 08:22:42 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 670D04BB5898","OpenDKIM Filter v2.11.0 sourceware.org 4691D4B99F5D"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 4691D4B99F5D","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 4691D4B99F5D","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777476165; cv=none;\n b=OiIJDPKp8W361DAm7RglYtT+00/Sa/aS5auOrU4rLw8C6qwqnD7JqAPpUu9jqABdPY6aj5XhQgNS7Cjfjgor7EAQ7WRpdjDV4qCD03x6HrzfSuZRJf6UX0m0bykxcSVHyW8So6Evo41kDQZ+DvyiaJiqvb8rbc6sQsqtHq3+ZKA=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777476165; c=relaxed/simple;\n bh=G/+PvAJVv7WZPwKrXZmau7fQXV18Iuf2v+hBXOj9Jbo=;\n h=DKIM-Signature:Mime-Version:Date:Message-Id:Subject:To:From;\n b=DLOl1ublaXPtuT6l3rDVmyKsv7WKcj2yKptWahuYt+u7QyEPXTODk9o14MNwqRSYxmtXVR9uJZhmpgGbh6do5CNFSpAvzoSalSQtKJNU/sV0cJqbsBaO2AeAKnYALmalcJ3fHi1kINUDz8VR0XYklWIAuINkqRgSccNPNocrRyc=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1777476164; x=1778080964; darn=gcc.gnu.org;\n h=in-reply-to:references:from:to:cc:subject:message-id:date\n :content-transfer-encoding:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=AxNfhNfLIXIWyo/ZxafvvzCjVcPo8XFvLRa2Py4whD0=;\n b=dX4X/8HajM/WOS7Esoy1522Dmj3BpR7Vw/0JZHz+lA6igTUTEqDXBdrPQyU8b1HO/t\n cbdA5IrrPxAdcZctnX67hPiDWrsWjFt0ZgUBmW1iXpU4C1jrwX1OXutF4kT3jmPhPcK0\n ei67mPR3Tbgy1t2XWV7A9PKYt0DmPtPCg637An/gdZpANoPcCXW+t8ASQn63tKQyRSkk\n aPtzYkJGR/SHUsVc8l6RS32OLQK4HIUnuIhH28b0kYYq799PqfHjZL5YqOO4LPepAeEW\n VF3MeF8WWLEXkmdG+S7VJgzTmxfb9zI6OtSxN6J8qo/Js+Gs0CZupAuAUZyRXX7iuBxj\n mw0A==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1777476164; x=1778080964;\n h=in-reply-to:references:from:to:cc:subject:message-id:date\n :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state\n :from:to:cc:subject:date:message-id:reply-to;\n bh=AxNfhNfLIXIWyo/ZxafvvzCjVcPo8XFvLRa2Py4whD0=;\n b=hf7/ZsO9psXnfE9mjTg4VRlR+htbeyApO6cbVLlyKNNmlBjkG6B6SdgnBoUZe+/sdN\n DrlvolvphKUH8pYTxl6s0/eUeWFrrlsnn/be/1NqOFuJEGcHedrN7jFKsUcDtu1RJV+V\n tCEmChIRsh0aEDr+kPGF/b0xxHgFcaEIPww/6DiQYuOFEHFHxKmsSN9CIVtN3A0a+/+z\n 8nkdDYMwNLc7Zb+Knonig6pObGcl5XP78DaZs9dmtFkNiVnlHd0AWQozhXZ057ECaA2Z\n h9Ej7DRhIMWYWNAj1zBGeaOtxNp1EPUvQow6B9VVdoJpUxuUdiDhgWCpg6FIEVpKB5xH\n nBSQ==","X-Forwarded-Encrypted":"i=1;\n AFNElJ8tuFGr4C/i6TpA0tCC3deRnDn502Bu754s+VJRtZjreNz2omgAIYxByDd6Uku1kQ5xaw9VCy6CxHSoPw==@gcc.gnu.org","X-Gm-Message-State":"AOJu0YwglD9+boagHTXSgvL44Bi7CgWiose2ricMyIKGcRFLk0x4kk1o\n TnVlNJ1zp51lnr5733FnS4oFlyrEHWnpRjZYf+tE4pvSS6e4s02a+x6+","X-Gm-Gg":"AeBDievQ1g+8XWT69x47AngnU4gOi0knZn4I/nQe0kuu4Njn5HEqlrVt+VtnXlHwYOf\n Zud7XwGZqKw4UsQ5p9YvRXldXPHrp5hRj0hEWYBa/2uMTXxYi69BOCTqNIxdZ66zcFc8KT3t903\n XZtmdUo9A5M5t7lNh6kPuSeVDZvwqGAFOKrooBdLD4FQ98mpJ9nbJJ0X0H+Q5JGEHgbObiZrTts\n hfUGNmeUkzLdOQeCZAytgqREGcqGf0OyTkZJucAKPyGSlNwI2b4KtlLoke8HQ66j58VPGxc1lDT\n YrfvCWdov7BoOF0sjWX0T7zpC6gSxqUlqqg2i/02VYZVKhrZspyedx+DofqG9h9rvY8zzeZkMFC\n 8JJ6srjc3KrbldgGHERLiaAAMGdcvIQObQ5nH/3NFS7ViVP3gxAUn7a4Iarg9MD5o2VugArkOCC\n NdmfHUQu4O1K7qawWwZzJLQyOlsYRx8E3GJDHV/Y3A132Y0tcX+rAbbSuobTkPxayV6m3X3p1Nx\n 9DuyDo=","X-Received":"by 2002:a05:600c:8b04:b0:48a:53ea:13eb with SMTP id\n 5b1f17b1804b1-48a77ad5a7emr124776505e9.5.1777476163621;\n Wed, 29 Apr 2026 08:22:43 -0700 (PDT)","Mime-Version":"1.0","Content-Transfer-Encoding":"quoted-printable","Content-Type":"text/plain; charset=UTF-8","Date":"Wed, 29 Apr 2026 17:22:41 +0200","Message-Id":"","Subject":"Re: [PATCH] RISC-V: -mrvv-max-lmul=m1-dynamic","Cc":", ","To":"\"Bohan Lei\" , ","From":"\"Robin Dapp\" ","References":"<20260423074916.10577-1-garthlei@linux.alibaba.com>","In-Reply-To":"<20260423074916.10577-1-garthlei@linux.alibaba.com>","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":3684528,"web_url":"http://patchwork.ozlabs.org/comment/3684528/","msgid":"","list_archive_url":null,"date":"2026-04-30T08:25:07","subject":"=?utf-8?q?Re=3A_=5BPATCH=5D_RISC-V=3A_-mrvv-max-lmul=3Dm1-dynamic?=","submitter":{"id":89310,"url":"http://patchwork.ozlabs.org/api/people/89310/","name":"Bohan Lei","email":"garthlei@linux.alibaba.com"},"content":"Hi Robin,\n\n> So I presume the issue is that your target uarch's LMUL latency is independent \n> of VL and you pay the full price despite small VL? But if the runtime VL were \n\nThat is the case.\n\n> large, wouldn't a larger LMUL be beneficial and your change would unnecessarily \n> penalize it?\n\nYes it would, but perhaps not too much for most cases, where the vector\ninstructions take the most of the execution time, if the vector latency is\nlinear to LMUL.\n\n> To me that rather sounds like a job for a heuristic and it's very difficult to \n> achieve a proper trade-off.\n\nIndeed. The `m1-dynamic` mode in the patch is itself a heuristic that assumes\nthat we would rather use a lower LMUL loop when the trip count is unknown. In,\nreality it can act just like `m1` in most dynamic-trip count cases, but allows\nusing `m2` or higher when the benefits are clear.\n\nI originally considered using a different LMUL scaling scheme, such as something\nquadratic, and put that into the tune parameters of uarchs, to penalize larger\nLMULs (a linear cost is clearly not enough). However, this is not due to (at\nleast not only) the property of a uarch, but rather a property of a program. I\ndon't want the cost of vector instructions to be larger than reality (which is\nlinear) as that can prevent beneficial uses of large LMULs for constant-niters\nloops. In addition, the LMUL scaling factor, in this case, will be very hard to\ndecide. This `m1-dynamic` mode only targets dynamic trip count cases, and it is\nclear.\n\n> \n> Maybe we could handle this with a tune-model property? Like \n> \"vl_dependent_lmul_scaling\"? If this is false and a loop is length controlled \n> (we could also have a non length-controlled VLS loop with unknown trip count), \n> penalize larger LMULs accordingly.\n\nI highly appreciate that point. It now seems that only targets with a\nVL-independent LMUL latency can have the problem. That would require a LMUL\npenalty applied differently for VLS and VLA vectorization. The penalty value\ncan be a problem though. Maybe quadratic? I personally think the `m1-dynamic`\nstrategy is clearer, but it can indeed prevent some beneficial optimizations\nwhen, for example, there is only one LMUL=2 instruction. A VLA-only LMUL\nscaling factor for such cases.\n\nAs for the patch, it actually consists of two parts (but in one commit), as it\nalso modifies the `-mrvv-max-lmul=dynamic` semantic to allow it to fall through\nto the default cost comparing function when comparing two VLA loops with an\nunknown NITERS. What do you think of that part?\n\nThanks,\nBohan","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=linux.alibaba.com header.i=@linux.alibaba.com\n header.a=rsa-sha256 header.s=default header.b=YhicSV+b;\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=linux.alibaba.com header.i=@linux.alibaba.com\n header.a=rsa-sha256 header.s=default header.b=YhicSV+b","sourceware.org; dmarc=pass (p=none dis=none)\n header.from=linux.alibaba.com","sourceware.org;\n spf=pass smtp.mailfrom=linux.alibaba.com","server2.sourceware.org;\n arc=none smtp.remote-ip=115.124.30.130"],"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 4g5nLN5JFhz1xqf\n\tfor ; Thu, 30 Apr 2026 18:25:46 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 35BC94310D5A\n\tfor ; Thu, 30 Apr 2026 08:25:44 +0000 (GMT)","from out30-130.freemail.mail.aliyun.com\n (out30-130.freemail.mail.aliyun.com [115.124.30.130])\n by sourceware.org (Postfix) with ESMTPS id A63344BA2E16\n for ; Thu, 30 Apr 2026 08:25:16 +0000 (GMT)","from WS-web\n (garthlei@linux.alibaba.com[W4_0.2.3_v5ForWebDing_21448500_1777537507638_o7001c1271]\n cluster:ay36) at Thu, 30 Apr 2026 16:25:07 +0800"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 35BC94310D5A","OpenDKIM Filter v2.11.0 sourceware.org A63344BA2E16"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org A63344BA2E16","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org A63344BA2E16","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777537517; cv=none;\n b=sdWbIzwZxRkcuB5iEOOsQSB8KZfe7MIIqfmdBGpx71jG30JFjnYPstJFSTJTuI26Odg/ZxAi1hj+DUXzlRUDkzkTrXAqDBsJ3nZ3rWEI5Oq2E/+6lGG2RlUk8lSb5e5mDA1ir1mfbxz5nV/4h6p5zjc2+o/rfFjVQocgqbmrD+Y=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777537517; c=relaxed/simple;\n bh=rHwOx7TlthdFKZscU5UrwrPNl1gbRpeTEmKvxzz0Hxo=;\n h=DKIM-Signature:Date:From:To:Message-ID:Subject:MIME-Version;\n b=veKUwtNv/0vIG98L9cmLzmUXPpQlDuB1dtVYTBulseXVPJ8WzMpxFVwpWFCy9jRBDB7ZYg3uwj3+Ogi0Zus7ck2eTaFOFO4d3CBO7lMi3RiAs4MzOY7YNx5kXdCZPJRNZ5YMhl7NHUyddemZmDgFllncpVggApStGb30+BJy38Q=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=linux.alibaba.com; s=default;\n t=1777537514; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type;\n bh=rHwOx7TlthdFKZscU5UrwrPNl1gbRpeTEmKvxzz0Hxo=;\n b=YhicSV+bIw8bVKisZ3W/C14aANTuusYmg9C7UYOS7JYQjjFvIZTsRhuNPrTLOTp8qaSxMsL/Hh6MixFpRrW0jMpUV1PHjFroRQEb30tcxllbE0KrwsJiMGbTZSmJ0hM/TUkmWhPZIFX/FU1DuqfWWc9bNqKJlFpafFxQAXfKb8o=","X-Alimail-AntiSpam":"AC=PASS; BC=-1|-1; BR=01201311R141e4; CH=green;\n DM=||false|;\n DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=maildocker-contentspam033037026112;\n MF=garthlei@linux.alibaba.com; NM=1; PH=DW; RN=3; SR=0;\n TI=W4_0.2.3_v5ForWebDing_21448500_1777537507638_o7001c1271;","Date":"Thu, 30 Apr 2026 16:25:07 +0800","From":"\"Bohan Lei\" ","To":"\"Robin Dapp\" ,\n \"gcc-patches\" ","Cc":"\"jeffrey.law\" ","Message-ID":"","Subject":"=?utf-8?q?Re=3A_=5BPATCH=5D_RISC-V=3A_-mrvv-max-lmul=3Dm1-dynamic?=","X-Mailer":"[Alimail-Mailagent revision 745868][W4_0.2.3][v5ForWebDing][Safari]","MIME-Version":"1.0","x-aliyun-im-through":"{\"version\":\"v1.0\"}","References":"<20260423074916.10577-1-garthlei@linux.alibaba.com>,\n ","x-aliyun-mail-creator":"\n W4_0.2.3_v5ForWebDing_NjATW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfMTVfNykgQXBwbGVXZWJLaXQvNjA1LjEuMTUgKEtIVE1MLCBsaWtlIEdlY2tvKSBWZXJzaW9uLzE3LjQuMSBTYWZhcmkvNjA1LjEuMTU=XQ","In-Reply-To":"","x-aliyun-mailtrack":"{\"foreign-track\":\"0\"}","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"base64","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":"Bohan Lei ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}}]