From: Iain Buclaw <ibuclaw@gdcproject.org>
To: Antoni Boucher <bouanto@zoho.com>,
David Malcolm <dmalcolm@redhat.com>,
gcc-patches@gcc.gnu.org, jit@gcc.gnu.org
Cc: Arthur Cohen <arthur.cohen@embecosm.com>
Subject: Re: Frontend access to target features (was Re: [PATCH] libgccjit: Add ability to get CPU features)
Date: Sun, 10 Mar 2024 12:05:47 +0100 [thread overview]
Message-ID: <1710063672.3qlr6ik163.astroid@pulse.none> (raw)
In-Reply-To: <997ddb068ca13f755accd03f38141e56c87b84a7.camel@redhat.com>
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.
next prev parent reply other threads:[~2024-03-10 11:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-09 22:27 [PATCH] libgccjit: Add ability to get CPU features Antoni Boucher
2023-11-09 23:04 ` David Malcolm
2023-11-10 0:33 ` Antoni Boucher
2023-11-30 22:11 ` Antoni Boucher
2024-03-05 15:09 ` Frontend access to target features (was Re: [PATCH] libgccjit: Add ability to get CPU features) David Malcolm
2024-03-10 11:05 ` Iain Buclaw [this message]
2024-03-18 11:39 ` Antoni Boucher
2024-06-26 21:55 ` David Malcolm
2024-03-19 11:03 ` Arthur Cohen
2024-04-01 12:20 ` Antoni Boucher
2024-04-09 13:21 ` Antoni Boucher
2024-04-19 12:34 ` Antoni Boucher
2024-04-26 13:51 ` Antoni Boucher
2024-06-12 12:21 ` Antoni Boucher
2023-12-13 19:56 ` [PATCH] libgccjit: Add ability to get CPU features Antoni Boucher
2024-01-10 23:18 ` Antoni Boucher
2024-01-11 18:49 ` Antoni Boucher
2024-01-19 12:53 ` Antoni Boucher
2024-01-20 14:50 ` Antoni Boucher
2024-01-30 15:50 ` Antoni Boucher
2024-02-06 12:54 ` Antoni Boucher
2024-02-13 18:37 ` Antoni Boucher
2024-02-29 15:34 ` Antoni Boucher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1710063672.3qlr6ik163.astroid@pulse.none \
--to=ibuclaw@gdcproject.org \
--cc=arthur.cohen@embecosm.com \
--cc=bouanto@zoho.com \
--cc=dmalcolm@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jit@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).