From: Antoni Boucher <bouanto@zoho.com>
To: David Malcolm <dmalcolm@redhat.com>,
jit@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] libgccjit: Add ability to get CPU features
Date: Wed, 13 Dec 2023 14:56:18 -0500 [thread overview]
Message-ID: <2b7e3baa288273725432f1bb5d8b894e83ec8b25.camel@zoho.com> (raw)
In-Reply-To: <755705e37731c4fbc3ab7eb1a96d8df0147bb002.camel@redhat.com>
David: Ping.
I guess if we want to have this merged for this release, it should be
sooner rather than later (if it's still an option).
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?
>
> 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?
>
> 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?
>
> I'm not at expert at target hooks (or at the i386 backend), so if we
> do
> go with this approach I'd want someone else to review those parts of
> the patch.
>
> Have you verified that GCC builds with this patch with jit *not*
> enabled in the enabled languages?
>
> [...snip...]
>
> A nitpick:
>
> > +.. function:: const char * \
> > + gcc_jit_target_info_arch (gcc_jit_target_info *info)
> > +
> > + Get the architecture of the currently running CPU.
>
> What does this string look like?
> How long does the pointer remain valid?
>
> Thanks again; hope the above makes sense
> Dave
>
next prev parent reply other threads:[~2023-12-13 19:56 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-09 22:27 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
2024-03-18 11:39 ` Antoni Boucher
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
2023-12-13 19:56 ` Antoni Boucher [this message]
2024-01-10 23:18 ` [PATCH] libgccjit: Add ability to get CPU features 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=2b7e3baa288273725432f1bb5d8b894e83ec8b25.camel@zoho.com \
--to=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).