Re: Frontend access to target features (was Re: [PATCH] libgccjit: Add ability to get CPU features)

[Antoni Boucher <bouanto@zoho.com>]

David: Ping.

Le 2024-03-10 à 07 h 05, Iain Buclaw a écrit :
> Excerpts from David Malcolm's message of März 5, 2024 4:09 pm:
>> On Thu, 2023-11-09 at 19:33 -0500, Antoni Boucher wrote:
>>> Hi.
>>> See answers below.
>>>
>>> On Thu, 2023-11-09 at 18:04 -0500, David Malcolm wrote:
>>>> On Thu, 2023-11-09 at 17:27 -0500, Antoni Boucher wrote:
>>>>> Hi.
>>>>> This patch adds support for getting the CPU features in libgccjit
>>>>> (bug
>>>>> 112466)
>>>>>
>>>>> There's a TODO in the test:
>>>>> I'm not sure how to test that gcc_jit_target_info_arch returns
>>>>> the
>>>>> correct value since it is dependant on the CPU.
>>>>> Any idea on how to improve this?
>>>>>
>>>>> Also, I created a CStringHash to be able to have a
>>>>> std::unordered_set<const char *>. Is there any built-in way of
>>>>> doing
>>>>> this?
>>>>
>>>> Thanks for the patch.
>>>>
>>>> Some high-level questions:
>>>>
>>>> Is this specifically about detecting capabilities of the host that
>>>> libgccjit is currently running on? or how the target was configured
>>>> when libgccjit was built?
>>>
>>> I'm less sure about this part. I'll need to do more tests.
>>>
>>>>
>>>> One of the benefits of libgccjit is that, in theory, we support all
>>>> of
>>>> the targets that GCC already supports.  Does this patch change
>>>> that,
>>>> or
>>>> is this more about giving client code the ability to determine
>>>> capabilities of the specific host being compiled for?
>>>
>>> This should not change that. If it does, this is a bug.
>>>
>>>>
>>>> I'm nervous about having per-target jit code.  Presumably there's a
>>>> reason that we can't reuse existing target logic here - can you
>>>> please
>>>> describe what the problem is.  I see that the ChangeLog has:
>>>>
>>>>>          * config/i386/i386-jit.cc: New file.
>>>>
>>>> where i386-jit.cc has almost 200 lines of nontrivial code.  Where
>>>> did
>>>> this come from?  Did you base it on existing code in our source
>>>> tree,
>>>> making modifications to fit the new internal API, or did you write
>>>> it
>>>> from scratch?  In either case, how onerous would this be for other
>>>> targets?
>>>
>>> This was mostly copied from the same code done for the Rust and D
>>> frontends.
>>> See this commit and the following:
>>> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b1c06fd9723453dd2b2ec306684cb806dc2b4fbb
>>> The equivalent to i386-jit.cc is there:
>>> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=22e3557e2d52f129f2bbfdc98688b945dba28dc9
>>
>> [CCing Iain and Arthur re those patches; for reference, the patch being
>> discussed is attached to :
>> https://gcc.gnu.org/pipermail/jit/2024q1/001792.html ]
>>
>> One of my concerns about this patch is that we seem to be gaining code
>> that's per-(frontend x config) which seems to be copied and pasted with
>> a search and replace, which could lead to an M*N explosion.
>>
> 
> That's certainly the case with the configure/make rules. Itself I think
> is copied originally from the {cpu_type}-protos.h machinery.
> 
> It might be worth pointing out that the c-family of front-ends don't
> have separate headers because their per-target macros are defined in
> {cpu_type}.h directly - for better or worse.
> 
>> Is there any real difference between the per-config code for the
>> different frontends, or should there be a general "enumerate all
>> features of the target" hook that's independent of the frontend? (but
>> perhaps calls into it).
>>
> 
> As far as I understand, the configure parts should all be identical
> between tm_p, tm_d, tm_rust, ..., so would benefit from being templated
> to aid any other front-ends adding in their own per target hooks.
> 
>> Am I right in thinking that (rustc with default LLVM backend) has some
>> set of feature strings that both (rustc with rustc_codegen_gcc) and
>> gccrs are trying to emulate?  If so, is it presumably a goal that
>> libgccjit gives identical results to gccrs?  If so, would it be crazy
>> for libgccjit to consume e.g. config/i386/i386-rust.cc ?
> 
> I don't know whether libgccjit can just pull in directly the
> implementation of the rust target hooks here.  The per-frontend target
> hooks usually also make use of code specific to that front-end -
> TARGET_CPU_CPP_BUILTINS and others can't be used by a non-c-family
> front-end without adding a plethora of stubs, for example.
> 
> Whether or not libgccjit wants to give identical information as as rust
> I think is a decision for you as the maintainer of its API.
> 
> Iain.