Message ID | 295f32d194b7b26bd02ce540f8df75a86fc20982.camel@zoho.com |
---|---|
State | Accepted |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp5100654vqy; Thu, 7 Dec 2023 14:26:35 -0800 (PST) X-Google-Smtp-Source: AGHT+IFjoUt1q5Hg1p5ci80MyXhwNHpvPBlzZK2m6pK7CDcawJ7gI0mAdiPf22YShDTSS1f4kv7C X-Received: by 2002:a05:6358:6184:b0:170:21d3:314e with SMTP id w4-20020a056358618400b0017021d3314emr3606808rww.49.1701987995033; Thu, 07 Dec 2023 14:26:35 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1701987995; cv=pass; d=google.com; s=arc-20160816; b=zWpsC3HnP+1drz0FgTmv6LPO1w5TPnIQyoqdgVp4Rd4Dd80xSUvJ9Mo0fYpAEwovny xWJQhxXsaay6WhUOLDMQHKD+pYEMmyrWe9kWnDirRe0YihqcDNaQDMso4RnXWh5Ciq7s 0qbMS+EwShFPWQ8VZO9oopv8zX4gopSHcAlcoBspMltRonktfA0aveBmLS2ljybApGsz vNlwOiooej52PfqHAb3uvDKRfQxFuGJ7gj9TMJffwb2eJTi39DOL/hOTDm73bS5KEFKF +vzqq+QAZH2mLWsXGmhXvFxvxpqX+95GVk7pqpjE4FmSnozUPGw8JC3knH6WRqZJpnov YVtg== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:feedback-id:mime-version :user-agent:autocrypt:date:cc:to:from:subject:message-id :dkim-signature:arc-filter:dmarc-filter:delivered-to; bh=HU4HiBv64EL+BKs1tJ9JhNwmceT5SlYZ3Re66/N+sK0=; fh=JISpz+bBSU4NvpZkyVsds76plEm8twWz26DY1VOoDBc=; b=WJ2ODEwU486/uYVMHZGszfHFLFlx9MhVyBMY2K8hOwsHdBi9xdfHWrqvQy6hFte6f7 A4pLoUM64cV9JH4E6mlLZ7Bwtos3f22efavZUIp+6qt2rEt9fYa6pc/t/eGcYBFf6cgm K4I46l0j0LpdfodSfckg90m2j/H3n/NN0E+DyDia2/d9dGwzh1C/0qvbjGPg75Aq5/CN OEy4YyvaoUKDZIc6KWRBF48fSYALOlcSHNtnhgu0ZJnnvbeG2w/rryOqmioA+i6LNGiW q5vaXGJvB5xBqw+kw1j4VPVvzAG/zitQoABvFDLDDiwrPK0whT/18gAgsUWKMabT94iX rh2Q== ARC-Authentication-Results: i=3; mx.google.com; dkim=pass header.i=@zoho.com header.s=zm2022 header.b="YmpR/OLr"; arc=pass (i=2); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=zoho.com Received: from server2.sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id t12-20020a056214154c00b0067ad125d1aesi761436qvw.109.2023.12.07.14.26.34 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Dec 2023 14:26:35 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@zoho.com header.s=zm2022 header.b="YmpR/OLr"; arc=pass (i=2); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=zoho.com Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C3FD53858422 for <ouuuleilei@gmail.com>; Thu, 7 Dec 2023 22:26:34 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from sender4-pp-o90.zoho.com (sender4-pp-o90.zoho.com [136.143.188.90]) by sourceware.org (Postfix) with ESMTPS id C2BDB3858D20; Thu, 7 Dec 2023 22:26:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C2BDB3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=zoho.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=zoho.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C2BDB3858D20 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=136.143.188.90 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1701987971; cv=pass; b=P6S6hE9ZRaguSiPpWjlyLCqoKE/XtIgLZINaukYv5V8DZpO9FXktJKicq9UQV3q1OTySo3Ukqg9X0WY2OSnEzadSJBWzrla87M+pVO1h+zg4sowmqm4XfARUumMQwnUoz9u+1Q0p0EkbGodUc2A9yqru1yoz5I+bCwYpFSpqYu0= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1701987971; c=relaxed/simple; bh=E5mxsV/qQXnNTNO8e+Bb3kFdh4aJBcLCmMwIzrm+7q4=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=d29oT7o0qdbAzIvoBe1OPfSdHAa6F+bDKi6eGAeGYJ+xuh/43GP/lhrvOt6OUYOt4r/T4O50Vnk45G8iWXEom5ZX5hnxGz2rIVjVfw0hlEkA0CLWwx6CowCyg7ZJtZSmoQXr3BJkyZA/5tAwictA+PusH7PIygwQu2vez7lgp50= ARC-Authentication-Results: i=2; server2.sourceware.org ARC-Seal: i=1; a=rsa-sha256; t=1701987963; cv=none; d=zohomail.com; s=zohoarc; b=kxtLnH9j7V5Cdl02O3XTg2toHTEk3HBGxEdWVcMhINXywxE153g792WHQ4v2kKQVbc+58G5NXqnzWPZEv151DPwsOLXMtZ/zpHYwmcOsN918j9zOzLQm4H/Pd9/Thc1y4iu0taeg8fWKjUU6PbTJ3NKFe5yiY3ERbxKBDhdMJo4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1701987963; h=Content-Type:Cc:Cc:Date:Date:From:From:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; bh=HU4HiBv64EL+BKs1tJ9JhNwmceT5SlYZ3Re66/N+sK0=; b=Aa9LF2Vz0Ze7Rsz7f30XAeEZ4KaMlZWLv2MAoABPP37JoXDm6XMEmy5v3p9XPNsA1qsgKMldsObTOQoP6etSiMfy6fFi+ujP50SskBc3a+Ab5TxMKECyvZbCAfaEy68mON3njluWTEHevdU9DxTv9AQJOvJB8MHEwkwz4jh6VOk= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=zoho.com; spf=pass smtp.mailfrom=bouanto@zoho.com; dmarc=pass header.from=<bouanto@zoho.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1701987963; s=zm2022; d=zoho.com; i=bouanto@zoho.com; h=Message-ID:Subject:Subject:From:From:To:To:Cc:Cc:Date:Date:Content-Type:MIME-Version:Feedback-ID:Message-Id:Reply-To; bh=HU4HiBv64EL+BKs1tJ9JhNwmceT5SlYZ3Re66/N+sK0=; b=YmpR/OLrc5RsnD7mBz+PyFSTZ+GKJbHivtEhervj17euiwMzTkE+LnuN7jQb3YBh NwLZk0SpUt1R3J89z2+xgnVVIrzFapZUGd2uMjoiWF1LvjB1zgfGAu8GW9WfiJVc1S2 29W0QhNlf6V7dxRU4//A0A5su3eZ0nYhOX3pGDcY= Received: from [192.168.1.172] (38.87.11.6 [38.87.11.6]) by mx.zohomail.com with SMTPS id 1701987963301214.3867024757584; Thu, 7 Dec 2023 14:26:03 -0800 (PST) Message-ID: <295f32d194b7b26bd02ce540f8df75a86fc20982.camel@zoho.com> Subject: [PATCH] libgccjit: Fix get_size of size_t From: Antoni Boucher <bouanto@zoho.com> To: jit@gcc.gnu.org, gcc-patches@gcc.gnu.org Cc: David Malcolm <dmalcolm@redhat.com> Date: Thu, 07 Dec 2023 17:26:01 -0500 Autocrypt: addr=bouanto@zoho.com; prefer-encrypt=mutual; keydata=mQENBFOSMLQBCADO5aw6Ys8thMQUNzrwAnfJX2wbgWiz0pQ01DjYj22eeIpChkoZn6LWdt4dieq30u2rFi/yQzJ02foHwI2+aL9rU6xz/x4TwqyRJQGMOqklNc3R+pdXmH4WDQkQDWmLxvc07vu+zb8Tx5A6pMDh4J2ncCEhLEUcH39Yq/yg4eBnFwUX6N7kakvHrnScGNqhnSFCacoJeMJUAR+1G7VBSBd++jmnHLnx3mj7QkRZVECJUw2zqiv1yReCC6GU4SvqLjdqm5ZGeoWOqD/NHjBRoEeOVjzp6M/qOjjWRbkJVqmvgfcD8UytSSqqboR35YFT4L+rZt2ri3T12MJb3i5syCAXABEBAAG0IUFudG9uaSBCb3VjaGVyIDxib3VhbnRvQHpvaG8uY29tPokBVgQTAQgAQAIbIwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAFiEEOELC4Uw1Jeb66YE6RVeGAwR4zcEFAlz4QM4FCRLMEZoACgkQRVeGAwR4zcFBQQf/afttJrA/puADQZhrDfkgr0MFvq6iB+GCy1b8BkXimk1TOXTPt87YLehSeijNu3JkYhl5eRc87BNfU9J87KfI/KIy6hZxqlDXk16FhW9bw/7wYEA0hpb3MUn7xLElXDT0ZHaD+KTe8Oun7qfzgx5RlL6r/WODf3CkSpO085R/rfeBqDEx9mVlhDWgq6Az3CZoD+3CqiCKVqmDuHTWz4kwrd9AM5eVcLvvLKnZIdoIp+G5Ao6BvaGlZyfenN1iOSjLy2NXNt4MnUt0lUYEP5KSIIRhHQ8xkUbj7eWUmaahkxhNb3fH3sAPwGnRZrPpb4rgYzNmSk63wWMh9M2xk+rLb7kBDQRTkjC0AQgAumZzsAV/UFWI+dpzebQfma36kKYZZFuseant5sq/HWP553XQ/U6ttJiKyN5MpCqtxvCAoRplf42YhlHuFqgf73WJxoJ6Y+sdyqoBSwlR+ gzAneAmsa8gmmY0wawH0Z2leazjKuS7mJjVEQZg0ZGsiCVRGeRnDqFGzDEzDc9ngWKSoTq0fKzlGy1X85OrtmUrvEbhSo6HP+FoeunHkIqrxu3w3vDoFEXxVQlKI6V3I4nCz5n6DB8WR3L7nsiiTnOiGirPw1ngvWFLW86kkA4FJpayc8Xl3va3SLY+2y4yuROboX2DVI4AC/Qeug/mDiBicPxkP6YfUartQRMe6obkEQARAQABiQE8BBgBCAAmAhsMFiEEOELC4Uw1Jeb66YE6RVeGAwR4zcEFAlz4QRsFCRLMEecACgkQRVeGAwR4zcE56ggAgTgrJInBKC+7552Dpccuo6Clh3wZfjlNLv9/6r5lKEbaNzaTrfhPiAP4WgnluIUmj8amOFLFJpj+BAVNOXpZ4D2R3o9ch8z7fot+fW4Yw+PKIxH4I2xEys8ndoEB3aiQwHjKcGIhkIU7uyMJFQr2aWjdTY0gmXw0YZueHOSLgo7uX4XKxB8fEO/yto/Tff2YBAAq+AtNwt+Gh5YS9rZw7rwUTWMi84yVOlc+zRE79E9NJkvdTwX7IJYo64VzIRNfgHsn7QNdVzuM1XIFHl+Glk6cIlI8s6BO7nEoCn3hTF104fQTAO3fEs+XXZOKXo2lk8faowEoPq5r58StrV0nyg== Content-Type: multipart/mixed; boundary="=-n4d+r6MXXAQaedHASNps" User-Agent: Evolution 3.50.2 MIME-Version: 1.0 X-Zoho-Virus-Status: 1 X-Zoho-AV-Stamp: zmail-av-1.1.0/201.873.56 Feedback-ID: rr0801122868e0ed64522ea1b4735658ed000012d682654f97e7c22cecd5ff1a6d633dc93e30b891563c536ed9:zu08011226da1dc56c524983d52d0baae20000bd85e905c983efb7aba3ad2990acf3bc9287c6bebb6e1c3e:rf08011232789e2d6f39ad8e0845ac7fcd0000f7ff2b82f13ba821fe3c9ea0e473e9588314d4b6ddde57397ff5e04334a128894b1934d6:ZohoMail X-ZohoMailClient: External X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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 <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784663763718611158 X-GMAIL-MSGID: 1784663763718611158 |
Series |
libgccjit: Fix get_size of size_t
|
|
Checks
Context | Check | Description |
---|---|---|
snail/gcc-patch-check | success | Github commit url |
Commit Message
Antoni Boucher
Dec. 7, 2023, 10:26 p.m. UTC
Hi. This patch fixes getting the size of size_t (bug 112910). There's one issue with this patch: like every other feature that checks for target-specific stuff, it requires a compilation before actually fetching the size of the type. Which means that getting the size before a compilation might be wrong (and I actually believe is wrong on x86-64). I was wondering if we should always implicitely do the first compilation to gather the correct info: this would fix this issue and all the others that we have due to that. I'm not sure what would be the performance implication. Another solution that I have been thinking about for a while now would be to have another frontend libgccaot (I don't like that name), which is like libgccjit but removes the JIT part so that we get access to the target stuff directly and would remove the need for having a seperation between recording and playback as far as I understand. That's a long-term solution, but I wanted to share the idea now and gather your thoughts on that. Thanks for the review.
Comments
On Thu, 2023-12-07 at 17:26 -0500, Antoni Boucher wrote: > Hi. > This patch fixes getting the size of size_t (bug 112910). > > There's one issue with this patch: like every other feature that > checks > for target-specific stuff, it requires a compilation before actually > fetching the size of the type. > Which means that getting the size before a compilation might be wrong > (and I actually believe is wrong on x86-64). > > I was wondering if we should always implicitely do the first > compilation to gather the correct info: this would fix this issue and > all the others that we have due to that. > I'm not sure what would be the performance implication. Maybe introduce a new class target_info which contains all the information we might want to find via a compilation, and have the top- level recording::context have a pointer to it, which starts as nullptr, but can be populated on-demand the first time something needs it? > > Another solution that I have been thinking about for a while now > would > be to have another frontend libgccaot (I don't like that name), which > is like libgccjit but removes the JIT part so that we get access to > the > target stuff directly and would remove the need for having a > seperation > between recording and playback as far as I understand. > That's a long-term solution, but I wanted to share the idea now and > gather your thoughts on that. FWIW the initial version of libgccjit didn't have a split between recording and playback; instead the client code had to pass in a callback to call into the various API functions (creating tree nodes). See: https://gcc.gnu.org/legacy-ml/gcc-patches/2013-10/msg00228.html Dave
On Thu, 2023-12-07 at 19:57 -0500, David Malcolm wrote: > On Thu, 2023-12-07 at 17:26 -0500, Antoni Boucher wrote: > > Hi. > > This patch fixes getting the size of size_t (bug 112910). > > > > There's one issue with this patch: like every other feature that > > checks > > for target-specific stuff, it requires a compilation before > > actually > > fetching the size of the type. > > Which means that getting the size before a compilation might be > > wrong > > (and I actually believe is wrong on x86-64). > > > > I was wondering if we should always implicitely do the first > > compilation to gather the correct info: this would fix this issue > > and > > all the others that we have due to that. > > I'm not sure what would be the performance implication. > > Maybe introduce a new class target_info which contains all the > information we might want to find via a compilation, and have the > top- > level recording::context have a pointer to it, which starts as > nullptr, > but can be populated on-demand the first time something needs it? That would mean that we'll need to populate it for every top-level context, right? Would the idea be that we should then use child contexts to have the proper information filled? If so, how is this different than just compiling two contexts like what I currently do? This would also mean that we'll do an implicit compilation whenever we use an API that needs this info, right? Wouldn't that be unexpected? Thanks for the idea. > > > > > Another solution that I have been thinking about for a while now > > would > > be to have another frontend libgccaot (I don't like that name), > > which > > is like libgccjit but removes the JIT part so that we get access to > > the > > target stuff directly and would remove the need for having a > > seperation > > between recording and playback as far as I understand. > > That's a long-term solution, but I wanted to share the idea now and > > gather your thoughts on that. > > FWIW the initial version of libgccjit didn't have a split between > recording and playback; instead the client code had to pass in a > callback to call into the various API functions (creating tree > nodes). > See: > https://gcc.gnu.org/legacy-ml/gcc-patches/2013-10/msg00228.html > > Dave >
From 37d25e55a0c79893c7ea7f4cb9f0842b8a9b4906 Mon Sep 17 00:00:00 2001 From: Antoni Boucher <bouanto@zoho.com> Date: Fri, 3 Nov 2023 17:49:18 -0400 Subject: [PATCH] libgccjit: Fix get_size of size_t gcc/jit/ChangeLog: PR jit/112910 * jit-recording.cc (recording::memento_of_get_type::get_size): Correctly compute the size of size_t. --- gcc/jit/jit-recording.cc | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc index 9b5b8005ebe..ea1f76d4415 100644 --- a/gcc/jit/jit-recording.cc +++ b/gcc/jit/jit-recording.cc @@ -2392,7 +2392,34 @@ recording::memento_of_get_type::get_size () size = LONG_DOUBLE_TYPE_SIZE; break; case GCC_JIT_TYPE_SIZE_T: - size = MAX_BITS_PER_WORD; + /* Compare with tree.cc's build_common_tree_nodes. */ + if (strcmp (SIZE_TYPE, "unsigned int") == 0) + size = INT_TYPE_SIZE; + else if (strcmp (SIZE_TYPE, "long unsigned int") == 0) + size = LONG_TYPE_SIZE; + else if (strcmp (SIZE_TYPE, "long long unsigned int") == 0) + size = LONG_LONG_TYPE_SIZE; + else if (strcmp (SIZE_TYPE, "short unsigned int") == 0) + size = SHORT_TYPE_SIZE; + else + { + int i; + + for (i = 0; i < NUM_INT_N_ENTS; i++) + if (int_n_enabled_p[i]) + { + fprintf (stderr, "%d\n", i); + char name[50], altname[50]; + sprintf (name, "__int%d unsigned", int_n_data[i].bitsize); + sprintf (altname, "__int%d__ unsigned", int_n_data[i].bitsize); + + if (strcmp (name, SIZE_TYPE) == 0 || strcmp (altname, SIZE_TYPE) == 0) + { + return int_n_data[i].bitsize / BITS_PER_UNIT; + } + } + gcc_unreachable (); + } break; default: /* As this function is called by -- 2.43.0