From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sender4-pp-o92.zoho.com (sender4-pp-o92.zoho.com [136.143.188.92]) by sourceware.org (Postfix) with ESMTPS id BAFE53831E0B; Fri, 28 Jun 2024 00:49:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BAFE53831E0B 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 BAFE53831E0B Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=136.143.188.92 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1719535772; cv=pass; b=NgHVU+DT7RkTBzC3bzXyp8v72DdGPTAfEkXjhMPXTQAqamrmnTb9mnYM8MbJz9gnmcCOhEZwGPNWzu/ZKF4H2z6mqcCVdIIb7HqAA0FmRHkjK6lKjGk4CjegpYpgX5V1kfivviF1E1BVk5QDPRyFg+7UpxLOOZwTtMvDav3Hx/M= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1719535772; c=relaxed/simple; bh=jkZkG+ofyQ4woyPwnDp1ZRTQk+4VPcbpKDIb1a3/PhY=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=VGY11bYXysZ3c+Ent3nKppD2LGxoEAHsXPvirvUDfPTkmVoCEZy4Ui/v6xpyLr01s+6SPHNk8s+sQ5PxcrXxTlvXBjRmp9swUNCkqaOXWTiie63nVx34XZNhUvapcYqnzE/fx1RmXS+UYY3Gzq3phzz6Or4ZD483GQQLkOsNhWI= ARC-Authentication-Results: i=2; server2.sourceware.org ARC-Seal: i=1; a=rsa-sha256; t=1719535761; cv=none; d=zohomail.com; s=zohoarc; b=XqSGckm8jC0nVcfhVDWRlBvFRbmQFDM4iaJGv//883+vMopQ56a95/hD6RLPW8//DXlvpYuLLSyooPzA7V2wpK66ybJ43xY8GKxhF56SJS34TLvR4bKodrZIpjrVz5ZULTCDPf4CEPQWFl90WuoAKlxzsZtuUT6PlWtQBT4rkfs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1719535761; 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=w7oL/6ZZn8MA+JjvxJOu9v/Ln54laN/Q6csy12SsmQk=; b=IM2mxl7kZYWHn/qRBKtnsX+VpF2iJi3Er9GBCEoayEf/CirOBrXPRO7eqW3deog0g9m8OrBRUPsLYZc8kVw1OVlESz5+Gxmd80FC66Cy2lPmx+Fk0otBa3seMC1opfBUaA2exUc4FRuJcv0qVDUvGtQg0DoX3cP6wOHzTNv/nGY= 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=1719535761; s=zm2022; d=zoho.com; i=bouanto@zoho.com; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID:Message-Id:Reply-To:Cc; bh=w7oL/6ZZn8MA+JjvxJOu9v/Ln54laN/Q6csy12SsmQk=; b=enuOgjmtpfXa6qBHnWoIl6yxZWrgNC0FfHzqWgTuvkKSv1oX9vA0OgZe7YKDEoQ2 4Pcy8r2WmrTER1NyXPAH1sZ1OC6YnG/pmMkXhXb5LDlR4Vio4H1dAp6zIlvfDKI06No HaNdoXgGYAfNyznwvW1BPGaborqrM4CAKzJntadU= Received: by mx.zohomail.com with SMTPS id 1719535759630262.2704226146568; Thu, 27 Jun 2024 17:49:19 -0700 (PDT) Message-ID: <18209b2c-f3f5-453b-bfb0-8ab10d8d9cad@zoho.com> Date: Thu, 27 Jun 2024 20:49:18 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] libgccjit: Fix get_size of size_t To: David Malcolm , jit@gcc.gnu.org, gcc-patches@gcc.gnu.org References: <295f32d194b7b26bd02ce540f8df75a86fc20982.camel@zoho.com> <77e49df168b29f0658bd4252671ca1b07e0a1f8a.camel@redhat.com> <2580ac0ae1b503e737602d18759adc4b7fa23d16.camel@zoho.com> Content-Language: en-US, fr From: Antoni Boucher In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Feedback-ID: rr080112288743006e4ea9b016ad57db4300007332d195c369f1095a2bcd2adc6452c3b6cdbff9b43df4d34c20:zu08011226e664b5cbd7a7bdd8c05754f00000fc64201c981f6266a93af48c7903f63d57b5b515b308e8bf:rf0801122cf0b8839817ec18240238c4960000c997a4441381a5227fff248738b63af298491e401837ca4d110e656ea34d:ZohoMail X-ZohoMailClient: External X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,SPF_HELO_NONE,SPF_PASS,TXREP 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: Le 2024-06-26 à 18 h 01, David Malcolm a écrit : > On Wed, 2024-02-21 at 14:16 -0500, Antoni Boucher wrote: >> 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? > > I was thinking a compilation with an empty playback::context to lazily > capture the target data. I'm still not sure I understand what you mean. Do you mean having a global context that we can compile to then fetch the size of the types? If not, could you please provide an example with some code? I'm wondering if we could have something that would also work for custom types like structs. I'm also not sure what would happen if options that change the size of types (like -m32) are provided by the user. Is the way libgccjit currently work (with 2 phases: recording and playback) this way because gcc is not thread-safe? If we could directly create GENERIC trees, we could get the size from those, but it seems like this would not be possible. > > My hope was that this would make things easier for users. But you're > the one using this API, so if you're more comfortable with the explicit > initial compilation approach, let's go with that. > > If so, this is OK for trunk - but we might want to add a note to the > documentation about the double-compilation workaround. > > Dave > > >> >> 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 >>> >> >