From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E08393857711; Fri, 26 May 2023 16:13:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E08393857711 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1685117633; bh=01bdQgPiPSOMf+OZ94ySZmJd4hn+//kbYtryfIeN+iM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=oGMQ7N2DchgQbHHsNiJNmIpRjaPdUiYCf3LMZzsMuLgDb8o/e9t7Nyzn6zpR3gZoU Q1N+XYsLWkl8wqIqGpSoQSYv0726IhBBja5YEmSVQBHoHTo3ndp8a+QZZJHnkY+2xd c2C2lt5Te3IjBfmshWTjt3L5lUojmDJ3hJSjjI84= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/102989] Implement C2x's n2763 (_BitInt) Date: Fri, 26 May 2023 16:13:51 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.isobsolete attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102989 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #55151|0 |1 is obsolete| | --- Comment #50 from Jakub Jelinek --- Created attachment 55169 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D55169&action=3Dedit gcc14-bitint-wip.patch Update, this time with addition of libgcc _BitInt multiplication libcall (b= ut not really wiring it on the compiler side yet, that would be part of the new _BitInt lowering pass). The function currently is void __mulbitint3 (__bitint_limb *ret, int retprec, const __bitint_limb *u,= int uprec, const __bitint_limb *v, int vprec); which allows mixing different precisions (at compile time, or at runtime us= ing the bitint_reduce_prec function); while in GIMPLE before _BitInt lowering p= ass MULT_EXPR will obviously have same precision for result and both operands, the loweri= ng pass could spot zero or sign extensions from narrower _BitInts for the operands, or VRP could figure out smaller ranges of values for the operands. Negative uprec or vprec would mean the operand is sign extended from precis= ion -[uv]prec, positive it is zero extended from [uv]prec. u/v could be the same or overlapping, but as the function writes result bef= ore consuming all inputs, doesn't allow aliasing between operands and return va= lue. Also, at least in the x86-64 psABI, _BitInt(N) for N < 64 is special and it isn't expected this function would be really used for multiplication of su= ch _BitInts, but of course if say multiplicating say _BitInt(512) by _Bitint(2= 4), it is expected the lowering pass would push those 24 bits into a 64-bit 64-= bit aligned limb and pass 24 for that operand. For inputs it assumes bits above precision but still within a limb are uninitialized (and so zero or sign extends when reading it), for the output= it always writes full limb (with hopefully proper zero/sign extensions). The implemented algorith is the base school book multiplication, if really needed, we could do Karatsuba for larger inputs. What do you think about this API? Shall I continue and create similar API for divmod? Also, wonder what to do about _BitInt(N) in __builtin_mul_overflow{,_p}. O= ne option would be to say that negative retprec is a request to return a nonze= ro result for the overflow case, but wonder how much larger the routine would = be in that case. Or if we should have two, one for multiplication and one for multiplication with overflow checking. Yet another possibility is to do a dumb thing on the compiler side, call the multiplication with a temporary result as large tha= t it would never overflow and check for the overflow on the caller side.=