From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sender4-pp-o90.zoho.com (sender4-pp-o90.zoho.com [136.143.188.90]) by sourceware.org (Postfix) with ESMTPS id 131953858D20; Wed, 21 Feb 2024 19:16:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 131953858D20 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 131953858D20 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=1708543001; cv=pass; b=XCpVKBmm9A5Fhqrvi2EobyacZy2AEvTOd7ZlrCBsh5WLBxDc0D8qG+Og1JzTAZRJntlPJnAlIjtYPusxUr0iigznkhlJIbV+pDmEIYAIMvfJp0W8+Zhz0ssfp0uIKrQkwXLV/L3lzfrv2TnFIWyvgSEumW4Mjsy8nOGr6N7mVyk= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1708543001; c=relaxed/simple; bh=0rFL6UySiP7o7P8sZ/qAMI4WHXpe9WhXQgKwJ+C6X7o=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=iwFgaSvW0SpqvDCMNXp4ozTAp8s4oThjhIXM/SDwHVk4SOsZsLLFj4UL/U29I2qIAjUMiSP4zF1R0byx+qZZ/ZwjeBjxsdHh8PGAz2RAf31FXBkIMrWXog1NVxokcBZ8uBgSOSxDMJvhBn0K2K+Ery4OIshZ1GVDLAMaHJ+/jvI= ARC-Authentication-Results: i=2; server2.sourceware.org ARC-Seal: i=1; a=rsa-sha256; t=1708542995; cv=none; d=zohomail.com; s=zohoarc; b=iCZX6pwozkfpyHO6FYcqKLqO7E+FITlh59Ez4LD1L0JhOUORb/gHnz6HDl1NBSkv8WCP2UQFbsQFalREYu8RJUK5nW+RSUDnN6+v41O2dgZpJh1m4jayX3xqiKVVQkvTCAAaJ2r2Wbi5AAR5I6+X1NkLaw57lW3M/NlBP3KEY7M= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1708542995; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To:Cc; bh=0rFL6UySiP7o7P8sZ/qAMI4WHXpe9WhXQgKwJ+C6X7o=; b=Lo7+RIznxF3GxS0XwqyakG5V+rpm/8hjNuhixkCd0Xs29xT668GpvE75ftF973ThVrqturvtYi3Dr32tI3shq7k1XRvIxIzHCw9PNhxivW94Ken3QaEq+Sy4F8/3rwxzEAFQQvqciKuZM8cYSNsp2k8rICopVuFCRrviiU5yn/E= 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= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1708542995; s=zm2022; d=zoho.com; i=bouanto@zoho.com; h=Message-ID:Subject:Subject:From:From:To:To:Date:Date:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:MIME-Version:Feedback-ID:Message-Id:Reply-To:Cc; bh=0rFL6UySiP7o7P8sZ/qAMI4WHXpe9WhXQgKwJ+C6X7o=; b=DTGUN/vgy8SMt6JCXqCsbknHd06L3bqxDcza1Y8BMgiG5B8rygwYF3d1pVqMgWOf Ev6Pe2pIFOkpT4mXfNAA4x6Dfi3SQeCnksiCoHFeaH0M+f0ZeU0qWhBn3crPpLmU9q8 0f8S4uYIbYIR1cUPGa/0Bcg6WqBvcAxeIyT0+BTU= Received: from [192.168.1.172] (38.87.11.6 [38.87.11.6]) by mx.zohomail.com with SMTPS id 1708542993951203.53993408165854; Wed, 21 Feb 2024 11:16:33 -0800 (PST) Message-ID: <2580ac0ae1b503e737602d18759adc4b7fa23d16.camel@zoho.com> Subject: Re: [PATCH] libgccjit: Fix get_size of size_t From: Antoni Boucher To: David Malcolm , jit@gcc.gnu.org, gcc-patches@gcc.gnu.org Date: Wed, 21 Feb 2024 14:16:32 -0500 In-Reply-To: <77e49df168b29f0658bd4252671ca1b07e0a1f8a.camel@redhat.com> References: <295f32d194b7b26bd02ce540f8df75a86fc20982.camel@zoho.com> <77e49df168b29f0658bd4252671ca1b07e0a1f8a.camel@redhat.com> 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: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.3 MIME-Version: 1.0 Feedback-ID: rr080112283fba0a855c33d795954c57500000d61e93b1217cb8ac27cfc700d6bff5429084a7018448afbd61c5:zu0801122672efe49dff9e2cf7fda1522800006baf2089cc18720681d325cc16a5e92e410fdd644bc1981c:rf080112319236cb40dff676961b68ee8d0000f6b113deb4ad03ee6f91d6bb4c34ab330a9e2cc1b96c6778e0e78d5940c15f9244ded9:ZohoMail X-ZohoMailClient: External X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,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 List-Id: 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). > >=20 > > 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). > >=20 > > 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. >=20 > 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. >=20 > >=20 > > 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. >=20 > 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 >=20 > Dave >=20