Re: Frontend access to target features (was Re: [PATCH] libgccjit: Add ability to get CPU features)
David: Ping. Le 2024-04-09 à 09 h 21, Antoni Boucher a écrit : David: Ping. Le 2024-04-01 à 08 h 20, Antoni Boucher a écrit : David: Ping. Le 2024-03-19 à 07 h 03, Arthur Cohen a écrit : Hi, On 3/5/24 16:09, David Malcolm wrote: 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. 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. I think this is definitely already the case, and it would be worth investigating if C/C++/Rust/jit can reuse a similar set of target files, or how to factor them together. I imagine that all of these components share similar needs for the targets they support. 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). 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 think this would definitely make sense, and it could probably be extended to other frontends. For the time being I think it makes sense to try it out for gccrs and jit. But finding a fitting name will be hard :) Best, Arthur Dave 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? I will do. [...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? It's the march string, like "znver2", for instance. It remains valid until we free the gcc_jit_target_info object. Thanks again; hope the above makes sense Dave
Re: [PATCH] libgccjit: Add support for machine-dependent builtins
David: Ping. Le 2024-02-29 à 10 h 34, Antoni Boucher a écrit : David: Ping. On Thu, 2024-02-15 at 09:32 -0500, Antoni Boucher wrote: David: Ping On Thu, 2024-02-08 at 08:59 -0500, Antoni Boucher wrote: David: Ping. On Wed, 2024-01-10 at 18:58 -0500, Antoni Boucher wrote: Here it is: https://gcc.gnu.org/pipermail/jit/2023q4/001725.html On Wed, 2024-01-10 at 18:44 -0500, David Malcolm wrote: On Wed, 2024-01-10 at 18:29 -0500, Antoni Boucher wrote: David: Ping in case you missed this patch. For some reason it's not showing up in patchwork (or, at least, I can't find it there). Do you have a URL for it there? Sorry about this Dave On Sat, 2023-02-11 at 17:37 -0800, Andrew Pinski wrote: On Sat, Feb 11, 2023 at 4:31 PM Antoni Boucher via Gcc- patches wrote: Hi. This patch adds support for machine-dependent builtins in libgccjit (bug 108762). There are two things I don't like in this patch: 1. There are a few functions copied from the C frontend (common_mark_addressable_vec and a few others). 2. Getting a target builtin only works from the second compilation since the type information is recorded at the first compilation. I couldn't find a way to get the builtin data without using the langhook. It is necessary to get the type information for type checking and instrospection. Any idea how to fix these issues? Seems like you should do this patch in a few steps; that is split it up. Definitely split out GCC_JIT_TYPE_BFLOAT16 support. I also think the vector support should be in a different patch too. Splitting out these parts would definitely make it easier for review and make incremental improvements. Thanks, Andrew Pinski Thanks for the review.
[PATCH] Add rvalue::get_name method (and its C equivalent)
Hi,
I just encountered the need to retrieve the name of an `rvalue` (if
there is one) while working on the Rust GCC backend.
This patch adds a getter to retrieve the information.
Cordially.
From d2ddeec950f23533e5e18bc0c10c4b49eef3cda3 Mon Sep 17 00:00:00 2001
From: Guillaume Gomez
Date: Sat, 20 Apr 2024 01:02:20 +0200
Subject: [PATCH] [PATCH] Add rvalue::get_name method
gcc/jit/ChangeLog:
* jit-recording.h: Add rvalue::get_name method
* libgccjit.cc (gcc_jit_rvalue_get_name): Likewise
* libgccjit.h (gcc_jit_rvalue_get_name): Likewise
* libgccjit.map: Likewise
gcc/testsuite/ChangeLog:
* jit.dg/test-tls.c: Add test for gcc_jit_rvalue_get_name
---
gcc/jit/jit-recording.h | 8
gcc/jit/libgccjit.cc| 16
gcc/jit/libgccjit.h | 4
gcc/jit/libgccjit.map | 5 +
gcc/testsuite/jit.dg/test-tls.c | 3 +++
5 files changed, 36 insertions(+)
diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
index d8d16f4fe29..3ae87c146ac 100644
--- a/gcc/jit/jit-recording.h
+++ b/gcc/jit/jit-recording.h
@@ -1213,6 +1213,8 @@ public:
virtual bool is_constant () const { return false; }
virtual bool get_wide_int (wide_int *) const { return false; }
+ virtual string * get_name () { return NULL; }
+
private:
virtual enum precedence get_precedence () const = 0;
@@ -1305,6 +1307,8 @@ public:
const char *access_as_rvalue (reproducer &r) final override;
const char *access_as_lvalue (reproducer &r) final override;
+ string * get_name () final override { return m_name; }
+
private:
string * make_debug_string () final override { return m_name; }
void write_reproducer (reproducer &r) final override;
@@ -1558,6 +1562,8 @@ public:
void set_rvalue_init (rvalue *val) { m_rvalue_init = val; }
+ string * get_name () final override { return m_name; }
+
private:
string * make_debug_string () final override { return m_name; }
template
@@ -2148,6 +2154,8 @@ public:
void write_to_dump (dump &d) final override;
+ string * get_name () final override { return m_name; }
+
private:
string * make_debug_string () final override { return m_name; }
void write_reproducer (reproducer &r) final override;
diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
index 445c0d0e0e3..2b8706dc7fd 100644
--- a/gcc/jit/libgccjit.cc
+++ b/gcc/jit/libgccjit.cc
@@ -4377,3 +4377,19 @@ gcc_jit_context_add_top_level_asm (gcc_jit_context *ctxt,
RETURN_IF_FAIL (asm_stmts, ctxt, NULL, "NULL asm_stmts");
ctxt->add_top_level_asm (loc, asm_stmts);
}
+
+/* Public entrypoint. See description in libgccjit.h.
+
+ After error-checking, this calls the trivial
+ gcc::jit::recording::rvalue::get_name method, in jit-recording.h. */
+
+extern const char *
+gcc_jit_rvalue_get_name (gcc_jit_rvalue *rvalue)
+{
+ RETURN_NULL_IF_FAIL (rvalue, NULL, NULL, "NULL rvalue");
+ auto name = rvalue->get_name ();
+
+ if (!name)
+return NULL;
+ return name->c_str ();
+}
diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
index 74e847b2dec..d4094610a16 100644
--- a/gcc/jit/libgccjit.h
+++ b/gcc/jit/libgccjit.h
@@ -2066,6 +2066,10 @@ gcc_jit_lvalue_add_string_attribute (gcc_jit_lvalue *variable,
enum gcc_jit_variable_attribute attribute,
const char* value);
+/* Returns the name of the `rvalue`, if any. Returns NULL otherwise. */
+extern const char *
+gcc_jit_rvalue_get_name (gcc_jit_rvalue *rvalue);
+
#ifdef __cplusplus
}
#endif /* __cplusplus */
diff --git a/gcc/jit/libgccjit.map b/gcc/jit/libgccjit.map
index 99aa5970be1..bbed8024263 100644
--- a/gcc/jit/libgccjit.map
+++ b/gcc/jit/libgccjit.map
@@ -289,3 +289,8 @@ LIBGCCJIT_ABI_27 {
global:
gcc_jit_context_new_sizeof;
} LIBGCCJIT_ABI_26;
+
+LIBGCCJIT_ABI_28 {
+ global:
+gcc_jit_rvalue_get_name;
+} LIBGCCJIT_ABI_27;
diff --git a/gcc/testsuite/jit.dg/test-tls.c b/gcc/testsuite/jit.dg/test-tls.c
index 3b20182ac10..b651eb09b44 100644
--- a/gcc/testsuite/jit.dg/test-tls.c
+++ b/gcc/testsuite/jit.dg/test-tls.c
@@ -28,6 +28,9 @@ create_code (gcc_jit_context *ctxt, void *user_data)
ctxt, NULL, GCC_JIT_GLOBAL_EXPORTED, int_type, "foo");
gcc_jit_lvalue_set_tls_model (foo, GCC_JIT_TLS_MODEL_GLOBAL_DYNAMIC);
+ CHECK_STRING_VALUE (
+gcc_jit_rvalue_get_name (gcc_jit_lvalue_as_rvalue (foo)), "foo");
+
/* Build the test_fn. */
gcc_jit_function *test_fn =
gcc_jit_context_new_function (ctxt, NULL,
--
2.24.1.2762.gfe2e4819b8
