From patchwork Sat Feb 10 10:19:16 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 1897336 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=hZWgrLeV; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4TX6Cf63wmz23hf for ; Sat, 10 Feb 2024 21:19:42 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9BB793858C52 for ; Sat, 10 Feb 2024 10:19:40 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id C890E3858D20 for ; Sat, 10 Feb 2024 10:19:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C890E3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C890E3858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707560364; cv=none; b=IM280iIIHb55e47/oMWrIpbBUyJ72IF0xiY6E2ajwCJjAJ8QSv4ovtsBRfLyp5OW9e23A01YNNQJ1+QG/Xxmxgq74AAIXB87KJ0KB6ktIiV8YqJPEaoVUfxMSRa4eR9FYBYXQLu99Q0k7YE/BBVV756u5wumNbQQysWprmHDYDw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707560364; c=relaxed/simple; bh=Js5yS+qWziKiKgFDkMItKVENPkCaWh4fegWH5SvDgRA=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=nHdwHQaaYG58frhmS7yddAEUUchs57OBiMPqPOrAk1S2StTL3lr2v4mAQovA43LHiazrZznBPHqipJMdnJPR7UV2pJFEad4jDtIK8Qq8z1aOu5ot8zpYUDR5576XjCyIBDxN1V3DOzCk/rUxx34W0zfhP3g9WPuC0TkxWkg855k= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1707560362; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type; bh=6oc3HWFSha3Z7bdJCXCnt8/prbINQgpcjZsgCMFoHVo=; b=hZWgrLeV5rJGMtO0k1qh08s6CUb3i+h8JDy/U65OUOUu6+Uyir+Q6g2ljtbh4MFOj2eIo5 3QupabiQiSXDxAHYWMmXYJv/gtXCe2IuW6YygFIfL8M/PQCaSuG+OZej6Nk5C4TpWEgRcP I2LaRyjpB2+r06g+4FzakD6gmYZ33to= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-180-YJ55Le5vOtusi7vDtIUuhw-1; Sat, 10 Feb 2024 05:19:21 -0500 X-MC-Unique: YJ55Le5vOtusi7vDtIUuhw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id AF06C83B7E6; Sat, 10 Feb 2024 10:19:20 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.70]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6C245AC17; Sat, 10 Feb 2024 10:19:20 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 41AAJHuI4023558 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sat, 10 Feb 2024 11:19:18 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 41AAJG8D4023557; Sat, 10 Feb 2024 11:19:16 +0100 Date: Sat, 10 Feb 2024 11:19:16 +0100 From: Jakub Jelinek To: Uros Bizjak , Jan Hubicka , "H.J. Lu" , "Joseph S. Myers" Cc: gcc-patches@gcc.gnu.org Subject: [RFC PATCH] i386: Enable _BitInt support on ia32 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_NUMSUBJECT, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Jakub Jelinek Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Hi! Given the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837#c9 comment, the following patch just attempts to implement what I think is best for ia32. Compared to https://gitlab.com/x86-psABIs/i386-ABI/-/issues/5 , like that patch for _BitInt(64) or smaller it uses the smallest containing {,un}signed {char,short,int,long long} for passing/returning and layout of variables including in structures for alignment/size, with any extra bits unspecified. Unlike the above proposal, for larger _BitInt (i.e. _BitInt(65)+), it uses passing/returning/layout/alignment of structure containing minimum needed number of 32-bit limbs, again with the extra bits unspecified. This is because most operations (except copy or bitwise ops) on _BitInts aren't really vectorizable and will be under the hood implemented in loops over 32-bit limbs anyway (using 64-bit limbs under the hood would mean often using library implementation for the basic operations) and because ia32 doesn't align even long long/double in structures to 64-bit I think it is better to just use 32-bit alignment for that. And I don't see a reason to waste 32-bit bits say for _BitInt(224) or _BitInt(288) on ia32. So, effectively it is like the x86-64 _BitInt ABI with everything divided by 2, the only exception is that in x86-64 psABI _BitInt(128) is said to be already a structure of 2 limbs, which happens to be passed mostly the same as __int128 (except for alignment). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? There are still 2 regressions: +FAIL: gcc.dg/pr113693.c at line 13 (test for warnings, line ) +FAIL: gcc.dg/torture/bitint-24.c -O0 execution test +FAIL: gcc.dg/torture/bitint-24.c -O2 execution test For pr113693.c I think we'll need to do something with the test, either make it x86_64 specific, add say -msse2 option for ia32, move to gcc.dg/vect/ And bitint-24.c case seems to be miscompilation of __floatbitintxf when built with -O2 -m32, it works fine when compiled with -O0 -m32. Will address that next week. 2024-02-10 Jakub Jelinek * config/i386/i386.cc (ix86_bitint_type_info): Add support for !TARGET_64BIT. Jakub --- gcc/config/i386/i386.cc.jj 2024-02-09 11:02:15.193830702 +0100 +++ gcc/config/i386/i386.cc 2024-02-09 16:30:28.568240299 +0100 @@ -25757,13 +25757,11 @@ ix86_get_excess_precision (enum excess_p bool ix86_bitint_type_info (int n, struct bitint_info *info) { - if (!TARGET_64BIT) - return false; if (n <= 8) info->limb_mode = QImode; else if (n <= 16) info->limb_mode = HImode; - else if (n <= 32) + else if (n <= 32 || (!TARGET_64BIT && n > 64)) info->limb_mode = SImode; else info->limb_mode = DImode;