From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DE8CC30101F for ; Wed, 14 Jan 2026 17:34:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768412084; cv=none; b=oZMpr7jUe6yg44IXOK6rUs5mwFofgMF5E5RArjnby4sjlHGuz329C8XSS1nuPd0h0icI6LCjnOO3bvGzYtp/96piRSY4/fnaCczvviuucsPqdj7+GhsQjOPyFLzExOdBqr8YraUz6E4eRjCn3c1qFZCA2XTKeF30KH4yZG7dBis= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768412084; c=relaxed/simple; bh=kObkP2DRo5mXrlxriPjEDWheb0/mwzFmw+8s1z659rQ=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=VSDvsWrIf9QbXAgO27U/0iJz5OaqKHZR2RCifVtxUWkfo+9UchfCLBevOppx2jorKQL0XWDCdNTCBK9VG4S2Ll32BWpgoG6Nx77MudkS42ngsd2MY+3Gd+bRxFXicxt5eUnDv0F2z90TX5favlXjDJavtlMk9CaL1h5Za9Spwhg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=l7rOqzn0; arc=none smtp.client-ip=209.85.128.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="l7rOqzn0" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-47ee974e230so846195e9.2 for ; Wed, 14 Jan 2026 09:34:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768412077; x=1769016877; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=WJ7m2Kae0rt7KDMZbiJnTHcyU/qgip1RiScuagqlCWo=; b=l7rOqzn0s98s9MB2RKh1QOdNVoZwqowXwuRhj0ttHsgh4OEWHGT5D1yGEOYlSCiad4 KCc8ZRuL+JqV2kSNEA/qMbGeDDTFJ7Q4JvEW8PTku+NMctiIJsaCc17ttuITW48fFCb3 1gJKIvap4KfNBzzvVMFKpL07rKWcfqKWDCMOz02/BB7VngETXA8V0TWDazKEPjjoKuPB uHRyrE18wk0IsQolpbZGjM5Di0rqB4qsxU+F8fkcd/C5vBdwLMAkoDNihGhcUqy+KTqc 1M+rqr6C65BOyA4B10Gkm8DryGY0XwTNDAKp9fjvZntpUjEbH8n4+uUM6lSQDj7JI8ce i/Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768412077; x=1769016877; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=WJ7m2Kae0rt7KDMZbiJnTHcyU/qgip1RiScuagqlCWo=; b=i4L1KhRDdViQqy/MM9GCAMWbh5HNf9Pz7xcoonicWSjOzr46U7EO2CRrwwb2KtWv9t +g0oX3rzg8JNQkjaAXFVnVGPYFVSidCNaqadwBhNlEtgWV5mffJZQZ3HkSVdGsu1WLJh d57ZUIo8WhVVdlDyYMEA44Z0QjVzNy8LE3yhXbezCWJG1GPFIqTGa0Azzl9VNre50Pvx IlDYDasIgNhq4a1GUMDJwrGRDL6gmF7VeTBhVhPko0kE4Gs4bkVabwdEWPOQTYkxyd2Y DXSUGepWeSCEZNCz82eHzcbD2k+PN233UHdb1Z4jL+jFgnmJptljBYH+7NmMp7awyTtM UTng== X-Forwarded-Encrypted: i=1; AJvYcCVkebcO8p8S7sxf7vQDjK5aKGIYGv6nC1zt7z3Lr3imOtzNrn5HGF1jdO531W6U0/FpdcBBPNxDoh97VEg=@vger.kernel.org X-Gm-Message-State: AOJu0YyU0YfHVgsFz3Z86M+bMajaNwzUbQUTzdTEeJNHHJ7FFxKC4xks 2zh3W7YedY6c3hFuiK3iLkiqNMz/P5SVUxvTXEIpRmNE2+gP0XY5/8UW X-Gm-Gg: AY/fxX5T6m1gFAr1J1rswkGPY3WoLfYZ5xwOF0vPLhlNIt9n99NBqoPDGgLdbWjcLOa wpgWR4l+HgwCiVGebuUVmyt3Oqwkh/0HXtdE5RZ+4EMEkZj3fpAS1n+YVu8FFCU8brg6v18vFrR 8REuE66HTqJSqXiOPXdoiOgHWtrBlkrRTkROm6hm8bsQDzzFHmkTD+xt9PJTnIWMxa5IR7+irH1 g0R9PlLJYlxabmz1RQfM4Oq5ofFRBECmYuqQ8AfLKhZeQq9hlRP5+E/POBywkhfH3f2Cob9GbiX 30BrzdXZ9c4HKYcCTRGVu/nk31QRwFwb++p9n53h+l81T+SR/KYeaJIODACYmoedA4HaYXH3tyb zHgAusSt+DlbDjc082f1XEmZYQ5FiSJOi4x1wVT/i3/gohwle2RnjruIKVpFKk1mkAhblsE/ydW 9Dr5Y8px6Lc3gFKZsAUIzGK4/C1ZrLyJ3KmVmIyw2Z3rT1qb+2gD4D X-Received: by 2002:a05:600c:a46:b0:477:73e9:dc17 with SMTP id 5b1f17b1804b1-47ee338c00cmr46093135e9.35.1768412076765; Wed, 14 Jan 2026 09:34:36 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47ee2725b54sm27307345e9.1.2026.01.14.09.34.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Jan 2026 09:34:36 -0800 (PST) Date: Wed, 14 Jan 2026 17:34:35 +0000 From: David Laight To: "Maciej W. Rozycki" Cc: kernel test robot , oe-kbuild-all@lists.linux.dev, linux-kernel@vger.kernel.org, Andrew Morton , Linux Memory Management List , Nicolas Pitre , linux-mips@vger.kernel.org, Thomas Bogendoerfer Subject: Re: mips64-linux-ld: div64.c:undefined reference to `__multi3' Message-ID: <20260114173435.51cf556d@pumpkin> In-Reply-To: References: <202601140146.hMLODc6v-lkp@intel.com> <20260113200455.3dffe121@pumpkin> <20260114103103.216aa122@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 14 Jan 2026 15:50:09 +0000 (GMT) "Maciej W. Rozycki" wrote: > On Wed, 14 Jan 2026, David Laight wrote: > > > > > Looking at the git log for that file there is a comment that includes: > > > > "we wouldn't expect any calls to __multi3 to be generated from > > > > kernel code". > > > > Not true.... > > > > Not sure why the link didn't fail before though, something subtle must > > > > have changed. > > > > > > > > I think the fix is just to remove the gcc version check. > > > > > > Or rather fix the version check. The GCC fix went in with GCC 10: > > > > Does that mean the GCC 10 generates the multiply instructions and never calls > > __multi3? > > (Rather than just not using __multi3() for that specific example.) > > Of course it still does call `__multi3' for 128x128bit multiplication. > It doesn't for widening 64x64bit one though, which was a missed case for > MIPS64r6 only, having been supported by GCC ever since MIPS III ISA. I > think we do want to fail link in the 128x128bit case. That's fine by me. I only get blamed for the widening one :-) ... > Distinct RTL insns are produced, so all the usual RTL optimisations > apply (in addition to any tree optimisations already made): > > mul_u64_u64_add_u64: > .frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0 > .mask 0x00000000,0 > .fmask 0x00000000,0 > .set noreorder > .set nomacro > dmul $2,$5,$6 # 9 [c=20 l=4] muldi3_mul3_nohilo > dmuhu $5,$5,$6 # 10 [c=44 l=4] umuldi3_highpart_r6 > daddu $7,$2,$7 # 14 [c=4 l=4] *adddi3/1 > sltu $2,$7,$2 # 16 [c=4 l=4] *sltu_didi > sd $7,0($4) # 21 [c=4 l=4] *movdi_64bit/4 > jr $31 # 44 [c=0 l=4] *simple_return > daddu $2,$2,$5 # 29 [c=4 l=4] *adddi3/1 > > (hmm, I wonder why the cost for the high-part RTX is over twice that for > the low-part one; this seems outright wrong, also taking the possibility > of fusing into account). They might be different, if the wide multiply is implemented with multiple narrow ones then the high result bits don't need to be generated if only the low result bits are needed. If the data is clocked through a single multiplier that might be significant, but probably not double (I think you need 3/4 of the products). If the results of separate narrow multipliers have to be added together then the carry-ripple of all the adds might make a small difference, but I'd only expect 1 (perhaps 2) clocks for that. If those are gcc's costs I suspect they may not match reality, after all they usually only have to be 'good enough' or 'reasonable'. I nearly got the 32x32 multiply to run in a single clock on my Nios-II re-implementation, but the 64bit ripple carry delayed things too much for the other logic that needed to happen to feed the product back into the ALU. The product itself could be latched - so it wasn't far off. I think I could have fed back the low bits, but that would have been complicated. Detecting 'short' (18bit by 18bit) unsigned multiplies would have been more use - they are common for array indexes. (That was a 'fun' project... Nios-II is, AFICT, basically MIPS 32.) David > > Maciej >