[PATCH] libgccjit: Fix get_size of size_t

[Antoni Boucher]

David: Ping

Le 2024-06-27 à 20 h 49, Antoni Boucher a écrit :
> 
> 
> 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
>>>>
>>>
>>