Re: [PATCH] libgccjit: Add support for creating temporary variables
Hi and thanks for the review!
Here's the updated patch.
Le 2024-01-24 à 09 h 54, David Malcolm a écrit :
On Fri, 2024-01-19 at 16:54 -0500, Antoni Boucher wrote:
Hi.
This patch adds a new way to create local variable that won't
generate
debug info: it is to be used for compiler-generated variables.
Thanks for the review.
Thanks for the patch.
diff --git a/gcc/jit/docs/topics/compatibility.rst
b/gcc/jit/docs/topics/compatibility.rst
index cbf5b414d8c..5d62e264a00 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -390,3 +390,12 @@ on functions and variables:
* :func:`gcc_jit_function_add_string_attribute`
* :func:`gcc_jit_function_add_integer_array_attribute`
* :func:`gcc_jit_lvalue_add_string_attribute`
+
+.. _LIBGCCJIT_ABI_27:
+
+``LIBGCCJIT_ABI_27``
+
+``LIBGCCJIT_ABI_27`` covers the addition of a functions to create a new
"functions" -> "function"
+temporary variable:
+
+ * :func:`gcc_jit_function_new_temp`
diff --git a/gcc/jit/docs/topics/functions.rst
b/gcc/jit/docs/topics/functions.rst
index 804605ea939..230caf42466 100644
--- a/gcc/jit/docs/topics/functions.rst
+++ b/gcc/jit/docs/topics/functions.rst
@@ -171,6 +171,26 @@ Functions
underlying string, so it is valid to pass in a pointer to an on-stack
buffer.
+.. function:: gcc_jit_lvalue *\
+ gcc_jit_function_new_temp (gcc_jit_function *func,\
+ gcc_jit_location *loc,\
+ gcc_jit_type *type)
+
+ Create a new local variable within the function, of the given type.
+ This function is similar to :func:`gcc_jit_function_new_local`, but
+ it is to be used for compiler-generated variables (as opposed to
+ user-defined variables in the language to be compiled) and these
+ variables won't show up in the debug info.
+
+ The parameter ``type`` must be non-`void`.
+
+ This entrypoint was added in :ref:`LIBGCCJIT_ABI_26`; you can test
+ for its presence using
The ABI number is inconsistent here (it's 27 above and in the .map
file), but obviously you can fix this when you eventually commit this
based on what the ABI number actually is.
[...snip...]
diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
index 84df6c100e6..cb6b2f66276 100644
--- a/gcc/jit/jit-playback.cc
+++ b/gcc/jit/jit-playback.cc
@@ -31,6 +31,7 @@ along with GCC; see the file COPYING3. If not see
#include "toplev.h"
#include "tree-cfg.h"
#include "convert.h"
+#include "gimple-expr.h"
#include "stor-layout.h"
#include "print-tree.h"
#include "gimplify.h"
@@ -1950,13 +1951,27 @@ new_local (location *loc,
type *type,
const char *name,
const std::vector> &attributes)
+ std::string>> &attributes,
+ bool is_temp)
{
gcc_assert (type);
- gcc_assert (name);
- tree inner = build_decl (UNKNOWN_LOCATION, VAR_DECL,
+ tree inner;
+ if (is_temp)
+ {
+inner = build_decl (UNKNOWN_LOCATION, VAR_DECL,
+ create_tmp_var_name ("JITTMP"),
+ type->as_tree ());
+DECL_ARTIFICIAL (inner) = 1;
+DECL_IGNORED_P (inner) = 1;
+DECL_NAMELESS (inner) = 1;
We could assert that "name" is null in the is_temp branch.
An alternative approach might be to drop "is_temp", and instead make
"name" being null signify that it's a temporary, if you prefer that
approach. Would client code ever want to specify a name prefix for a
temporary?
No, I don't think anyone would want a different prefix.
+ }
+ else
+ {
+gcc_assert (name);
+inner = build_decl (UNKNOWN_LOCATION, VAR_DECL,
get_identifier (name),
type->as_tree ());
+ }
DECL_CONTEXT (inner) = this->m_inner_fndecl;
/* Prepend to BIND_EXPR_VARS: */
[...snip...]
Thanks again for the patch. Looks good to me as-is (apart from the
grammar and ABI number nits), but what do you think of eliminating
"is_temp" in favor of the "name" ptr being null? I think it's your
call.
Dave
From 80ea12ce227b2ac5d5dcd99374532e30a775ecbd Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Thu, 18 Jan 2024 16:54:59 -0500
Subject: [PATCH] libgccjit: Add support for creating temporary variables
gcc/jit/ChangeLog:
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_28): New ABI tag.
* docs/topics/functions.rst: Document gcc_jit_function_new_temp.
* jit-playback.cc (new_local): Add support for temporary
variables.
* jit-recording.cc (recording::function::new_temp): New method.
(recording::local::write_reproducer): Support temporary
variables.
* jit-recording.h (new_temp): New method.
* libgccjit.cc (gcc_jit_function_new_temp):
Re: [PATCH] libgccjit: Add option to allow special characters in function names
Hi and thanks for the review.
I thought it would be a bit weird to have an option to change which
characters are allowed, but I can't think of a better solution.
Here's the updated patch that now allow arbitrary characters.
Le 2024-02-20 à 16 h 05, Iain Sandoe a écrit :
On 20 Feb 2024, at 20:50, David Malcolm wrote:
On Thu, 2024-02-15 at 17:08 -0500, Antoni Boucher wrote:
Hi.
This patch adds a new option to allow special characters like . and $
in function names.
This is useful to allow for mangling using those characters.
Thanks for the review.
Thanks for the patch.
diff --git a/gcc/jit/docs/topics/contexts.rst b/gcc/jit/docs/topics/contexts.rst
index 10a0e50f9f6..4af75ea7418 100644
--- a/gcc/jit/docs/topics/contexts.rst
+++ b/gcc/jit/docs/topics/contexts.rst
@@ -453,6 +453,10 @@ Boolean options
If true, the :type:`gcc_jit_context` will not clean up intermediate files
written to the filesystem, and will display their location on stderr.
+ .. macro:: GCC_JIT_BOOL_OPTION_SPECIAL_CHARS_IN_FUNC_NAMES
+
+ If true, allow special characters like . and $ in function names.
The documentation and the comment in libgccjit.h say:
"allow special characters like . and $ in function names."
and on reading the implementation, the special characters are exactly
'.' and '$'.
The API seems rather arbitrary and inflexible to me; why the choice of
those characters? Presumably those are the ones that Rust's mangling
scheme uses, but do other mangling schemes require other chars?
How about an API for setting the valid chars, something like:
extern void
gcc_jit_context_set_valid_symbol_chars (gcc_jit_context *ctxt,
const char *chars);
to specify the chars that are valid in addition to underscore and
alphanumeric.
In your case you'd call:
gcc_jit_context_set_valid_symbol_chars (ctxt, ".$");
Or is that overkill?
If we ever wanted to support objective-c (NeXT runtime) then we’d need to
be able to support +,-,[,] space and : at least. The interesting thing there is
that most assemblers do not support that either (and the symbols then need
to be quoted into the assembler) .
So, it’s not (IMO) overkill considering at least one potential extension.
Iain
Dave
From 1bd8a95ffd8e30bf3b65a2948f9ebba22e691bd6 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Thu, 15 Feb 2024 17:03:22 -0500
Subject: [PATCH] libgccjit: Add option to allow special characters in function
names
gcc/jit/ChangeLog:
* docs/topics/contexts.rst: Add documentation for new option.
* jit-recording.cc (recording::context::get_str_option): New
method.
* jit-recording.h (get_str_option): New method.
* libgccjit.cc (gcc_jit_context_new_function): Allow special
characters in function names.
* libgccjit.h (enum gcc_jit_str_option): New option.
gcc/testsuite/ChangeLog:
* jit.dg/test-special-chars.c: New test.
---
gcc/jit/docs/topics/contexts.rst | 8 +++--
gcc/jit/jit-recording.cc | 17 --
gcc/jit/jit-recording.h | 3 ++
gcc/jit/libgccjit.cc | 8 +++--
gcc/jit/libgccjit.h | 3 ++
gcc/testsuite/jit.dg/test-special-chars.c | 41 +++
6 files changed, 74 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-special-chars.c
diff --git a/gcc/jit/docs/topics/contexts.rst b/gcc/jit/docs/topics/contexts.rst
index 10a0e50f9f6..e7950cee961 100644
--- a/gcc/jit/docs/topics/contexts.rst
+++ b/gcc/jit/docs/topics/contexts.rst
@@ -317,13 +317,17 @@ String Options
copy of the underlying string, so it is valid to pass in a pointer to
an on-stack buffer.
- There is just one string option specified this way:
-
.. macro:: GCC_JIT_STR_OPTION_PROGNAME
The name of the program, for use as a prefix when printing error
messages to stderr. If `NULL`, or default, "libgccjit.so" is used.
+ .. macro:: GCC_JIT_STR_OPTION_SPECIAL_CHARS_IN_FUNC_NAMES
+
+ Special characters to allow in function names.
+ This string contains all characters that should not be rejected by
+ libgccjit. Ex.: ".$"
+
Boolean options
***
diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc
index 68a2e860c1f..a656b9a0a98 100644
--- a/gcc/jit/jit-recording.cc
+++ b/gcc/jit/jit-recording.cc
@@ -1362,6 +1362,18 @@ recording::context::set_str_option (enum gcc_jit_str_option opt,
log_str_option (opt);
}
+const char*
+recording::context::get_str_option (enum gcc_jit_str_option opt)
+{
+ if (opt < 0 || opt >= GCC_JIT_NUM_STR_OPTIONS)
+{
+ add_error (NULL,
+ "unrecognized (enum gcc_jit_str_option) value: %i", opt);
+ return NULL;
+}
+ return m_str_options[opt];
+}
+
/* Set the given integer option for this context, or add an error if
it's not recognized.
@@ -1703,7 +1715,8 @@ re
Re: Frontend access to target features (was Re: [PATCH] libgccjit: Add ability to get CPU features)
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. 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.
Re: Frontend access to target features (was Re: [PATCH] libgccjit: Add ability to get CPU features)
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
[PATCH] libgccjit: Add ability to get the alignment of a type
Hi.
This patch adds a new API to produce an rvalue representing the
alignment of a type.
Thanks for the review.From 12d8e57ca2313002da42672dc86b167baf812ff3 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Thu, 4 Apr 2024 18:57:07 -0400
Subject: [PATCH] libgccjit: Add ability to get the alignment of a type
gcc/jit/ChangeLog:
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_28): New ABI tag.
* docs/topics/expressions.rst: Document gcc_jit_context_new_alignof.
* jit-playback.cc (new_alignof): New method.
* jit-playback.h: New method.
* jit-recording.cc (recording::context::new_alignof): New
method.
(recording::memento_of_sizeof::replay_into,
recording::memento_of_typeinfo::replay_into,
recording::memento_of_sizeof::make_debug_string,
recording::memento_of_typeinfo::make_debug_string,
recording::memento_of_sizeof::write_reproducer,
recording::memento_of_typeinfo::write_reproducer): Rename.
* jit-recording.h (enum type_info_type): New enum.
(class memento_of_sizeof class memento_of_typeinfo): Rename.
* libgccjit.cc (gcc_jit_context_new_alignof): New function.
* libgccjit.h (gcc_jit_context_new_alignof): New function.
* libgccjit.map: New function.
gcc/testsuite/ChangeLog:
* jit.dg/all-non-failing-tests.h: New test.
* jit.dg/test-alignof.c: New test.
---
gcc/jit/docs/topics/compatibility.rst| 7 ++
gcc/jit/docs/topics/expressions.rst | 14
gcc/jit/jit-playback.cc | 11
gcc/jit/jit-playback.h | 3 +
gcc/jit/jit-recording.cc | 67 +++
gcc/jit/jit-recording.h | 19 --
gcc/jit/libgccjit.cc | 18 +
gcc/jit/libgccjit.h | 13
gcc/jit/libgccjit.map| 5 ++
gcc/testsuite/jit.dg/all-non-failing-tests.h | 10 +++
gcc/testsuite/jit.dg/test-alignof.c | 69
11 files changed, 221 insertions(+), 15 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-alignof.c
diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst
index 9cfb054f653..92c3ed24c89 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -397,3 +397,10 @@ on functions and variables:
``LIBGCCJIT_ABI_27`` covers the addition of
:func:`gcc_jit_context_new_sizeof`
+
+.. _LIBGCCJIT_ABI_28:
+
+``LIBGCCJIT_ABI_28``
+
+``LIBGCCJIT_ABI_28`` covers the addition of
+:func:`gcc_jit_context_new_alignof`
diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst
index c3f4f61eb06..299d3d229df 100644
--- a/gcc/jit/docs/topics/expressions.rst
+++ b/gcc/jit/docs/topics/expressions.rst
@@ -140,6 +140,20 @@ Simple expressions
sizeof (type)
+.. function:: gcc_jit_rvalue *\
+ gcc_jit_context_new_alignof (gcc_jit_context *ctxt, \
+ gcc_jit_type *type)
+
+ Generate an rvalue that is equal to the alignment of ``type``.
+
+ The parameter ``type`` must be non-NULL.
+
+ This is equivalent to this C code:
+
+ .. code-block:: c
+
+ _Alignof (type)
+
Constructor expressions
***
diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
index 6baa838af10..b3f54da24ab 100644
--- a/gcc/jit/jit-playback.cc
+++ b/gcc/jit/jit-playback.cc
@@ -1120,6 +1120,17 @@ new_sizeof (type *type)
/* Construct a playback::rvalue instance (wrapping a tree). */
+playback::rvalue *
+playback::context::
+new_alignof (type *type)
+{
+ int alignment = TYPE_ALIGN (type->as_tree ()) / BITS_PER_UNIT;
+ tree inner = build_int_cst (integer_type_node, alignment);
+ return new rvalue (this, inner);
+}
+
+/* Construct a playback::rvalue instance (wrapping a tree). */
+
playback::rvalue *
playback::context::
new_string_literal (const char *value)
diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
index aa6a086613c..6e97b389cbb 100644
--- a/gcc/jit/jit-playback.h
+++ b/gcc/jit/jit-playback.h
@@ -165,6 +165,9 @@ public:
rvalue *
new_sizeof (type *type);
+ rvalue *
+ new_alignof (type *type);
+
rvalue *
new_string_literal (const char *value);
diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc
index 68a2e860c1f..1121f5e00a8 100644
--- a/gcc/jit/jit-recording.cc
+++ b/gcc/jit/jit-recording.cc
@@ -1077,7 +1077,7 @@ recording::context::new_global_init_rvalue (lvalue *variable,
gbl->set_rvalue_init (init); /* Needed by the global for write dump. */
}
-/* Create a recording::memento_of_sizeof instance and add it
+/* Create a recording::memento_of_typeinfo instance and add it
to this context's list of mementos.
Implements the post-error-checking part of
@@ -1087,7 +1087,22 @@ recording::rvalue *
recording::context::new_sizeof (recording::type *type)
{
recording::rvalue *result =
-new memento_of_sizeof (this, NULL, type
Re: Frontend access to target features (was Re: [PATCH] libgccjit: Add ability to get CPU features)
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 ability to get CPU features
David: Ping. On Tue, 2024-01-30 at 10:50 -0500, Antoni Boucher wrote: > David: I'm unsure what to do here. It seems we cannot find a > reviewer. > Would it help if I show you the code in gccrs that is similar? > Would it help if I ask someone from gccrs to review this code? > > On Sat, 2024-01-20 at 09:50 -0500, Antoni Boucher wrote: > > CC-ing Iain in case they can do the review since it is based on how > > they did it in the D frontend. > > Could you please do the review? > > Thanks! > > > > 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? > > > > > > 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 > > > > > >
Re: [PATCH] libgccjit: Add support for machine-dependent builtins
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] libgccjit: Clear pending_assemble_externals_processed
Hi.
This patch fixes the bug 113842.
I cannot yet add a test with this patch since it requires using
try/catch which is not yet merged in master.
Thanks for the review.
From 71f5f5fa8e68594454d5511b6d0c795bc6a8c37a Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Fri, 26 Jan 2024 11:31:47 -0500
Subject: [PATCH] libgccjit: Clear pending_assemble_externals_processed
Without this patch, code using exception handling will fail the
following assert in the function assemble_external_libcall in varasm.cc:
gcc_assert (!pending_assemble_externals_processed)
gcc/ChangeLog:
PR jit/113842
* toplev.cc (toplev::finalize): Call varasm_cc_finalize.
* varasm.cc (varasm_cc_finalize): New function to clear
pending_assemble_externals_processed.
* varasm.h (varasm_cc_finalize): New function.
---
gcc/toplev.cc | 1 +
gcc/varasm.cc | 8
gcc/varasm.h | 2 ++
3 files changed, 11 insertions(+)
diff --git a/gcc/toplev.cc b/gcc/toplev.cc
index 175d4cd18fa..eca8ba292b4 100644
--- a/gcc/toplev.cc
+++ b/gcc/toplev.cc
@@ -2372,6 +2372,7 @@ toplev::finalize (void)
ira_costs_cc_finalize ();
tree_cc_finalize ();
reginfo_cc_finalize ();
+ varasm_cc_finalize ();
/* save_decoded_options uses opts_obstack, so these must
be cleaned up together. */
diff --git a/gcc/varasm.cc b/gcc/varasm.cc
index fa17eff551e..2aa46b498e4 100644
--- a/gcc/varasm.cc
+++ b/gcc/varasm.cc
@@ -8661,4 +8661,12 @@ handle_vtv_comdat_section (section *sect, const_tree decl ATTRIBUTE_UNUSED)
switch_to_comdat_section(sect, DECL_NAME (decl));
}
+void
+varasm_cc_finalize (void)
+{
+#ifdef ASM_OUTPUT_EXTERNAL
+ pending_assemble_externals_processed = false;
+#endif
+}
+
#include "gt-varasm.h"
diff --git a/gcc/varasm.h b/gcc/varasm.h
index d9311dc370b..26e6fab8601 100644
--- a/gcc/varasm.h
+++ b/gcc/varasm.h
@@ -81,4 +81,6 @@ extern rtx assemble_trampoline_template (void);
extern void switch_to_comdat_section (section *, tree);
+extern void varasm_cc_finalize (void);
+
#endif // GCC_VARASM_H
--
2.43.0
Re: [PATCH] libgccjit: Add ability to get CPU features
David: Ping. On Tue, 2024-02-06 at 07:54 -0500, Antoni Boucher wrote: > David: Ping. > > On Tue, 2024-01-30 at 10:50 -0500, Antoni Boucher wrote: > > David: I'm unsure what to do here. It seems we cannot find a > > reviewer. > > Would it help if I show you the code in gccrs that is similar? > > Would it help if I ask someone from gccrs to review this code? > > > > On Sat, 2024-01-20 at 09:50 -0500, Antoni Boucher wrote: > > > CC-ing Iain in case they can do the review since it is based on > > > how > > > they did it in the D frontend. > > > Could you please do the review? > > > Thanks! > > > > > > 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? > > > > > > > > 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 > > > > > > > > > >
Re: [PATCH] libgccjit: Add support for machine-dependent builtins
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. > > > > > > > > > >
Re: [PATCH] libgccjit: Clear pending_assemble_externals_processed
David: Ping. On Thu, 2024-02-08 at 17:09 -0500, Antoni Boucher wrote: > Hi. > This patch fixes the bug 113842. > I cannot yet add a test with this patch since it requires using > try/catch which is not yet merged in master. > Thanks for the review.
Re: [PATCH] libgccjit: Fix ira cost segfault
This patch is indeed not necessary anymore.
On Wed, 2024-01-10 at 09:32 -0500, David Malcolm wrote:
> On Wed, 2024-01-10 at 09:30 -0500, David Malcolm wrote:
> > On Thu, 2023-11-16 at 17:28 -0500, Antoni Boucher wrote:
> > > Hi.
> > > This patch fixes a segfault that happens when compiling librsvg
> > > (more
> > > specifically its dependency aho-corasick) with rustc_codegen_gcc
> > > (bug
> > > 112575).
> > > I was not able to create a reproducer for this bug: I'm assuming
> > > I
> > > might need to concat all the reproducers together in the same
> > > file
> > > in
> > > order to be able to reproduce the issue.
> >
> > Hi Antoni
> >
> > Thanks for the patch; sorry for missing it before.
> >
> > CCing the i386 maintainers; quoting the patch here to give them
> > context:
>
> Oops; actually adding them to the CC this time; sorry.
>
> >
> > > From e0f4f51682266bc9f507afdb64908ed3695a2f5e Mon Sep 17 00:00:00
> > > 2001
> > > From: Antoni Boucher
> > > Date: Thu, 2 Nov 2023 17:18:35 -0400
> > > Subject: [PATCH] libgccjit: Fix ira cost segfault
> > >
> > > gcc/ChangeLog:
> > > PR jit/112575
> > > * config/i386/i386-options.cc
> > > (ix86_option_override_internal):
> > > Cleanup target_attribute_cache.
> > > ---
> > > gcc/config/i386/i386-options.cc | 6 ++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/gcc/config/i386/i386-options.cc
> > > b/gcc/config/i386/i386-options.cc
> > > index df7d24352d1..f596c0fb53c 100644
> > > --- a/gcc/config/i386/i386-options.cc
> > > +++ b/gcc/config/i386/i386-options.cc
> > > @@ -3070,6 +3070,12 @@ ix86_option_override_internal (bool
> > > main_args_p,
> > > = opts->x_flag_unsafe_math_optimizations;
> > > target_option_default_node = target_option_current_node
> > > = build_target_option_node (opts, opts_set);
> > > + /* TODO: check if this is the correct location. It should
> > > probably be in
> > > + some finalizer function, but I don't
> > > + know if there's one. */
> > > + target_attribute_cache[0] = NULL;
> > > + target_attribute_cache[1] = NULL;
> > > + target_attribute_cache[2] = NULL;
> > > }
> > >
> > > if (opts->x_flag_cf_protection != CF_NONE)
> > > --
> > > 2.42.1
> > >
> >
> > Presumably this happens when there's more than one in-process
> > invocation of the compiler code (via libgccjit).
> >
> > >
> > > I'm also not sure I put the cleanup in the correct location.
> > > Is there any finalizer function for target specific code?
> >
> > As you know (but the i386 maintainers might not), to allow multiple
> > in-
> > process invocations of the compiler code (for libgccjit) we've been
> > putting code to reset global state in various
> > {filename_cc}_finalize
> > functions called from toplev::finalize (see the end of toplev.cc).
> >
> > There doesn't seem to be any kind of hook at this time for calling
> > target-specific cleanups from toplev::finalize.
> >
> > However, as of r14-4003-geaa8e8541349df ggc_common_finalize zeroes
> > everything marked with GTY. The array target_attribute_cache does
> > have
> > a GTY marking, so perhaps as of that commit this patch isn't
> > necessary?
> >
> > Otherwise, if special-casing this is required, sorry: I'm not
> > familiar
> > enough with i386-options.cc to know if the patch is correct.
> >
> > >
> > > Thanks to fix this issue.
> >
> > Dave
>
[PATCH] libgccjit: Add count zeroes builtins to ensure_optimization_builtins_exist
Hi. This patch adds some missing builtins that can be generated by optimizations. I'm not sure how to add a test for this one. Do you know the C code that can be optimized to a builtin_clz? Thanks for the review. From 578cb40bd333abf57e5b3b08d3453bdcf7ad80b5 Mon Sep 17 00:00:00 2001 From: Antoni Boucher Date: Thu, 8 Feb 2024 21:48:27 -0500 Subject: [PATCH] libgccjit: Add count zeroes builtins to ensure_optimization_builtins_exist gcc/jit/ChangeLog: * jit-builtins.cc (ensure_optimization_builtins_exist): Add missing builtins. --- gcc/jit/jit-builtins.cc | 6 ++ 1 file changed, 6 insertions(+) diff --git a/gcc/jit/jit-builtins.cc b/gcc/jit/jit-builtins.cc index e0bb24738dd..0c13c8db586 100644 --- a/gcc/jit/jit-builtins.cc +++ b/gcc/jit/jit-builtins.cc @@ -612,6 +612,12 @@ builtins_manager::ensure_optimization_builtins_exist () (void)get_builtin_function_by_id (BUILT_IN_POPCOUNT); (void)get_builtin_function_by_id (BUILT_IN_POPCOUNTL); (void)get_builtin_function_by_id (BUILT_IN_POPCOUNTLL); + (void)get_builtin_function_by_id (BUILT_IN_CLZ); + (void)get_builtin_function_by_id (BUILT_IN_CTZ); + (void)get_builtin_function_by_id (BUILT_IN_CLZL); + (void)get_builtin_function_by_id (BUILT_IN_CTZL); + (void)get_builtin_function_by_id (BUILT_IN_CLZLL); + (void)get_builtin_function_by_id (BUILT_IN_CTZLL); } /* Playback support. */ -- 2.43.0
Re: [PATCH] libgccjit: Clear pending_assemble_externals_processed
It's OK to merge even though it touches files outside of the jit directory and we're in stage 4? Or do we need some kind of approval? On Thu, 2024-02-15 at 10:35 -0500, David Malcolm wrote: > On Thu, 2024-02-08 at 17:09 -0500, Antoni Boucher wrote: > > Hi. > > This patch fixes the bug 113842. > > I cannot yet add a test with this patch since it requires using > > try/catch which is not yet merged in master. > > Thanks for the review. > > Thanks; patch looks good for trunk, assuming you've tested it on a > target that defines ASM_OUTPUT_EXTERNAL. > > Dave >
[PATCH] libgccjit: Do not treat warnings as errors
Hi.
This patch makes libgccjit treat warnings as warnings instead of errors
in order to continue the compilation when there are warnings.
One thing I'm not sure what to do about is that warnings will keep
overriding first_error as long as there are no errors.
What behavior should we have here?
Thanks for the review.
From 755c72478dc5ba8f6920c9ca27559f5d426a41f5 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Mon, 12 Feb 2024 19:49:43 -0400
Subject: [PATCH] libgccjit: Do not treat warnings as errors
gcc/jit/ChangeLog:
* jit-playback.cc (add_error, add_error_va): Send DK_ERROR to
add_error_va.
(add_diagnostic): Call add_diagnostic instead of add_error.
* jit-recording.cc (DEFINE_DIAGNOSTIC_KIND): New define.
(recording::context::add_diagnostic): New function.
(recording::context::add_error): Send DK_ERROR to add_error_va.
(recording::context::add_error_va): New parameter diagnostic_kind.
* jit-recording.h (add_diagnostic): New function.
(add_error_va): New parameter diagnostic_kind.
* libgccjit.cc (jit_error): Send DK_ERROR to add_error_va.
gcc/testsuite/ChangeLog:
* jit.dg/test-error-array-bounds.c: Fix test.
---
gcc/jit/jit-playback.cc | 13 ---
gcc/jit/jit-recording.cc | 35 +++
gcc/jit/jit-recording.h | 11 --
gcc/jit/libgccjit.cc | 2 +-
.../jit.dg/test-error-array-bounds.c | 10 ++
5 files changed, 48 insertions(+), 23 deletions(-)
diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
index b49bc94442a..6b0522d6f88 100644
--- a/gcc/jit/jit-playback.cc
+++ b/gcc/jit/jit-playback.cc
@@ -3941,7 +3941,7 @@ add_error (location *loc, const char *fmt, ...)
va_list ap;
va_start (ap, fmt);
m_recording_ctxt->add_error_va (loc ? loc->get_recording_loc () : NULL,
- fmt, ap);
+ DK_ERROR, fmt, ap);
va_end (ap);
}
@@ -3953,13 +3953,12 @@ playback::context::
add_error_va (location *loc, const char *fmt, va_list ap)
{
m_recording_ctxt->add_error_va (loc ? loc->get_recording_loc () : NULL,
- fmt, ap);
+ DK_ERROR, fmt, ap);
}
-/* Report a diagnostic up to the jit context as an error,
- so that the compilation is treated as a failure.
- For now, any kind of diagnostic is treated as an error by the jit
- API. */
+/* Report a diagnostic up to the jit context, so that the
+ compilation is treated as a failure if the diagnostic
+ is an error. */
void
playback::context::
@@ -3989,7 +3988,7 @@ add_diagnostic (diagnostic_context *diag_context,
false);
}
- m_recording_ctxt->add_error (rec_loc, "%s", text);
+ m_recording_ctxt->add_diagnostic (rec_loc, diagnostic.kind, "%s", text);
pp_clear_output_area (pp);
}
diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc
index 4b8e40ec64c..83a8b299b91 100644
--- a/gcc/jit/jit-recording.cc
+++ b/gcc/jit/jit-recording.cc
@@ -31,6 +31,14 @@ along with GCC; see the file COPYING3. If not see
#include "jit-playback.h"
#include
+/* This comes from diagnostic.cc. */
+static const char *const diagnostic_kind_text[] = {
+#define DEFINE_DIAGNOSTIC_KIND(K, T, C) (T),
+#include "diagnostic.def"
+#undef DEFINE_DIAGNOSTIC_KIND
+ "must-not-happen"
+};
+
namespace gcc {
namespace jit {
@@ -1664,12 +1672,22 @@ recording::context::get_target_info ()
/* Format the given error using printf's conventions, print
it to stderr, and add it to the context. */
+void
+recording::context::add_diagnostic (location *loc, diagnostic_t diagnostic_kind,
+const char *fmt, ...)
+{
+ va_list ap;
+ va_start (ap, fmt);
+ add_error_va (loc, diagnostic_kind, fmt, ap);
+ va_end (ap);
+}
+
void
recording::context::add_error (location *loc, const char *fmt, ...)
{
va_list ap;
va_start (ap, fmt);
- add_error_va (loc, fmt, ap);
+ add_error_va (loc, DK_ERROR, fmt, ap);
va_end (ap);
}
@@ -1677,7 +1695,8 @@ recording::context::add_error (location *loc, const char *fmt, ...)
it to stderr, and add it to the context. */
void
-recording::context::add_error_va (location *loc, const char *fmt, va_list ap)
+recording::context::add_error_va (location *loc, diagnostic_t diagnostic_kind,
+ const char *fmt, va_list ap)
{
int len;
char *malloced_msg;
@@ -1698,7 +1717,8 @@ recording::context::add_error_va (location *loc, const char *fmt, va_list ap)
has_ownership = true;
}
if (get_logger ())
-get_logger ()->log ("error %i: %s", m_error_count, errmsg);
+get_logger ()->log ("%s %i: %s", diagnostic_kind_text[diagnostic_kind],
+ m_error_count, errmsg);
const char *ctxt_progname =
get_str_option (GCC_JIT_STR_OPTION_PROGNAME);
@@ -1710,13 +1730,15 @@ recording::context::add_error_va (location *loc, const char *fmt, va_list ap)
if (print_errors_to_stderr)
{
if (loc)
- fprintf (stderr,
[PATCH] libgccjit: Add option to allow special characters in function names
Hi.
This patch adds a new option to allow special characters like . and $
in function names.
This is useful to allow for mangling using those characters.
Thanks for the review.
From 89a92e561ca83a622dcc22a6500ca2b17551edb1 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Thu, 15 Feb 2024 17:03:22 -0500
Subject: [PATCH] libgccjit: Add option to allow special characters in function
names
gcc/jit/ChangeLog:
* docs/topics/contexts.rst: Add documentation for new option.
* jit-recording.cc (recording::context::get_bool_option): New
method.
* jit-recording.h (get_bool_option): New method.
* libgccjit.cc (gcc_jit_context_new_function): Allow special
characters in function names.
* libgccjit.h (enum gcc_jit_bool_option): New option.
gcc/testsuite/ChangeLog:
* jit.dg/test-special-chars.c: New test.
---
gcc/jit/docs/topics/contexts.rst | 4 +++
gcc/jit/jit-recording.cc | 15 -
gcc/jit/jit-recording.h | 3 ++
gcc/jit/libgccjit.cc | 8 +++--
gcc/jit/libgccjit.h | 3 ++
gcc/testsuite/jit.dg/test-special-chars.c | 41 +++
6 files changed, 71 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-special-chars.c
diff --git a/gcc/jit/docs/topics/contexts.rst b/gcc/jit/docs/topics/contexts.rst
index 10a0e50f9f6..4af75ea7418 100644
--- a/gcc/jit/docs/topics/contexts.rst
+++ b/gcc/jit/docs/topics/contexts.rst
@@ -453,6 +453,10 @@ Boolean options
If true, the :type:`gcc_jit_context` will not clean up intermediate files
written to the filesystem, and will display their location on stderr.
+ .. macro:: GCC_JIT_BOOL_OPTION_SPECIAL_CHARS_IN_FUNC_NAMES
+
+ If true, allow special characters like . and $ in function names.
+
.. function:: void \
gcc_jit_context_set_bool_allow_unreachable_blocks (gcc_jit_context *ctxt, \
int bool_value)
diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc
index 83a8b299b91..962c37ee87e 100644
--- a/gcc/jit/jit-recording.cc
+++ b/gcc/jit/jit-recording.cc
@@ -1511,6 +1511,18 @@ recording::context::set_bool_option (enum gcc_jit_bool_option opt,
log_bool_option (opt);
}
+int
+recording::context::get_bool_option (enum gcc_jit_bool_option opt)
+{
+ if (opt < 0 || opt >= GCC_JIT_NUM_BOOL_OPTIONS)
+{
+ add_error (NULL,
+ "unrecognized (enum gcc_jit_bool_option) value: %i", opt);
+ return 0;
+}
+ return m_bool_options[opt];
+}
+
void
recording::context::set_inner_bool_option (enum inner_bool_option inner_opt,
int value)
@@ -1863,7 +1875,8 @@ static const char * const
"GCC_JIT_BOOL_OPTION_DUMP_SUMMARY",
"GCC_JIT_BOOL_OPTION_DUMP_EVERYTHING",
"GCC_JIT_BOOL_OPTION_SELFCHECK_GC",
- "GCC_JIT_BOOL_OPTION_KEEP_INTERMEDIATES"
+ "GCC_JIT_BOOL_OPTION_KEEP_INTERMEDIATES",
+ "GCC_JIT_BOOL_OPTION_SPECIAL_CHARS_IN_FUNC_NAMES",
};
static const char * const
diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
index 4833b2d3f52..377b60c662c 100644
--- a/gcc/jit/jit-recording.h
+++ b/gcc/jit/jit-recording.h
@@ -267,6 +267,9 @@ public:
set_bool_option (enum gcc_jit_bool_option opt,
int value);
+ int
+ get_bool_option (enum gcc_jit_bool_option opt);
+
void
set_inner_bool_option (enum inner_bool_option inner_opt,
int value);
diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
index 5a1308b2b8c..3c5ff5a2a59 100644
--- a/gcc/jit/libgccjit.cc
+++ b/gcc/jit/libgccjit.cc
@@ -1222,10 +1222,13 @@ gcc_jit_context_new_function (gcc_jit_context *ctxt,
Eventually we'll need some way to interact with e.g. C++ name
mangling. */
{
+int special_chars_allowed
+ = ctxt->get_bool_option (GCC_JIT_BOOL_OPTION_SPECIAL_CHARS_IN_FUNC_NAMES);
/* Leading char: */
char ch = *name;
RETURN_NULL_IF_FAIL_PRINTF2 (
- ISALPHA (ch) || ch == '_',
+ ISALPHA (ch) || ch == '_' || (special_chars_allowed
+ && (ch == '.' || ch == '$')),
ctxt, loc,
"name \"%s\" contains invalid character: '%c'",
name, ch);
@@ -1233,7 +1236,8 @@ gcc_jit_context_new_function (gcc_jit_context *ctxt,
for (const char *ptr = name + 1; (ch = *ptr); ptr++)
{
RETURN_NULL_IF_FAIL_PRINTF2 (
- ISALNUM (ch) || ch == '_',
+ ISALNUM (ch) || ch == '_' || (special_chars_allowed
+ && (ch == '.' || ch == '$')),
ctxt, loc,
"name \"%s\" contains invalid character: '%c'",
name, ch);
diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
index d45b767c262..694f45f34e5 100644
--- a/gcc/jit/libgccjit.h
+++ b/gcc/jit/libgccjit.h
@@ -244,6 +244,9 @@ enum gcc_jit_bool_option
their location on stderr. */
GCC_JIT_BOOL_OPTION_KEEP_I
Re: [PATCH] libgccjit: Add type checks in gcc_jit_block_add_assignment_op
David: Ping. On Thu, 2023-12-21 at 08:36 -0500, Antoni Boucher wrote: > Hi. > Here's the updated patch. > Thanks. > > On Thu, 2023-12-07 at 20:15 -0500, David Malcolm wrote: > > On Thu, 2023-12-07 at 17:34 -0500, Antoni Boucher wrote: > > > Hi. > > > This patch adds checks gcc_jit_block_add_assignment_op to make > > > sure > > > it > > > is only ever called on numeric types. > > > > > > With the previous patch, this might require a change to also > > > allow > > > vector types here. > > > > > > Thanks for the review. > > > > Thanks for the patch. > > > > [...snip...] > > > > > @@ -2890,6 +2900,17 @@ gcc_jit_block_add_assignment_op > > > (gcc_jit_block *block, > > > lvalue->get_type ()->get_debug_string (), > > > rvalue->get_debug_string (), > > > rvalue->get_type ()->get_debug_string ()); > > > + // TODO: check if it is a numeric vector? > > > + RETURN_IF_FAIL_PRINTF3 ( > > > + lvalue->get_type ()->is_numeric () && rvalue->get_type ()- > > > > is_numeric (), ctxt, loc, > > > + "gcc_jit_block_add_assignment_op %s has non-numeric lvalue > > > %s > > > (type: %s)", > > > + gcc::jit::binary_op_reproducer_strings[op], > > > + lvalue->get_debug_string (), lvalue->get_type ()- > > > > get_debug_string ()); > > > > The condition being tested here should probably just be: > > > > lvalue->get_type ()->is_numeric () > > > > since otherwise if the lvalue's type is numeric and the rvalue's > > type > > fails to be, then the user would incorrectly get a message about > > the > > lvalue. > > > > > + RETURN_IF_FAIL_PRINTF3 ( > > > + rvalue->get_type ()->is_numeric () && rvalue->get_type ()- > > > > is_numeric (), ctxt, loc, > > > + "gcc_jit_block_add_assignment_op %s has non-numeric rvalue > > > %s > > > (type: %s)", > > > + gcc::jit::binary_op_reproducer_strings[op], > > > + rvalue->get_debug_string (), rvalue->get_type ()- > > > > get_debug_string ()); > > > > The condition being tested here seems to have a redundant repeated: > > && rvalue->get_type ()->is_numeric () > > > > Am I missing something, or is that a typo? > > > > [...snip...] > > > > The patch is OK otherwise. > > > > Thanks > > Dave > > > > > > >
Re: [PATCH] libgccjit: Add vector permutation and vector access operations
David: Ping. On Fri, 2024-01-19 at 15:21 -0500, Antoni Boucher wrote: > David: Ping. > > On Thu, 2023-11-30 at 17:16 -0500, Antoni Boucher wrote: > > All of these are fixed in this new patch. > > Thanks for the review. > > > > On Mon, 2023-11-20 at 18:05 -0500, David Malcolm wrote: > > > On Fri, 2023-11-17 at 17:36 -0500, Antoni Boucher wrote: > > > > Hi. > > > > This patch adds a vector permutation and vector access > > > > operations > > > > (bug > > > > 112602). > > > > > > > > This was split from this patch: > > > > https://gcc.gnu.org/pipermail/jit/2023q1/001606.html > > > > > > > > > > Thanks for the patch. > > > > > > Overall, looks good, but 3 minor nitpicks: > > > > > > [...snip...] > > > > > > > diff --git a/gcc/jit/docs/topics/compatibility.rst > > > > b/gcc/jit/docs/topics/compatibility.rst > > > > index ebede440ee4..a764e3968d1 100644 > > > > --- a/gcc/jit/docs/topics/compatibility.rst > > > > +++ b/gcc/jit/docs/topics/compatibility.rst > > > > @@ -378,3 +378,13 @@ alignment of a variable: > > > > > > > > ``LIBGCCJIT_ABI_25`` covers the addition of > > > > :func:`gcc_jit_type_get_restrict` > > > > + > > > > + > > > > +.. _LIBGCCJIT_ABI_26: > > > > + > > > > +``LIBGCCJIT_ABI_26`` > > > > + > > > > +``LIBGCCJIT_ABI_26`` covers the addition of functions to > > > > manipulate vectors: > > > > + > > > > + * :func:`gcc_jit_context_new_rvalue_vector_perm` > > > > + * :func:`gcc_jit_context_new_vector_access` > > > > diff --git a/gcc/jit/docs/topics/expressions.rst > > > > b/gcc/jit/docs/topics/expressions.rst > > > > index 42cfee36302..4a45aa13f5c 100644 > > > > --- a/gcc/jit/docs/topics/expressions.rst > > > > +++ b/gcc/jit/docs/topics/expressions.rst > > > > @@ -295,6 +295,35 @@ Vector expressions > > > > > > > > #ifdef > > > > LIBGCCJIT_HAVE_gcc_jit_context_new_rvalue_from_vector > > > > > > > > +.. function:: gcc_jit_rvalue * \ > > > > + gcc_jit_context_new_rvalue_vector_perm > > > > (gcc_jit_context *ctxt, \ > > > > + > > > > gcc_jit_location *loc, \ > > > > + > > > > gcc_jit_rvalue *elements1, \ > > > > + > > > > gcc_jit_rvalue *elements2, \ > > > > + > > > > gcc_jit_rvalue *mask); > > > > + > > > > + Build a permutation of two vectors. > > > > + > > > > + "elements1" and "elements2" should have the same type. > > > > + The length of "mask" and "elements1" should be the same. > > > > + The element type of "mask" should be integral. > > > > + The size of the element type of "mask" and "elements1" > > > > should > > > > be the same. > > > > + > > > > + This entrypoint was added in :ref:`LIBGCCJIT_ABI_25`; you > > > > can > > > > test for > > > ^^ > > > Should be 26 > > > > > > [...snip...] > > > > > > > Unary Operations > > > > > > > > > > > > @@ -1020,3 +1049,27 @@ Field access is provided separately for > > > > both > > > > lvalues and rvalues. > > > > PTR[INDEX] > > > > > > > > in C (or, indeed, to ``PTR + INDEX``). > > > > + > > > > +.. function:: gcc_jit_lvalue *\ > > > > + gcc_jit_context_new_vector_access > > > > (gcc_jit_context > > > > *ctxt,\ > > > > + > > > > gcc_jit_location > > > > *loc,\ > > > > + > > > > gcc_jit_rvalue > > > > *vector,\ > > > > + > > > > gcc_jit_rvalue > > > > *index)
Re: [PATCH] libgccjit: Allow sending a const pointer as argument
David: Ping. On Fri, 2024-01-19 at 15:59 -0500, Antoni Boucher wrote: > David: Ping. > > On Thu, 2023-12-21 at 11:59 -0500, Antoni Boucher wrote: > > Hi. > > This patch adds the ability to send const pointer as argument to a > > function. > > Thanks for the review. >
Re: [PATCH] libgccjit: Fix float playback for cross-compilation
David: Ping. On Thu, 2024-01-25 at 16:04 -0500, Antoni Boucher wrote: > Thanks for the review! > > On Wed, 2024-01-24 at 13:10 -0500, David Malcolm wrote: > > On Thu, 2024-01-11 at 18:42 -0500, Antoni Boucher wrote: > > > Hi. > > > This patch fixes the bug 113343. > > > I'm wondering if there's a better solution than using mpfr. > > > The only other solution I found is real_from_string, but that > > > seems > > > overkill to convert the number to a string. > > > I could not find a better way to create a real value from a host > > > double. > > > > I took a look, and I don't see a better way; it seems weird to go > > through a string stage. Ideally there would be a > > real_from_host_double, but I don't see one. > > > > Is there a cross-platform way to directly access the representation > > of > > a host double? > > I have no idea. > > > > > > If there's no solution, do we lose some precision by using mpfr? > > > Running Rust's core library tests, there was a difference of one > > > decimal, so I'm wondering if there's some lost precision, or if > > > it's > > > just because those tests don't work on m68k which was my test > > > target. > > > > Sorry, can you clarify what you mean by "a difference of one > > decimal" > > above? > > Let's say the Rust core tests expected the value "1.23456789", it > instead got the value "1.2345678" (e.g. without the last decimal). > Not sure if this is expected. > Everything works fine for x86-64; this just happened for m68k which > is > not well supported for now in Rust, so that might just be that the > test > doesn't work on this platform. > > > > > > Also, I'm not sure how to write a test this fix. Any ideas? > > > > I think we don't need cross-compilation-specific tests, we should > > just > > use and/or extend the existing coverage for > > gcc_jit_context_new_rvalue_from_double e.g. in test-constants.c and > > test-types.c > > > > We probably should have test coverage for "awkward" values; we > > already > > have coverage for DBL_MIN and DBL_MAX, but we don't yet have test > > coverage for: > > * quiet/signaling NaN > > * +ve/-ve inf > > * -ve zero > > Is this something you would want for this patch? > > > > > Thanks > > Dave > > >
Re: [PATCH] libgccjit: Add gcc_jit_global_set_readonly
David: Ping. On Wed, 2024-01-24 at 10:36 -0500, Antoni Boucher wrote: > Yes, it is for a use case inside of rustc_codegen_gcc. > The compiler is structured in a way where we don't know if a global > variable might be constant when it is created. > > On Wed, 2024-01-24 at 10:09 -0500, David Malcolm wrote: > > On Fri, 2024-01-19 at 16:57 -0500, Antoni Boucher wrote: > > > Hi. > > > This patch adds a new API gcc_jit_global_set_readonly: it's > > > equivalent > > > to having a const global variable, but it is useful in the case > > > of > > > complex compilers where it is not convenient to use const. > > > Thanks for the review. > > > > Hi Antoni; thanks for the patch. > > > > Can you give an example of where/why this might be used? > > Presumably this is motivated by a use case you had inside the rustc > > backend? > > > > Thanks > > Dave > > >
Re: [PATCH] libgccjit: Add support for the type bfloat16
Thanks for the review.
Here's the updated patch.
On Fri, 2023-12-01 at 12:45 -0500, David Malcolm wrote:
> On Thu, 2023-11-16 at 17:20 -0500, Antoni Boucher wrote:
> > I forgot to attach the patch.
> >
> > On Thu, 2023-11-16 at 17:19 -0500, Antoni Boucher wrote:
> > > Hi.
> > > This patch adds the support for the type bfloat16 (bug 112574).
> > >
> > > This was asked to be splitted from a another patch sent here:
> > > https://gcc.gnu.org/pipermail/jit/2023q1/001607.html
> > >
> > > Thanks for the review.
> >
>
> Thanks for the patch.
>
> > diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
> > index 18cc4da25b8..7e1c97a4638 100644
> > --- a/gcc/jit/jit-playback.cc
> > +++ b/gcc/jit/jit-playback.cc
> > @@ -280,6 +280,8 @@ get_tree_node_for_type (enum gcc_jit_types
> > type_)
> >
> > case GCC_JIT_TYPE_FLOAT:
> > return float_type_node;
> > + case GCC_JIT_TYPE_BFLOAT16:
> > + return bfloat16_type_node;
>
> The code to create bfloat16_type_node (in build_common_tree_nodes) is
> guarded by #ifdef HAVE_BFmode, so we should probably have a test for
> this in case GCC_JIT_TYPE_BFLOAT16 to at least add an error message
> when it's NULL_TREE, rather than silently returning NULL_TREE and
> crashing.
>
> [...]
>
> > diff --git a/gcc/testsuite/jit.dg/test-bfloat16.c
> > b/gcc/testsuite/jit.dg/test-bfloat16.c
> > new file mode 100644
> > index 000..6aed3920351
> > --- /dev/null
> > +++ b/gcc/testsuite/jit.dg/test-bfloat16.c
> > @@ -0,0 +1,37 @@
> > +/* { dg-do compile { target x86_64-*-* } } */
> > +
> > +#include
> > +#include
> > +
> > +#include "libgccjit.h"
> > +
> > +/* We don't want set_options() in harness.h to set -O3 so our
> > little local
> > + is optimized away. */
> > +#define TEST_ESCHEWS_SET_OPTIONS
> > +static void set_options (gcc_jit_context *ctxt, const char *argv0)
> > +{
> > +}
>
>
> Please add a comment to all-non-failing-tests.h noting the exclusion
> of
> this test case from the array.
>
> [...]
>
> > diff --git a/gcc/testsuite/jit.dg/test-types.c
> > b/gcc/testsuite/jit.dg/test-types.c
> > index a01944e35fa..9e7c4f3e046 100644
> > --- a/gcc/testsuite/jit.dg/test-types.c
> > +++ b/gcc/testsuite/jit.dg/test-types.c
> > @@ -1,3 +1,4 @@
> > +#include
> > #include
> > #include
> > #include
> > @@ -492,4 +493,5 @@ verify_code (gcc_jit_context *ctxt,
> > gcc_jit_result *result)
> >
> > CHECK_VALUE (gcc_jit_type_get_size (gcc_jit_context_get_type
> > (ctxt, GCC_JIT_TYPE_FLOAT)), sizeof (float));
> > CHECK_VALUE (gcc_jit_type_get_size (gcc_jit_context_get_type
> > (ctxt, GCC_JIT_TYPE_DOUBLE)), sizeof (double));
> > + CHECK_VALUE (gcc_jit_type_get_size (gcc_jit_context_get_type
> > (ctxt, GCC_JIT_TYPE_BFLOAT16)), sizeof (__bfloat16));
>
>
> This is only going to work on targets which #ifdef HAVE_BFmode, so
> this
> CHECK_VALUE needs to be conditionalized somehow, to avoid having
> this,
> test-combination, and test-threads from bailing out early on targets
> without BFmode.
>
> Dave
>
From 3b31bca3a1144a5fa4dc34e402ad3287ccca84dd Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Thu, 16 Nov 2023 10:59:22 -0500
Subject: [PATCH] libgccjit: Add support for the type bfloat16
gcc/jit/ChangeLog:
PR jit/112574
* docs/topics/types.rst: Document GCC_JIT_TYPE_BFLOAT16.
* jit-common.h: Update NUM_GCC_JIT_TYPES.
* jit-playback.cc (get_tree_node_for_type): Support bfloat16.
* jit-recording.cc (recording::memento_of_get_type::get_size,
recording::memento_of_get_type::dereference,
recording::memento_of_get_type::is_int,
recording::memento_of_get_type::is_signed,
recording::memento_of_get_type::is_float,
recording::memento_of_get_type::is_bool): Support bfloat16.
* libgccjit.h (enum gcc_jit_types): Add GCC_JIT_TYPE_BFLOAT16.
gcc/testsuite/ChangeLog:
PR jit/112574
* jit.dg/all-non-failing-tests.h: New test test-bfloat16.c.
* jit.dg/test-types.c: Test GCC_JIT_TYPE_BFLOAT16.
* jit.dg/test-bfloat16.c: New test.
---
gcc/jit/docs/topics/types.rst| 2 ++
gcc/jit/jit-common.h | 2 +-
gcc/jit/jit-playback.cc | 6
gcc/jit/jit-recording.cc | 11 ++
gcc/jit/libgccjit.h | 4 ++-
gcc/testsuite/jit.dg/all-non-failing-tests.h | 3 ++
gcc/testsuite/jit.dg/test-bfloat16.c | 37
gcc/testsuite/jit.dg/test-types.c| 4 +++
8 files changed, 67 insertions(+
Re: [PATCH] libgccjit: Fix get_size of size_t
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? 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 >
Re: [PATCH] libgccjit: Make new_array_type take unsigned long
Thanks for the review.
Here's the updated patch.
On Thu, 2023-12-07 at 20:04 -0500, David Malcolm wrote:
> On Thu, 2023-12-07 at 17:29 -0500, Antoni Boucher wrote:
> > Hi.
> > This patches update gcc_jit_context_new_array_type to take the size
> > as
> > an unsigned long instead of a int, to allow creating bigger array
> > types.
> >
> > I haven't written the ChangeLog yet because I wasn't sure it's
> > allowed
> > to change the type of a function like that.
> > If it isn't, what would you suggest?
>
> We've kept ABI compatibility all the way back to the version in GCC
> 5,
> so it seems a shame to break ABI.
>
> How about a new API entrypoint:
> gcc_jit_context_new_array_type_unsigned_long
> whilst keeping the old one.
>
> Then everything internally can use "unsigned long"; we just keep the
> old entrypoint accepting int (which internally promotes the arg to
> unsigned long, if positive, sharing all the implementation).
>
> Alternatively, I think there may be a way to do this with symbol
> versioning:
> https://gcc.gnu.org/wiki/SymbolVersioning
> see e.g. Section 3.7 of Ulrich Drepper's "How To Write Shared
> Libraries", but I'm a bit wary of cross-platform compatibility with
> that.
>
> Dave
>
>
From 4886f05909b0770a673f220a8957d0104d5014d3 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sat, 4 Mar 2023 00:44:49 -0500
Subject: [PATCH] libgccjit: Make new_array_type take unsigned long
gcc/jit/ChangeLog:
* jit-playback.cc (new_array_type): Change num_elements type to
unsigned long.
* jit-playback.h (new_array_type): Change num_elements type to
unsigned long.
* jit-recording.cc (recording::context::new_array_type): Change
num_elements type to unsigned long.
(recording::array_type::make_debug_string): Use unsigned long
format.
(recording::array_type::write_reproducer): Switch to
gcc_jit_context_new_array_type_unsigned_long.
* jit-recording.h (class array_type): Change num_elements type
to unsigned long.
(new_array_type): Change num_elements type to unsigned long.
(num_elements): Change return type to unsigned long.
* libgccjit.cc (gcc_jit_context_new_array_type_unsigned_long):
New function.
* libgccjit.h (gcc_jit_context_new_array_type_unsigned_long):
New function.
* libgccjit.map: New function.
gcc/testsuite/ChangeLog:
* jit.dg/all-non-failing-tests.h: Add test-arrays-unsigned-long.c.
* jit.dg/test-arrays-unsigned-long.c: New test.
---
gcc/jit/jit-playback.cc | 2 +-
gcc/jit/jit-playback.h| 2 +-
gcc/jit/jit-recording.cc | 12 +-
gcc/jit/jit-recording.h | 8 +-
gcc/jit/libgccjit.cc | 12 +-
gcc/jit/libgccjit.h | 7 +
gcc/jit/libgccjit.map | 5 +
gcc/testsuite/jit.dg/all-non-failing-tests.h | 10 ++
.../jit.dg/test-arrays-unsigned-long.c| 165 ++
9 files changed, 210 insertions(+), 13 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-arrays-unsigned-long.c
diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
index 6baa838af10..b3775a18a83 100644
--- a/gcc/jit/jit-playback.cc
+++ b/gcc/jit/jit-playback.cc
@@ -327,7 +327,7 @@ playback::type *
playback::context::
new_array_type (playback::location *loc,
playback::type *element_type,
- int num_elements)
+ unsigned long num_elements)
{
gcc_assert (element_type);
diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
index aa6a086613c..7cbb2d1f8d8 100644
--- a/gcc/jit/jit-playback.h
+++ b/gcc/jit/jit-playback.h
@@ -80,7 +80,7 @@ public:
type *
new_array_type (location *loc,
type *element_type,
- int num_elements);
+ unsigned long num_elements);
field *
new_field (location *loc,
diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc
index 68a2e860c1f..3a05e91c140 100644
--- a/gcc/jit/jit-recording.cc
+++ b/gcc/jit/jit-recording.cc
@@ -841,7 +841,7 @@ recording::context::get_int_type (int num_bytes, int is_signed)
recording::type *
recording::context::new_array_type (recording::location *loc,
recording::type *element_type,
-int num_elements)
+unsigned long num_elements)
{
if (struct_ *s = element_type->dyn_cast_struct ())
if (!s->get_fields ())
@@ -3129,7 +3129,7 @@ recording::string *
recording::array_type::make_debug_string ()
{
return string::from_printf (m_ctxt,
- "%s[%d]",
+ "%s[%ld]",
m_element_type->get_debug_string (),
m_num_elements);
}
@@ -3142,10 +3142,10 @@ recording::array_type::write_reproducer (reproducer &r)
{
const char *id = r.make_identifier (this, "array_type");
r.write (" gcc_jit_type *%s =\n"
- &q
Re: [PATCH] libgccjit: Allow comparing aligned int types
Thanks for the review.
Here's the updated patch.
On Wed, 2024-01-24 at 12:18 -0500, David Malcolm wrote:
> On Thu, 2023-12-21 at 08:33 -0500, Antoni Boucher wrote:
> > Hi.
> > This patch allows comparing aligned integer types as equal.
> > There's a TODO in the code about whether we should check that the
> > alignment is equal.
> > What are your thoughts on this?
>
> I think we should check for equal alignment.
>
> [...snip...]
>
> > diff --git a/gcc/testsuite/jit.dg/test-types.c
> > b/gcc/testsuite/jit.dg/test-types.c
> > index a01944e35fa..c2f4d2bcb3d 100644
> > --- a/gcc/testsuite/jit.dg/test-types.c
> > +++ b/gcc/testsuite/jit.dg/test-types.c
> > @@ -485,11 +485,15 @@ verify_code (gcc_jit_context *ctxt,
> > gcc_jit_result *result)
> >
> > CHECK_VALUE (z.m_FILE_ptr, stderr);
> >
> > + gcc_jit_type *long_type = gcc_jit_context_get_type (ctxt,
> > GCC_JIT_TYPE_LONG);
> > + gcc_jit_type *int64_type = gcc_jit_context_get_type (ctxt,
> > GCC_JIT_TYPE_INT64_T);
> > if (sizeof(long) == 8)
> > - CHECK (gcc_jit_compatible_types (
> > - gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_LONG),
> > - gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_INT64_T)));
> > + CHECK (gcc_jit_compatible_types (long_type, int64_type));
> >
> > CHECK_VALUE (gcc_jit_type_get_size (gcc_jit_context_get_type
> > (ctxt, GCC_JIT_TYPE_FLOAT)), sizeof (float));
> > CHECK_VALUE (gcc_jit_type_get_size (gcc_jit_context_get_type
> > (ctxt, GCC_JIT_TYPE_DOUBLE)), sizeof (double));
> > +
> > + gcc_jit_type *aligned_long = gcc_jit_type_get_aligned
> > (long_type, 4);
> > + gcc_jit_type *aligned_int64 = gcc_jit_type_get_aligned
> > (int64_type, 4);
> > + CHECK (gcc_jit_compatible_types (aligned_long, aligned_int64));
>
> This CHECK should be guarded on sizeof(long) == 8 like the check
> above.
>
>
> Dave
>
From 899a0555fa1b1796d29b59a6a41db854c46f6c09 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sun, 8 Oct 2023 09:12:12 -0400
Subject: [PATCH] libgccjit: Allow comparing aligned int types
gcc/jit/ChangeLog:
* jit-common.h: Add forward declaration of memento_of_get_aligned.
* jit-recording.h (type::is_same_type_as): Compare integer
types.
(dyn_cast_aligned_type): New method.
(type::is_aligned, memento_of_get_aligned::is_same_type_as,
memento_of_get_aligned::is_aligned): new methods.
gcc/testsuite/ChangeLog:
* jit.dg/test-types.c: Add checks comparing aligned types.
---
gcc/jit/jit-common.h | 1 +
gcc/jit/jit-recording.h | 30 +++---
gcc/testsuite/jit.dg/test-types.c | 11 ---
3 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/gcc/jit/jit-common.h b/gcc/jit/jit-common.h
index 1e335878b56..53a6dcce79f 100644
--- a/gcc/jit/jit-common.h
+++ b/gcc/jit/jit-common.h
@@ -133,6 +133,7 @@ namespace recording {
class statement;
class extended_asm;
class case_;
+class memento_of_get_aligned;
class top_level_asm;
/* End of recording types. */
diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
index d8d16f4fe29..9af952cc217 100644
--- a/gcc/jit/jit-recording.h
+++ b/gcc/jit/jit-recording.h
@@ -552,6 +552,7 @@ public:
virtual function_type *as_a_function_type() { gcc_unreachable (); return NULL; }
virtual struct_ *dyn_cast_struct () { return NULL; }
virtual vector_type *dyn_cast_vector_type () { return NULL; }
+ virtual memento_of_get_aligned *dyn_cast_aligned_type () { return NULL; }
/* Is it typesafe to copy to this type from rtype? */
virtual bool accepts_writes_from (type *rtype)
@@ -562,6 +563,14 @@ public:
virtual bool is_same_type_as (type *other)
{
+if (is_int ()
+ && other->is_int ()
+ && get_size () == other->get_size ()
+ && is_signed () == other->is_signed ())
+{
+ /* LHS (this) is an integer of the same size and sign as rtype. */
+ return true;
+}
return this == other;
}
@@ -579,6 +588,7 @@ public:
virtual type *is_volatile () { return NULL; }
virtual type *is_restrict () { return NULL; }
virtual type *is_const () { return NULL; }
+ virtual type *is_aligned () { return NULL; }
virtual type *is_array () = 0;
virtual struct_ *is_struct () { return NULL; }
virtual bool is_union () const { return false; }
@@ -633,13 +643,6 @@ public:
accept it: */
return true;
}
- } else if (is_int ()
- && rtype->is_int ()
- && get_size () == rtype->get_size ()
- && is_signed () == rtype->is_signed ())
- {
- /* LHS (this) is an integer of the same size and sign as rtype. */
- return true;
}
return type::accepts_writes_from (rtype);
@@ -816,10 +
Re: [PATCH] libgccjit: Support signed char flag
Thanks for the review and idea.
Here's the updated patch. I added a test, but I could not set -fsigned-
char as this is not an option accepted by the jit frontend.
However, the test still works in the sense that it fails without this
patch and passes with it.
I'm just wondering if it would pass on all targets or if I should add a
target filtering directive to only execute on some target.
What do you think?
On Tue, 2024-01-09 at 11:01 -0500, David Malcolm wrote:
> On Thu, 2023-12-21 at 08:42 -0500, Antoni Boucher wrote:
> > Hi.
> > This patch adds support for the -fsigned-char flag.
>
> Thanks. The patch looks correct to me.
>
> > I'm not sure how to test it since I stumbled upon this bug when I
> > found
> > this other bug
> > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863)
> > which is now fixed.
> > Any idea how I could test this patch?
>
> We already document that GCC_JIT_TYPE_CHAR has "some signedness".
> The
> bug being fixed here is that gcc_jit_context compilations were always
> treating "char" as unsigned, regardless of the value of -fsigned-char
> (either from the target's default, or as a context option), when it
> makes more sense to follow the C frontend's behavior.
>
> So perhaps jit-written code with a context that has -fsigned-char as
> an
> option (via gcc_jit_context_add_command_line_option), and which
> promotes a negative char to a signed int, and then returns the result
> as an int? Presumably if we're erroneously forcing "char" to be
> unsigned, the int will be in the range 0x80 to 0xff, rather that
> being
> negative.
>
> Dave
>
From 57d4bd695bcb16c54ecbe05346282f5dc270c30a Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Mon, 3 Oct 2022 19:11:39 -0400
Subject: [PATCH] libgccjit: Support signed char flag
gcc/jit/ChangeLog:
* dummy-frontend.cc (jit_langhook_init): Send flag_signed_char
argument to build_common_tree_nodes.
gcc/testsuite/ChangeLog:
* jit.dg/all-non-failing-tests.h: Add test-signed-char.c.
* jit.dg/test-signed-char.c: New test.
---
gcc/jit/dummy-frontend.cc| 2 +-
gcc/testsuite/jit.dg/all-non-failing-tests.h | 10
gcc/testsuite/jit.dg/test-signed-char.c | 52
3 files changed, 63 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/jit.dg/test-signed-char.c
diff --git a/gcc/jit/dummy-frontend.cc b/gcc/jit/dummy-frontend.cc
index dbeeacd17a8..dc1347b714a 100644
--- a/gcc/jit/dummy-frontend.cc
+++ b/gcc/jit/dummy-frontend.cc
@@ -1029,7 +1029,7 @@ jit_langhook_init (void)
diagnostic_starter (global_dc) = jit_begin_diagnostic;
diagnostic_finalizer (global_dc) = jit_end_diagnostic;
- build_common_tree_nodes (false);
+ build_common_tree_nodes (flag_signed_char);
build_common_builtin_nodes ();
diff --git a/gcc/testsuite/jit.dg/all-non-failing-tests.h b/gcc/testsuite/jit.dg/all-non-failing-tests.h
index 14a0a321550..404377a4df0 100644
--- a/gcc/testsuite/jit.dg/all-non-failing-tests.h
+++ b/gcc/testsuite/jit.dg/all-non-failing-tests.h
@@ -353,6 +353,13 @@
/* test-setting-alignment.c: This can't be in the testcases array as it
is target-specific. */
+/* test-signed-char.c */
+#define create_code create_code_signed_char
+#define verify_code verify_code_signed_char
+#include "test-signed-char.c"
+#undef create_code
+#undef verify_code
+
/* test-sizeof.c */
#define create_code create_code_sizeof
#define verify_code verify_code_sizeof
@@ -560,6 +567,9 @@ const struct testcase testcases[] = {
{"reflection",
create_code_reflection ,
verify_code_reflection },
+ {"signed-char",
+ create_code_signed_char,
+ verify_code_signed_char},
{"sizeof",
create_code_sizeof,
verify_code_sizeof},
diff --git a/gcc/testsuite/jit.dg/test-signed-char.c b/gcc/testsuite/jit.dg/test-signed-char.c
new file mode 100644
index 000..c12b41d92cc
--- /dev/null
+++ b/gcc/testsuite/jit.dg/test-signed-char.c
@@ -0,0 +1,52 @@
+#include
+#include
+#include
+
+#include "libgccjit.h"
+
+#include "harness.h"
+
+void
+create_code (gcc_jit_context *ctxt, void *user_data)
+{
+ /* Let's try to inject the equivalent of:
+int test_signed_char ()
+{
+char val = -2;
+return (int) val;
+}
+*/
+ gcc_jit_type *char_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_CHAR);
+ gcc_jit_type *int_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_INT);
+
+ gcc_jit_function *test_fn =
+gcc_jit_context_new_function (ctxt, NULL,
+ GCC_JIT_FUNCTION_EXPORTED,
+ int_type,
+ "test_signed_char",
+ 0, NULL,
+ 0);
+
+ gcc_jit_block *block = gcc_jit_function_new_block(test_fn, "entry");
+
+ gcc_jit_rvalue *val = gcc_jit_context_n
Re: [PATCH] libgccjit: Add support for setting the comment ident
Thanks for the review.
Here's the updated patch. See answers to question below.
On Fri, 2024-01-05 at 14:39 -0500, David Malcolm wrote:
> On Fri, 2024-01-05 at 12:09 -0500, Antoni Boucher wrote:
> > Hi.
> > This patch adds support for setting the comment ident (analogous to
> > #ident "comment" in C).
> > Thanks for the review.
>
> Thanks for the patch.
>
> This may sound like a silly question, but what does #ident do and
> what
> is it used for?
This adds text to the .comment section.
>
> FWIW I found this in our documentation:
> https://gcc.gnu.org/onlinedocs/cpp/Other-Directives.html
>
> [...snip...]
>
> > +Output options
> > +**
> > +
> > +.. function:: void gcc_jit_context_set_output_ident
> > (gcc_jit_context *ctxt,\
> > + const char*
> > output_ident)
> > +
> > + Set the identifier to write in the .comment section of the
> > output file to
> > + ``output_ident``. Analogous to:
>
> ...but only on some targets, according to the link above. Maybe add
> that link here?
>
> > +
> > + .. code-block:: c
> > +
> > + #ident "My comment"
> > +
> > + in C.
> > +
> > + This entrypoint was added in :ref:`LIBGCCJIT_ABI_26`; you can
> > test for
> > + its presence using
>
> Can the param "output_ident" be NULL? It isn't checked for NULL in
> the
> patch's implementation of gcc_jit_context_set_output_ident, and
> recording::output_ident's constructor does check for it being NULL...
>
> > +
> > + .. code-block:: c
> > +
> > + #ifdef LIBGCCJIT_HAVE_gcc_jit_context_set_output_ident
>
> > diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
> > index 537f3b1..243a9fdf972 100644
> > --- a/gcc/jit/jit-playback.cc
> > +++ b/gcc/jit/jit-playback.cc
> > @@ -319,6 +319,13 @@ get_type (enum gcc_jit_types type_)
> > return new type (type_node);
> > }
> >
> > +void
> > +playback::context::
> > +set_output_ident (const char* ident)
> > +{
> > + targetm.asm_out.output_ident (ident);
> > +}
> > +
>
> ...but looking at varasm.cc's default_asm_output_ident_directive it
> looks like the param must be non-NULL.
>
> So this should either be conditionalized here to:
>
> if (ident)
> targetm.asm_out.output_ident (ident);
>
> or else we should ensure that "ident" is non-NULL at the API boundary
> and document this.
Ok, updated the patch to do this at the API boundary.
>
> My guess is that it doesn't make sense to have a NULL ident, so we
> should go with the latter approach.
>
> Can you have more than one #ident directive? Presumably each one
> just
> adds another line to the generated asm, right?
Yes.
>
> [...snip...]
>
> > @@ -2185,6 +2192,52 @@ recording::string::write_reproducer
> > (reproducer &)
> > /* Empty. */
> > }
> >
> > +/* The implementation of class gcc::jit::recording::output_ident.
> > */
> > +
> > +/* Constructor for gcc::jit::recording::output_ident, allocating a
> > + copy of the given text using new char[]. */
> > +
> > +recording::output_ident::output_ident (context *ctxt, const char
> > *ident)
> > +: memento (ctxt)
> > +{
> > + m_ident = ident ? xstrdup (ident) : NULL;
> > +}
> > +
> > +/* Destructor for gcc::jit::recording::output_ident. */
> > +
> > +recording::output_ident::~output_ident ()
> > +{
> > + delete[] m_ident;
>
> m_ident is allocated above using xstrdup, so it must be cleaned up
> with
> "free"; I don't think it's safe to use "delete[]" here.
>
> [...snip...]
>
> > +/* Implementation of recording::memento::write_reproducer for
> > output_ident. */
> > +
> > +void
> > +recording::output_ident::write_reproducer (reproducer &r)
> > +{
> > + r.write (" gcc_jit_context_set_output_ident (%s, \"%s\");",
> > + r.get_identifier (get_context ()),
> > + m_ident);
>
> It isn't safe on all implementations to use %s with m_ident being
> NULL.
Now, m_ident is non-NULL.
>
> [...snip...]
>
> Thanks again for the patch; hope this is constructive
> Dave
>
From 1e98faa4cc489641289cb8d6634e24efaa3d36a2 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Fri, 27 Oct 2023 17:36:03 -0400
Subject: [PATCH] libgccjit: Add support for setting the comment ident
gcc/jit/ChangeLog:
* docs/
Re: [PATCH] libgccjit: Make new_array_type take unsigned long
I had forgotten to add the doc since there is now a new API. Here it is. On Wed, 2024-02-21 at 19:45 -0500, Antoni Boucher wrote: > Thanks for the review. > > Here's the updated patch. > > On Thu, 2023-12-07 at 20:04 -0500, David Malcolm wrote: > > On Thu, 2023-12-07 at 17:29 -0500, Antoni Boucher wrote: > > > Hi. > > > This patches update gcc_jit_context_new_array_type to take the > > > size > > > as > > > an unsigned long instead of a int, to allow creating bigger array > > > types. > > > > > > I haven't written the ChangeLog yet because I wasn't sure it's > > > allowed > > > to change the type of a function like that. > > > If it isn't, what would you suggest? > > > > We've kept ABI compatibility all the way back to the version in GCC > > 5, > > so it seems a shame to break ABI. > > > > How about a new API entrypoint: > > gcc_jit_context_new_array_type_unsigned_long > > whilst keeping the old one. > > > > Then everything internally can use "unsigned long"; we just keep > > the > > old entrypoint accepting int (which internally promotes the arg to > > unsigned long, if positive, sharing all the implementation). > > > > Alternatively, I think there may be a way to do this with symbol > > versioning: > > https://gcc.gnu.org/wiki/SymbolVersioning > > see e.g. Section 3.7 of Ulrich Drepper's "How To Write Shared > > Libraries", but I'm a bit wary of cross-platform compatibility with > > that. > > > > Dave > > > > > From 00156914f0805788190706935962fe65ab5fd7cb Mon Sep 17 00:00:00 2001 From: Antoni Boucher Date: Sat, 4 Mar 2023 00:44:49 -0500 Subject: [PATCH] libgccjit: Add gcc_jit_context_new_array_type_unsigned_long gcc/jit/ChangeLog: * docs/topics/compatibility.rst (LIBGCCJIT_ABI_28): New ABI tag. * docs/topics/types.rst: Document gcc_jit_context_new_array_type_unsigned_long. * jit-playback.cc (new_array_type): Change num_elements type to unsigned long. * jit-playback.h (new_array_type): Change num_elements type to unsigned long. * jit-recording.cc (recording::context::new_array_type): Change num_elements type to unsigned long. (recording::array_type::make_debug_string): Use unsigned long format. (recording::array_type::write_reproducer): Switch to gcc_jit_context_new_array_type_unsigned_long. * jit-recording.h (class array_type): Change num_elements type to unsigned long. (new_array_type): Change num_elements type to unsigned long. (num_elements): Change return type to unsigned long. * libgccjit.cc (gcc_jit_context_new_array_type_unsigned_long): New function. * libgccjit.h (gcc_jit_context_new_array_type_unsigned_long): New function. * libgccjit.map: New function. gcc/testsuite/ChangeLog: * jit.dg/all-non-failing-tests.h: Add test-arrays-unsigned-long.c. * jit.dg/test-arrays-unsigned-long.c: New test. --- gcc/jit/docs/topics/compatibility.rst | 7 + gcc/jit/docs/topics/types.rst | 18 ++ gcc/jit/jit-playback.cc | 2 +- gcc/jit/jit-playback.h| 2 +- gcc/jit/jit-recording.cc | 12 +- gcc/jit/jit-recording.h | 8 +- gcc/jit/libgccjit.cc | 12 +- gcc/jit/libgccjit.h | 14 ++ gcc/jit/libgccjit.map | 5 + gcc/testsuite/jit.dg/all-non-failing-tests.h | 10 ++ .../jit.dg/test-arrays-unsigned-long.c| 165 ++ 11 files changed, 242 insertions(+), 13 deletions(-) create mode 100644 gcc/testsuite/jit.dg/test-arrays-unsigned-long.c diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst index 9cfb054f653..a8c8cf45630 100644 --- a/gcc/jit/docs/topics/compatibility.rst +++ b/gcc/jit/docs/topics/compatibility.rst @@ -397,3 +397,10 @@ on functions and variables: ``LIBGCCJIT_ABI_27`` covers the addition of :func:`gcc_jit_context_new_sizeof` + +.. _LIBGCCJIT_ABI_28: + +``LIBGCCJIT_ABI_28`` + +``LIBGCCJIT_ABI_28`` covers the addition of +:func:`gcc_jit_context_new_array_type_unsigned_long` diff --git a/gcc/jit/docs/topics/types.rst b/gcc/jit/docs/topics/types.rst index bb51f037b7e..d83ecd3cf13 100644 --- a/gcc/jit/docs/topics/types.rst +++ b/gcc/jit/docs/topics/types.rst @@ -160,6 +160,24 @@ Pointers, `const`, and `volatile` Given non-`void` type "T", get type "T[N]" (for a constant N). +.. function:: gcc_jit_type *\ + gcc_jit_context_new_array_type_unsigned_long (gcc_jit_context *ctxt, \ + gcc_jit_location *loc, \ +
Re: [PATCH] libgccjit: Add ability to get CPU features
David: Ping. Iain: Ping. On Tue, 2024-02-13 at 13:37 -0500, Antoni Boucher wrote: > David: Ping. > > On Tue, 2024-02-06 at 07:54 -0500, Antoni Boucher wrote: > > David: Ping. > > > > On Tue, 2024-01-30 at 10:50 -0500, Antoni Boucher wrote: > > > David: I'm unsure what to do here. It seems we cannot find a > > > reviewer. > > > Would it help if I show you the code in gccrs that is similar? > > > Would it help if I ask someone from gccrs to review this code? > > > > > > On Sat, 2024-01-20 at 09:50 -0500, Antoni Boucher wrote: > > > > CC-ing Iain in case they can do the review since it is based on > > > > how > > > > they did it in the D frontend. > > > > Could you please do the review? > > > > Thanks! > > > > > > > > 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? > > > > > > > > > > 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 > > > > > > > > > > > > > > >
Re: [PATCH] libgccjit: Add support for machine-dependent builtins
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. > > > > > > > > > > > > > > >
Re: [PATCH] libgccjit: Allow comparing array types
David: Ping. On Thu, 2024-01-25 at 07:52 -0500, Antoni Boucher wrote: > Thanks. > Can we please agree on some wording to use so I know when the patch > can > be pushed. Especially since we're now in stage 4, it would help me if > you say something like "you can push to master". > Regards. > > On Wed, 2024-01-24 at 12:14 -0500, David Malcolm wrote: > > On Fri, 2024-01-19 at 16:55 -0500, Antoni Boucher wrote: > > > Hi. > > > This patch allows comparing different instances of array types as > > > equal. > > > Thanks for the review. > > > > Thanks; the patch looks good to me. > > > > Dave > > >
Re: [PATCH] libgccjit: Fix GGC segfault when using -flto
On Wed, 2024-01-10 at 10:19 -0500, David Malcolm wrote: > On Mon, 2023-12-11 at 19:20 -0500, Antoni Boucher wrote: > > I'm not sure how to do this. I tried the following commands, but > > this > > fails even on master: > > > > ../../gcc/configure --enable-host-shared --enable- > > languages=c,jit,c++,fortran,objc,lto --enable-checking=release -- > > disable-werror --prefix=/opt/gcc > > > > make bootstrap -j24 > > make -k check -j24 > > > > From what I can understand, the unexpected failures are in g++: > > > > === g++ Summary === > > > > # of expected passes72790 > > # of unexpected failures1 > > # of expected failures 1011 > > # of unsupported tests 3503 > > > > === g++ Summary === > > > > # of expected passes4750 > > # of unexpected failures27 > > # of expected failures 16 > > # of unsupported tests 43 > > > > > > Am I doing something wrong? > > I normally do a pair of bootstrap/tests: a "control" build with a > pristine copy of the source tree, and an "experiment" build > containing > the patch(s) of interest, then compare the results. FWIW given that > each one takes 2 hours on my machine, I normally just do one control > build on a Monday, rebase all my working copies to that revision, and > then use that control build throughout the week for comparison when > testing patches. > > I can have a go at testing an updated patch if you like; presumably > the > latest version is this one: > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638841.html > right? Thanks. I would appreciate if you do it. Yes, this is the latest patch. > > Dave > > > > > > > On Fri, 2023-12-01 at 12:49 -0500, David Malcolm wrote: > > > On Thu, 2023-11-30 at 17:13 -0500, Antoni Boucher wrote: > > > > Here's the updated patch. > > > > The failure was due to the test being in the test array while > > > > it > > > > should > > > > not have been there since it changes the context. > > > > > > Thanks for the updated patch. > > > > > > Did you do a full bootstrap and regression test with this one, or > > > do > > > you want me to? > > > > > > Dave > > > > > >
Re: [PATCH] libgccjit: Add missing builtins needed by optimizations
Just to make sure since we are in stage 4. Does that mean I can merge it? In general, how would I know if it's OK to merge? If the patch is in the state Accepted on patchwork, does that mean it's always OK to merge no matter the stage we're in? On Tue, 2024-01-09 at 11:35 -0500, David Malcolm wrote: > On Fri, 2023-12-22 at 09:39 -0500, Antoni Boucher wrote: > > Hi. > > This patch adds missing builtins needed by optimizations. > > Thanks for the review. > > The patch looks good to me. > > Thanks! > Dave >
Re: [PATCH] libgccjit: Implement sizeof operator
On Tue, 2024-01-09 at 11:33 -0500, David Malcolm wrote: > On Fri, 2023-12-22 at 10:25 -0500, Antoni Boucher wrote: > > Hi. > > This patch adds the support of the sizeof operator. > > I was wondering if this new API entrypoint should take a location > > as > > a > > parameter. What do you think? > > I'd prefer it if it did (even if it's currently ignored internally), > but it's not a big deal. The reason it doesn't have a location is because it directly produces a constant, rather like gcc_jit_context_new_rvalue_from_int, which doesn't have a location either. So, I wanted to confirm that you think it's needed to have a location. Also, I realized I misnamed memento_of_new_sizeof and will rename it to memento_of_sizeof. > > > Thanks for the review. > > The patch is OK as-is. > > Thanks > Dave >
Re: [PATCH] libgccjit: Add ability to get CPU features
David: Ping in case you missed it. On Wed, 2023-12-13 at 14:56 -0500, Antoni Boucher wrote: > 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. 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 > > >
Re: [PATCH] libgccjit: Fix infinite recursion in gt_ggc_mx_lang_tree_node
It seems I cannot reproduce the issue.
Should we drop this patch, then?
Or do you think there's value in keeping it?
On Mon, 2022-06-06 at 19:01 -0400, David Malcolm wrote:
> On Thu, 2022-06-02 at 21:23 -0400, Antoni Boucher via Gcc-patches
> wrote:
> > Sorry, forgot to attach the patch.
> >
> > Here it is.
> >
> > On Thu, 2022-06-02 at 21:20 -0400, Antoni Boucher via Jit wrote:
> > > Hi.
> > > The attached patch fix bug 105827:
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105827
> > >
> > > I'm not sure how to test this, so please share ideas.
>
> Do you have a reproducer for this?
>
> With garbage-collections issues in libgccjit, you can set:
>
> gcc_jit_context_set_bool_option (ctxt,
> GCC_JIT_BOOL_OPTION_SELFCHECK_GC,
> 1);
>
> which will force a full garbage collection at every opportunity that
> the collector considers doing one (rather than following heuristics)
>
> This really slows things down, but makes reproducing crashes much
> more
> deterministic, often turning "it crashes every now and then" to "it
> crashes every time" (and the test suite runs with this enabled).
>
> > >
> > > Thanks for the review.
> >
>
> > diff --git a/gcc/jit/dummy-frontend.cc b/gcc/jit/dummy-frontend.cc
> > index 84ff359bfe3..8bb5d03d630 100644
> > --- a/gcc/jit/dummy-frontend.cc
> > +++ b/gcc/jit/dummy-frontend.cc
> > @@ -506,13 +506,14 @@ struct GTY(()) lang_identifier
> >
> > /* The resulting tree type. */
> >
> > +/* See lang_tree_node in gcc/c/c-decl.cc. */
> > union GTY((desc ("TREE_CODE (&%h.generic) == IDENTIFIER_NODE"),
> > - chain_next ("CODE_CONTAINS_STRUCT (TREE_CODE
> > (&%h.generic), TS_COMMON) ? ((union lang_tree_node *) TREE_CHAIN
> > (&%h.generic)) : NULL")))
> > -lang_tree_node
> > -{
> > - union tree_node GTY((tag ("0"),
> > - desc ("tree_node_structure (&%h)")))
> > generic;
> > - struct lang_identifier GTY((tag ("1"))) identifier;
> > + chain_next ("(union lang_tree_node *) jit_tree_chain_next
> > (&%h.generic)"))) lang_tree_node
> > + {
> > + union tree_node GTY ((tag ("0"),
> > + desc ("tree_node_structure (&%h)")))
> > + generic;
> > + struct lang_identifier GTY ((tag ("1"))) identifier;
> > };
>
> Those GTY markings on gcc/jit/dummy-frontend.cc's lang_tree_node
> union
> have been like that since my initial proof-of-concept patch back in
> 2013:
> https://gcc.gnu.org/legacy-ml/gcc-patches/2013-10/msg00228.html
> so presumably I simply copied and pasted that from another frontend
> when I was initially prototyping libgccjit. There was an element of
> "cargo cult programming" as I was getting the project started.
>
> Jakub had changed the C and C++ frontends in June 2011 with
> 563007852e8d19b66ec8c1e42e431efaaa967dc6, which introduced the
> c_tree_chain_next that you're now copying in your patch, so
> presumably
> I copied from a different frontend. My notes say I created the first
> prototype in July 2013, so that's when I would have copied&pasted the
> code.
>
> Dave
>
>
>
>
>
>
Re: [PATCH] libgccjit: Add support for machine-dependent builtins
David: Ping in case you missed this patch. 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.
Re: [PATCH] libgccjit: Add support for machine-dependent builtins
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. > > >
Re: [PATCH] libgccjit: Add ability to get CPU features
Here's an updated patch to include the change from this PATCH: https://gcc.gnu.org/pipermail/jit/2023q4/001763.html 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? > > 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 > From b1e8df6da7c7876e5cb5c6fde60f0fff854888e3 Mon Sep 17 00:00:00 2001 From: Antoni Boucher Date: Mon, 26 Jun 2023 18:29:15 -0400 Subject: [PATCH] libgccjit: Add ability to get CPU features gcc/ChangeLog: PR jit/112466 * Makefile.in (tm_jit_file_list, tm_jit_include_list, TM_JIT_H, JIT_TARGET_DEF, JIT_TARGET_H, JIT_TARGET_OBJS): New variables. (tm_jit.h, cs-tm_jit.h, jit/jit-target-hooks-def.h, s-jit-target-hooks-def-h, default-jit.o): New rules. (s-tm-texi): Also check timestamp on jit-target.def. (generated_files): Add TM_JIT_H and jit/jit-target-hooks-def.h. (build/genhooks.o): Also depend on JIT_TARGET_DEF. * config.gcc (tm_jit_file, jit_target_objs, target_has_targetjitm): New variables. * config/i386/t-i386 (i386-jit.o): New rule. * config/t-linux (linux-jit.o): New rule. * configure: Regenerate. * configure.ac (tm_jit_file_list, tm_jit_include_list, jit_target_objs): Add substitutes. * doc/tm.texi: Regenerate. * doc/tm.texi.in (targetjitm): Document. (target_has_targetjitm): Document. * genhooks.cc: Include jit/jit-target.def. * config/default-jit.cc: New file. * config/i386/i386-jit.cc: New file. * config/i386/i386-jit.h: New file. * config/linux-jit.cc: New file. gcc/jit/ChangeLog: PR jit/112466 * Make-lang.in (JIT_OBJS): New variable. * jit-playback.cc (replay): Include jit-target.h and initialize target. * jit-playback.h (class get_target_info): New class. * jit-recording.cc (recording::context::get_target_info): New method. * jit-recording.h (recording::context::get_target_info): New method. * libgccjit.cc: Include jit-target.h. (struct gcc_jit_target_info): New struct. (gcc_jit_context_get_target_info, gcc_jit_target_info_release, gcc_jit_target_info_cpu_supports, gcc_jit_target_info_arch, gcc_jit_target_info_supports_128bit_int): New functions. * libgccjit.h (gcc_jit_context_get_target_info, gcc_jit_target_info_release, gcc_jit_target_info_cpu_supports, gcc_jit_target_info_arch, gcc_jit_target_info_supports_128bit_int): New functions. * libgccjit.map (LIBGCCJIT_ABI_26): New ABI tag. * docs/topics/compilation.rst: Add documentation for the functions gcc_jit_context_get_target_info, gcc_jit_target_info_release, gcc_jit_target_info_cpu_supports, gcc_jit_target_info_arch, gcc_jit_target_info_supports_128bit_int. * docs/topics/compatibility.rst (LIBGCCJIT_ABI_26
[PATCH] libgccjit: Fix float playback for cross-compilation
Hi.
This patch fixes the bug 113343.
I'm wondering if there's a better solution than using mpfr.
The only other solution I found is real_from_string, but that seems
overkill to convert the number to a string.
I could not find a better way to create a real value from a host
double.
If there's no solution, do we lose some precision by using mpfr?
Running Rust's core library tests, there was a difference of one
decimal, so I'm wondering if there's some lost precision, or if it's
just because those tests don't work on m68k which was my test target.
Also, I'm not sure how to write a test this fix. Any ideas?
Thanks for the review.
From 8ddfd4abbe6e46efc256030c2d010f035cd9ecf0 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sat, 21 Oct 2023 11:20:46 -0400
Subject: [PATCH] libgccjit: Fix float playback for cross-compilation
gcc/jit/ChangeLog:
PR jit/113343
* jit-playback.cc (new_rvalue_from_const): Fix to have the
correct value when cross-compiling.
---
gcc/jit/jit-playback.cc | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
index 537f3b1..9cb27ee4ef3 100644
--- a/gcc/jit/jit-playback.cc
+++ b/gcc/jit/jit-playback.cc
@@ -41,6 +41,7 @@ along with GCC; see the file COPYING3. If not see
#include "gcc.h"
#include "diagnostic.h"
#include "stmt.h"
+#include "realmpfr.h"
#include "jit-playback.h"
#include "jit-result.h"
@@ -932,22 +933,16 @@ new_rvalue_from_const (type *type,
// FIXME: type-checking, or coercion?
tree inner_type = type->as_tree ();
+ mpfr_t mpf_value;
+
+ mpfr_init2 (mpf_value, 64);
+ mpfr_set_d (mpf_value, value, MPFR_RNDN);
+
/* We have a "double", we want a REAL_VALUE_TYPE.
- real.cc:real_from_target appears to require the representation to be
- split into 32-bit values, and then sent as an pair of host long
- ints. */
+ realmpfr.cc:real_from_mpfr. */
REAL_VALUE_TYPE real_value;
- union
- {
-double as_double;
-uint32_t as_uint32s[2];
- } u;
- u.as_double = value;
- long int as_long_ints[2];
- as_long_ints[0] = u.as_uint32s[0];
- as_long_ints[1] = u.as_uint32s[1];
- real_from_target (&real_value, as_long_ints, DFmode);
+ real_from_mpfr (&real_value, mpf_value, inner_type, MPFR_RNDN);
tree inner = build_real (inner_type, real_value);
return new rvalue (this, inner);
}
--
2.43.0
Re: [PATCH] libgccjit: Add ability to get CPU features
David: Ping. 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? > > 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 >
Re: [PATCH] libgccjit: Add vector permutation and vector access operations
David: Ping. On Thu, 2023-11-30 at 17:16 -0500, Antoni Boucher wrote: > All of these are fixed in this new patch. > Thanks for the review. > > On Mon, 2023-11-20 at 18:05 -0500, David Malcolm wrote: > > On Fri, 2023-11-17 at 17:36 -0500, Antoni Boucher wrote: > > > Hi. > > > This patch adds a vector permutation and vector access operations > > > (bug > > > 112602). > > > > > > This was split from this patch: > > > https://gcc.gnu.org/pipermail/jit/2023q1/001606.html > > > > > > > Thanks for the patch. > > > > Overall, looks good, but 3 minor nitpicks: > > > > [...snip...] > > > > > diff --git a/gcc/jit/docs/topics/compatibility.rst > > > b/gcc/jit/docs/topics/compatibility.rst > > > index ebede440ee4..a764e3968d1 100644 > > > --- a/gcc/jit/docs/topics/compatibility.rst > > > +++ b/gcc/jit/docs/topics/compatibility.rst > > > @@ -378,3 +378,13 @@ alignment of a variable: > > > > > > ``LIBGCCJIT_ABI_25`` covers the addition of > > > :func:`gcc_jit_type_get_restrict` > > > + > > > + > > > +.. _LIBGCCJIT_ABI_26: > > > + > > > +``LIBGCCJIT_ABI_26`` > > > + > > > +``LIBGCCJIT_ABI_26`` covers the addition of functions to > > > manipulate vectors: > > > + > > > + * :func:`gcc_jit_context_new_rvalue_vector_perm` > > > + * :func:`gcc_jit_context_new_vector_access` > > > diff --git a/gcc/jit/docs/topics/expressions.rst > > > b/gcc/jit/docs/topics/expressions.rst > > > index 42cfee36302..4a45aa13f5c 100644 > > > --- a/gcc/jit/docs/topics/expressions.rst > > > +++ b/gcc/jit/docs/topics/expressions.rst > > > @@ -295,6 +295,35 @@ Vector expressions > > > > > > #ifdef > > > LIBGCCJIT_HAVE_gcc_jit_context_new_rvalue_from_vector > > > > > > +.. function:: gcc_jit_rvalue * \ > > > + gcc_jit_context_new_rvalue_vector_perm > > > (gcc_jit_context *ctxt, \ > > > + > > > gcc_jit_location *loc, \ > > > + > > > gcc_jit_rvalue *elements1, \ > > > + > > > gcc_jit_rvalue *elements2, \ > > > + > > > gcc_jit_rvalue *mask); > > > + > > > + Build a permutation of two vectors. > > > + > > > + "elements1" and "elements2" should have the same type. > > > + The length of "mask" and "elements1" should be the same. > > > + The element type of "mask" should be integral. > > > + The size of the element type of "mask" and "elements1" should > > > be the same. > > > + > > > + This entrypoint was added in :ref:`LIBGCCJIT_ABI_25`; you can > > > test for > > ^^ > > Should be 26 > > > > [...snip...] > > > > > Unary Operations > > > > > > > > > @@ -1020,3 +1049,27 @@ Field access is provided separately for > > > both > > > lvalues and rvalues. > > > PTR[INDEX] > > > > > > in C (or, indeed, to ``PTR + INDEX``). > > > + > > > +.. function:: gcc_jit_lvalue *\ > > > + gcc_jit_context_new_vector_access (gcc_jit_context > > > *ctxt,\ > > > + > > > gcc_jit_location > > > *loc,\ > > > + gcc_jit_rvalue > > > *vector,\ > > > + gcc_jit_rvalue > > > *index) > > > + > > > + Given an rvalue of vector type ``T __attribute__ > > > ((__vector_size__ (SIZE)))``, get the element `T` at > > > + the given index. > > > + > > > + This entrypoint was added in :ref:`LIBGCCJIT_ABI_25`; you can > > > test for > > ^^ > > > > Likewise here. > > > > [...snip...] > > > > > @@ -4071,6 +4107,79 @@ gcc_jit_context_new_rvalue_from_vector > > > (gcc_jit_context *ctxt, > > > (gcc::jit::recording::rvalue **)elements); > > > } > > > > > > +/* Public entrypoint. See d
Re: [PATCH] libgccjit: Allow comparing aligned int types
David: Ping. On Thu, 2023-12-21 at 08:33 -0500, Antoni Boucher wrote: > Hi. > This patch allows comparing aligned integer types as equal. > There's a TODO in the code about whether we should check that the > alignment is equal. > What are your thoughts on this? > > Thanks for the review.
Re: [PATCH] libgccjit: Allow sending a const pointer as argument
David: Ping. On Thu, 2023-12-21 at 11:59 -0500, Antoni Boucher wrote: > Hi. > This patch adds the ability to send const pointer as argument to a > function. > Thanks for the review.
Re: [PATCH] libgccjit: Add convert vector
David: Ping. On Thu, 2023-12-21 at 16:01 -0500, Antoni Boucher wrote: > Hi. > This patch adds the support for the convert vector internal function. > I'll need to double-check that making the decl a register is > necessary. > Thanks for the review.
[PATCH] libgccjit: Add support for creating temporary variables
Hi.
This patch adds a new way to create local variable that won't generate
debug info: it is to be used for compiler-generated variables.
Thanks for the review.
From 6f69e9db77f3c7e019fae74414ba5eed15298514 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Thu, 18 Jan 2024 16:54:59 -0500
Subject: [PATCH] libgccjit: Add support for creating temporary variables
gcc/jit/ChangeLog:
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_26): New ABI tag.
* docs/topics/functions.rst: Document gcc_jit_function_new_temp.
* jit-playback.cc (new_local): Add new is_temp parameter.
* jit-playback.h: Add new is_temp parameter.
* jit-recording.cc (recording::function::new_temp): New method.
(recording::local::replay_into): Support temporary variables.
(recording::local::write_reproducer): Support temporary
variables.
* jit-recording.h (new_temp): New method.
(m_is_temp): New field.
* libgccjit.cc (gcc_jit_function_new_temp): New function.
* libgccjit.h (gcc_jit_function_new_temp): New function.
* libgccjit.map: New function.
gcc/testsuite/ChangeLog:
* jit.dg/all-non-failing-tests.h: Mention test-temp.c.
* jit.dg/test-temp.c: New test.
---
gcc/jit/docs/topics/compatibility.rst| 9
gcc/jit/docs/topics/functions.rst| 20 +++
gcc/jit/jit-playback.cc | 21 ++--
gcc/jit/jit-playback.h | 3 +-
gcc/jit/jit-recording.cc | 52 +-
gcc/jit/jit-recording.h | 17 --
gcc/jit/libgccjit.cc | 31 +++
gcc/jit/libgccjit.h | 7 +++
gcc/jit/libgccjit.map| 5 ++
gcc/testsuite/jit.dg/all-non-failing-tests.h | 3 ++
gcc/testsuite/jit.dg/test-temp.c | 56
11 files changed, 205 insertions(+), 19 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-temp.c
diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst
index cbf5b414d8c..5d62e264a00 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -390,3 +390,12 @@ on functions and variables:
* :func:`gcc_jit_function_add_string_attribute`
* :func:`gcc_jit_function_add_integer_array_attribute`
* :func:`gcc_jit_lvalue_add_string_attribute`
+
+.. _LIBGCCJIT_ABI_27:
+
+``LIBGCCJIT_ABI_27``
+
+``LIBGCCJIT_ABI_27`` covers the addition of a functions to create a new
+temporary variable:
+
+ * :func:`gcc_jit_function_new_temp`
diff --git a/gcc/jit/docs/topics/functions.rst b/gcc/jit/docs/topics/functions.rst
index 804605ea939..230caf42466 100644
--- a/gcc/jit/docs/topics/functions.rst
+++ b/gcc/jit/docs/topics/functions.rst
@@ -171,6 +171,26 @@ Functions
underlying string, so it is valid to pass in a pointer to an on-stack
buffer.
+.. function:: gcc_jit_lvalue *\
+ gcc_jit_function_new_temp (gcc_jit_function *func,\
+ gcc_jit_location *loc,\
+ gcc_jit_type *type)
+
+ Create a new local variable within the function, of the given type.
+ This function is similar to :func:`gcc_jit_function_new_local`, but
+ it is to be used for compiler-generated variables (as opposed to
+ user-defined variables in the language to be compiled) and these
+ variables won't show up in the debug info.
+
+ The parameter ``type`` must be non-`void`.
+
+ This entrypoint was added in :ref:`LIBGCCJIT_ABI_26`; you can test
+ for its presence using
+
+ .. code-block:: c
+
+ #ifdef LIBGCCJIT_HAVE_gcc_jit_function_new_temp
+
.. function:: size_t \
gcc_jit_function_get_param_count (gcc_jit_function *func)
diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
index 84df6c100e6..cb6b2f66276 100644
--- a/gcc/jit/jit-playback.cc
+++ b/gcc/jit/jit-playback.cc
@@ -31,6 +31,7 @@ along with GCC; see the file COPYING3. If not see
#include "toplev.h"
#include "tree-cfg.h"
#include "convert.h"
+#include "gimple-expr.h"
#include "stor-layout.h"
#include "print-tree.h"
#include "gimplify.h"
@@ -1950,13 +1951,27 @@ new_local (location *loc,
type *type,
const char *name,
const std::vector> &attributes)
+ std::string>> &attributes,
+ bool is_temp)
{
gcc_assert (type);
- gcc_assert (name);
- tree inner = build_decl (UNKNOWN_LOCATION, VAR_DECL,
+ tree inner;
+ if (is_temp)
+ {
+inner = build_decl (UNKNOWN_LOCATION, VAR_DECL,
+ create_tmp_var_name ("JITTMP"),
+ type->as_tree ());
+DECL_ARTIFICIAL (inner) = 1;
+DECL_IGNORED_P (inner) = 1;
+DECL_NAMELESS (inner) = 1;
+ }
+ else
+ {
+gcc_assert (name);
+inner = build_decl (UNKNOWN_LOCATION, VAR_DECL,
get_identifier (name),
type->as_tree ());
+ }
DECL_CONTEXT (inner) = this-&g
[PATCH] libgccjit: Allow comparing array types
Hi.
This patch allows comparing different instances of array types as
equal.
Thanks for the review.
From ef4afd9de440f10502f3cc84b2112cf83cde2610 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Tue, 2 Jan 2024 16:04:10 -0500
Subject: [PATCH] libgccjit: Allow comparing array types
gcc/jit/ChangeLog:
* jit-common.h: Add array_type class.
* jit-recording.h (type::dyn_cast_array_type,
memento_of_get_aligned::dyn_cast_array_type,
array_type::dyn_cast_array_type, array_type::is_same_type_as):
New methods.
gcc/testsuite/ChangeLog:
* jit.dg/test-types.c: Add array type comparison to the test.
---
gcc/jit/jit-common.h | 1 +
gcc/jit/jit-recording.h | 17 +
gcc/testsuite/jit.dg/test-types.c | 5 +
3 files changed, 23 insertions(+)
diff --git a/gcc/jit/jit-common.h b/gcc/jit/jit-common.h
index 80c1618da96..57a667e6d12 100644
--- a/gcc/jit/jit-common.h
+++ b/gcc/jit/jit-common.h
@@ -118,6 +118,7 @@ namespace recording {
class struct_;
class union_;
class vector_type;
+ class array_type;
class field;
class bitfield;
class fields;
diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
index 4a8082991fb..df33ce219fc 100644
--- a/gcc/jit/jit-recording.h
+++ b/gcc/jit/jit-recording.h
@@ -545,6 +545,7 @@ public:
virtual function_type *as_a_function_type() { gcc_unreachable (); return NULL; }
virtual struct_ *dyn_cast_struct () { return NULL; }
virtual vector_type *dyn_cast_vector_type () { return NULL; }
+ virtual array_type *dyn_cast_array_type () { return NULL; }
/* Is it typesafe to copy to this type from rtype? */
virtual bool accepts_writes_from (type *rtype)
@@ -810,6 +811,11 @@ public:
void replay_into (replayer *) final override;
+ array_type *dyn_cast_array_type () final override
+ {
+return m_other_type->dyn_cast_array_type ();
+ }
+
private:
string * make_debug_string () final override;
void write_reproducer (reproducer &r) final override;
@@ -868,6 +874,17 @@ class array_type : public type
type *dereference () final override;
+ bool is_same_type_as (type *other) final override
+ {
+array_type *other_array_type = other->dyn_cast_array_type ();
+if (!other_array_type)
+ return false;
+return m_num_elements == other_array_type->m_num_elements
+ && m_element_type->is_same_type_as (other_array_type->m_element_type);
+ }
+
+ array_type *dyn_cast_array_type () final override { return this; }
+
bool is_int () const final override { return false; }
bool is_float () const final override { return false; }
bool is_bool () const final override { return false; }
diff --git a/gcc/testsuite/jit.dg/test-types.c b/gcc/testsuite/jit.dg/test-types.c
index a01944e35fa..79f7ea21026 100644
--- a/gcc/testsuite/jit.dg/test-types.c
+++ b/gcc/testsuite/jit.dg/test-types.c
@@ -492,4 +492,9 @@ verify_code (gcc_jit_context *ctxt, gcc_jit_result *result)
CHECK_VALUE (gcc_jit_type_get_size (gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_FLOAT)), sizeof (float));
CHECK_VALUE (gcc_jit_type_get_size (gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_DOUBLE)), sizeof (double));
+
+ gcc_jit_type *int_type = gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_INT);
+ gcc_jit_type *array_type1 = gcc_jit_context_new_array_type (ctxt, NULL, int_type, 2);
+ gcc_jit_type *array_type2 = gcc_jit_context_new_array_type (ctxt, NULL, int_type, 2);
+ CHECK (gcc_jit_compatible_types (array_type1, array_type2));
}
--
2.43.0
[PATCH] libgccjit: Add gcc_jit_global_set_readonly
Hi.
This patch adds a new API gcc_jit_global_set_readonly: it's equivalent
to having a const global variable, but it is useful in the case of
complex compilers where it is not convenient to use const.
Thanks for the review.
From ff3aa19207a6cdaeff6fcb6521ad2ad92f5448ff Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Tue, 24 May 2022 17:45:01 -0400
Subject: [PATCH] libgccjit: Add gcc_jit_global_set_readonly
gcc/jit/ChangeLog:
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_26): New ABI tag.
* docs/topics/expressions.rst: Document gcc_jit_global_set_readonly.
* jit-playback.cc (global_new_decl, new_global,
new_global_initialized): New parameter readonly.
* jit-playback.h (global_new_decl, new_global,
new_global_initialized): New parameter readonly.
* jit-recording.cc (recording::global::replay_into): Use
m_readonly.
(recording::global::write_reproducer): Dump reproducer for
gcc_jit_global_set_readonly.
* jit-recording.h (get_readonly, set_readonly): New methods.
(m_readonly): New attribute.
* libgccjit.cc (gcc_jit_global_set_readonly): New function.
(gcc_jit_block_add_assignment): Check that we don't assign to a
readonly variable.
* libgccjit.h (gcc_jit_global_set_readonly): New function.
(LIBGCCJIT_HAVE_gcc_jit_global_set_readonly): New define.
* libgccjit.map: New function.
gcc/testsuite/ChangeLog:
* jit.dg/all-non-failing-tests.h: Mention test-readonly.c.
* jit.dg/test-error-assign-readonly.c: New test.
* jit.dg/test-readonly.c: New test.
---
gcc/jit/docs/topics/compatibility.rst | 7 +++
gcc/jit/docs/topics/expressions.rst | 12
gcc/jit/jit-playback.cc | 15 +++--
gcc/jit/jit-playback.h| 9 ++-
gcc/jit/jit-recording.cc | 10 ++-
gcc/jit/jit-recording.h | 12
gcc/jit/libgccjit.cc | 22 +++
gcc/jit/libgccjit.h | 5 ++
gcc/jit/libgccjit.map | 5 ++
gcc/testsuite/jit.dg/all-non-failing-tests.h | 3 +
.../jit.dg/test-error-assign-readonly.c | 62 +++
gcc/testsuite/jit.dg/test-readonly.c | 38
12 files changed, 189 insertions(+), 11 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-error-assign-readonly.c
create mode 100644 gcc/testsuite/jit.dg/test-readonly.c
diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst
index ebede440ee4..e13581d0685 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -378,3 +378,10 @@ alignment of a variable:
``LIBGCCJIT_ABI_25`` covers the addition of
:func:`gcc_jit_type_get_restrict`
+
+.. _LIBGCCJIT_ABI_26:
+
+``LIBGCCJIT_ABI_26``
+
+``LIBGCCJIT_ABI_26`` covers the addition of
+:func:`gcc_jit_global_set_readonly`
diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst
index 42cfee36302..8d4aa96e64a 100644
--- a/gcc/jit/docs/topics/expressions.rst
+++ b/gcc/jit/docs/topics/expressions.rst
@@ -944,6 +944,18 @@ Global variables
#ifdef LIBGCCJIT_HAVE_CTORS
+.. function:: void\
+ gcc_jit_global_set_readonly (gcc_jit_lvalue *global)
+
+ Set the global variable as read-only, meaning you cannot assign to this variable.
+
+ This entrypoint was added in :ref:`LIBGCCJIT_ABI_26`; you can test for its
+ presence using:
+
+ .. code-block:: c
+
+ #ifdef LIBGCCJIT_HAVE_gcc_jit_global_set_readonly
+
Working with pointers, structs and unions
-
diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
index 537f3b1..420f3a843cf 100644
--- a/gcc/jit/jit-playback.cc
+++ b/gcc/jit/jit-playback.cc
@@ -607,7 +607,8 @@ global_new_decl (location *loc,
enum gcc_jit_global_kind kind,
type *type,
const char *name,
- enum global_var_flags flags)
+ enum global_var_flags flags,
+ bool readonly)
{
gcc_assert (type);
gcc_assert (name);
@@ -646,7 +647,7 @@ global_new_decl (location *loc,
break;
}
- if (TYPE_READONLY (type_tree))
+ if (TYPE_READONLY (type_tree) || readonly)
TREE_READONLY (inner) = 1;
if (loc)
@@ -674,10 +675,11 @@ new_global (location *loc,
enum gcc_jit_global_kind kind,
type *type,
const char *name,
- enum global_var_flags flags)
+ enum global_var_flags flags,
+ bool readonly)
{
tree inner =
-global_new_decl (loc, kind, type, name, flags);
+global_new_decl (loc, kind, type, name, flags, readonly);
return global_finalize_lvalue (inner);
}
@@ -822,9 +824,10 @@ new_global_initialized (location *loc,
size_t initializer_num_elem,
const void *initializer,
const char *name,
- enum global_var_flags flags)
+ enum global_var_flags flags,
+ bool readonly)
{
- tree inner = global_new_decl (loc, kind, type, name, flags);
+ tree inner = global_new_decl
Re: [PATCH] libgccjit: Add ability to get CPU features
CC-ing Iain in case they can do the review since it is based on how they did it in the D frontend. Could you please do the review? Thanks! 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? > > 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 >
Re: [PATCH] libgccjit: Add gcc_jit_global_set_readonly
Yes, it is for a use case inside of rustc_codegen_gcc. The compiler is structured in a way where we don't know if a global variable might be constant when it is created. On Wed, 2024-01-24 at 10:09 -0500, David Malcolm wrote: > On Fri, 2024-01-19 at 16:57 -0500, Antoni Boucher wrote: > > Hi. > > This patch adds a new API gcc_jit_global_set_readonly: it's > > equivalent > > to having a const global variable, but it is useful in the case of > > complex compilers where it is not convenient to use const. > > Thanks for the review. > > Hi Antoni; thanks for the patch. > > Can you give an example of where/why this might be used? > Presumably this is motivated by a use case you had inside the rustc > backend? > > Thanks > Dave >
Re: [PATCH] libgccjit: Allow comparing array types
Thanks. Can we please agree on some wording to use so I know when the patch can be pushed. Especially since we're now in stage 4, it would help me if you say something like "you can push to master". Regards. On Wed, 2024-01-24 at 12:14 -0500, David Malcolm wrote: > On Fri, 2024-01-19 at 16:55 -0500, Antoni Boucher wrote: > > Hi. > > This patch allows comparing different instances of array types as > > equal. > > Thanks for the review. > > Thanks; the patch looks good to me. > > Dave >
Re: [PATCH] libgccjit: Fix float playback for cross-compilation
Thanks for the review! On Wed, 2024-01-24 at 13:10 -0500, David Malcolm wrote: > On Thu, 2024-01-11 at 18:42 -0500, Antoni Boucher wrote: > > Hi. > > This patch fixes the bug 113343. > > I'm wondering if there's a better solution than using mpfr. > > The only other solution I found is real_from_string, but that seems > > overkill to convert the number to a string. > > I could not find a better way to create a real value from a host > > double. > > I took a look, and I don't see a better way; it seems weird to go > through a string stage. Ideally there would be a > real_from_host_double, but I don't see one. > > Is there a cross-platform way to directly access the representation > of > a host double? I have no idea. > > > If there's no solution, do we lose some precision by using mpfr? > > Running Rust's core library tests, there was a difference of one > > decimal, so I'm wondering if there's some lost precision, or if > > it's > > just because those tests don't work on m68k which was my test > > target. > > Sorry, can you clarify what you mean by "a difference of one decimal" > above? Let's say the Rust core tests expected the value "1.23456789", it instead got the value "1.2345678" (e.g. without the last decimal). Not sure if this is expected. Everything works fine for x86-64; this just happened for m68k which is not well supported for now in Rust, so that might just be that the test doesn't work on this platform. > > > Also, I'm not sure how to write a test this fix. Any ideas? > > I think we don't need cross-compilation-specific tests, we should > just > use and/or extend the existing coverage for > gcc_jit_context_new_rvalue_from_double e.g. in test-constants.c and > test-types.c > > We probably should have test coverage for "awkward" values; we > already > have coverage for DBL_MIN and DBL_MAX, but we don't yet have test > coverage for: > * quiet/signaling NaN > * +ve/-ve inf > * -ve zero Is this something you would want for this patch? > > Thanks > Dave >
Re: [PATCH] libgccjit: Add ability to get CPU features
David: I'm unsure what to do here. It seems we cannot find a reviewer. Would it help if I show you the code in gccrs that is similar? Would it help if I ask someone from gccrs to review this code? On Sat, 2024-01-20 at 09:50 -0500, Antoni Boucher wrote: > CC-ing Iain in case they can do the review since it is based on how > they did it in the D frontend. > Could you please do the review? > Thanks! > > 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? > > > > 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 > > >
Re: [PATCH] libgccjit: Add ability to get CPU features
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. 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 >
[PATCH] libgccjit: Allow comparing aligned int types
Hi.
This patch allows comparing aligned integer types as equal.
There's a TODO in the code about whether we should check that the
alignment is equal.
What are your thoughts on this?
Thanks for the review.
From b1db2e31729876d313061a94c13b155bcd552c02 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sun, 8 Oct 2023 09:12:12 -0400
Subject: [PATCH] libgccjit: Allow comparing aligned int types
gcc/jit/ChangeLog:
* jit-recording.h (type::is_same_type_as): Compare integer
types.
(type::is_aligned, memento_of_get_aligned::is_same_type_as,
memento_of_get_aligned::is_aligned): new methods.
gcc/testsuite/ChangeLog:
* jit.dg/test-types.c: Add checks comparing aligned types.
---
gcc/jit/jit-recording.h | 28 +---
gcc/testsuite/jit.dg/test-types.c | 10 +++---
2 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
index 4a8082991fb..97f39f3fc98 100644
--- a/gcc/jit/jit-recording.h
+++ b/gcc/jit/jit-recording.h
@@ -555,6 +555,14 @@ public:
virtual bool is_same_type_as (type *other)
{
+if (is_int ()
+ && other->is_int ()
+ && get_size () == other->get_size ()
+ && is_signed () == other->is_signed ())
+{
+ /* LHS (this) is an integer of the same size and sign as rtype. */
+ return true;
+}
return this == other;
}
@@ -571,6 +579,7 @@ public:
virtual type *is_volatile () { return NULL; }
virtual type *is_restrict () { return NULL; }
virtual type *is_const () { return NULL; }
+ virtual type *is_aligned () { return NULL; }
virtual type *is_array () = 0;
virtual struct_ *is_struct () { return NULL; }
virtual bool is_union () const { return false; }
@@ -625,13 +634,6 @@ public:
accept it: */
return true;
}
- } else if (is_int ()
- && rtype->is_int ()
- && get_size () == rtype->get_size ()
- && is_signed () == rtype->is_signed ())
- {
- /* LHS (this) is an integer of the same size and sign as rtype. */
- return true;
}
return type::accepts_writes_from (rtype);
@@ -805,6 +807,18 @@ public:
: decorated_type (other_type),
m_alignment_in_bytes (alignment_in_bytes) {}
+ bool is_same_type_as (type *other) final override
+ {
+// TODO: check if outermost alignment is equal?
+if (!other->is_aligned ())
+{
+ return m_other_type->is_same_type_as (other);
+}
+return m_other_type->is_same_type_as (other->is_aligned ());
+ }
+
+ type *is_aligned () final override { return m_other_type; }
+
/* Strip off the alignment, giving the underlying type. */
type *unqualified () final override { return m_other_type; }
diff --git a/gcc/testsuite/jit.dg/test-types.c b/gcc/testsuite/jit.dg/test-types.c
index a01944e35fa..c2f4d2bcb3d 100644
--- a/gcc/testsuite/jit.dg/test-types.c
+++ b/gcc/testsuite/jit.dg/test-types.c
@@ -485,11 +485,15 @@ verify_code (gcc_jit_context *ctxt, gcc_jit_result *result)
CHECK_VALUE (z.m_FILE_ptr, stderr);
+ gcc_jit_type *long_type = gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_LONG);
+ gcc_jit_type *int64_type = gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_INT64_T);
if (sizeof(long) == 8)
-CHECK (gcc_jit_compatible_types (
- gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_LONG),
- gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_INT64_T)));
+CHECK (gcc_jit_compatible_types (long_type, int64_type));
CHECK_VALUE (gcc_jit_type_get_size (gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_FLOAT)), sizeof (float));
CHECK_VALUE (gcc_jit_type_get_size (gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_DOUBLE)), sizeof (double));
+
+ gcc_jit_type *aligned_long = gcc_jit_type_get_aligned (long_type, 4);
+ gcc_jit_type *aligned_int64 = gcc_jit_type_get_aligned (int64_type, 4);
+ CHECK (gcc_jit_compatible_types (aligned_long, aligned_int64));
}
--
2.43.0
Re: [PATCH] libgccjit: Add type checks in gcc_jit_block_add_assignment_op
Hi.
Here's the updated patch.
Thanks.
On Thu, 2023-12-07 at 20:15 -0500, David Malcolm wrote:
> On Thu, 2023-12-07 at 17:34 -0500, Antoni Boucher wrote:
> > Hi.
> > This patch adds checks gcc_jit_block_add_assignment_op to make sure
> > it
> > is only ever called on numeric types.
> >
> > With the previous patch, this might require a change to also allow
> > vector types here.
> >
> > Thanks for the review.
>
> Thanks for the patch.
>
> [...snip...]
>
> > @@ -2890,6 +2900,17 @@ gcc_jit_block_add_assignment_op
> > (gcc_jit_block *block,
> > lvalue->get_type ()->get_debug_string (),
> > rvalue->get_debug_string (),
> > rvalue->get_type ()->get_debug_string ());
> > + // TODO: check if it is a numeric vector?
> > + RETURN_IF_FAIL_PRINTF3 (
> > + lvalue->get_type ()->is_numeric () && rvalue->get_type ()-
> > >is_numeric (), ctxt, loc,
> > + "gcc_jit_block_add_assignment_op %s has non-numeric lvalue %s
> > (type: %s)",
> > + gcc::jit::binary_op_reproducer_strings[op],
> > + lvalue->get_debug_string (), lvalue->get_type ()-
> > >get_debug_string ());
>
> The condition being tested here should probably just be:
>
> lvalue->get_type ()->is_numeric ()
>
> since otherwise if the lvalue's type is numeric and the rvalue's type
> fails to be, then the user would incorrectly get a message about the
> lvalue.
>
> > + RETURN_IF_FAIL_PRINTF3 (
> > + rvalue->get_type ()->is_numeric () && rvalue->get_type ()-
> > >is_numeric (), ctxt, loc,
> > + "gcc_jit_block_add_assignment_op %s has non-numeric rvalue %s
> > (type: %s)",
> > + gcc::jit::binary_op_reproducer_strings[op],
> > + rvalue->get_debug_string (), rvalue->get_type ()-
> > >get_debug_string ());
>
> The condition being tested here seems to have a redundant repeated:
> && rvalue->get_type ()->is_numeric ()
>
> Am I missing something, or is that a typo?
>
> [...snip...]
>
> The patch is OK otherwise.
>
> Thanks
> Dave
>
>
>
From a93b029db4622ff6385715ff9cdaf1be5ffa5657 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Wed, 18 Oct 2023 18:33:18 -0400
Subject: [PATCH] libgccjit: Add type checks in gcc_jit_block_add_assignment_op
gcc/jit/ChangeLog:
* libgccjit.cc (RETURN_IF_FAIL_PRINTF3): New macro.
(gcc_jit_block_add_assignment_op): Add numeric checks.
gcc/testsuite/ChangeLog:
* jit.dg/test-error-bad-assignment-op.c: New test.
---
gcc/jit/libgccjit.cc | 21 +++
.../jit.dg/test-error-bad-assignment-op.c | 57 +++
2 files changed, 78 insertions(+)
create mode 100644 gcc/testsuite/jit.dg/test-error-bad-assignment-op.c
diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
index 0451b4df7f9..10d23e7fcf6 100644
--- a/gcc/jit/libgccjit.cc
+++ b/gcc/jit/libgccjit.cc
@@ -267,6 +267,16 @@ struct gcc_jit_extended_asm : public gcc::jit::recording::extended_asm
}\
JIT_END_STMT
+#define RETURN_IF_FAIL_PRINTF3(TEST_EXPR, CTXT, LOC, ERR_FMT, A0, A1, A2) \
+ JIT_BEGIN_STMT \
+if (!(TEST_EXPR)) \
+ {\
+ jit_error ((CTXT), (LOC), "%s: " ERR_FMT, \
+ __func__, (A0), (A1), (A2)); \
+ return; \
+ }\
+ JIT_END_STMT
+
#define RETURN_IF_FAIL_PRINTF4(TEST_EXPR, CTXT, LOC, ERR_FMT, A0, A1, A2, A3) \
JIT_BEGIN_STMT \
if (!(TEST_EXPR)) \
@@ -2890,6 +2900,17 @@ gcc_jit_block_add_assignment_op (gcc_jit_block *block,
lvalue->get_type ()->get_debug_string (),
rvalue->get_debug_string (),
rvalue->get_type ()->get_debug_string ());
+ // TODO: check if it is a numeric vector?
+ RETURN_IF_FAIL_PRINTF3 (
+lvalue->get_type ()->is_numeric (), ctxt, loc,
+"gcc_jit_block_add_assignment_op %s has non-numeric lvalue %s (type: %s)",
+gcc::jit::binary_op_reproducer_strings[op],
+lvalue->get_debug_string (), lvalue->get_type ()->get_debug_string ());
+ RETURN_IF_FAIL_PRINTF3 (
+rvalue->get_type ()->is_numeric (), ctxt, loc,
+"gcc_jit_block_add_assignment_op %s has non-numeric rvalue %s (type: %s)",
+gcc::jit::binary_op_reproducer_strings[op],
+rvalue->get_debug_string (), rvalue->get_type ()->get_debug_string ());
gcc::jit::recording::statement *stmt = block->add_assignment_op (loc, lvalue, op, rvalue);
diff --git a/gcc/testsuite/jit.dg/test-error-bad-assignment-op.c b/gcc/testsuite/jit.dg/test-error-bad-assignment-op.c
new file mode 100644
index 000..683ebbfb1fe
--- /dev/null
+++ b/gcc/testsuite/jit.dg/test-error-bad-assignment-op.c
@@ -0,0
[PATCH] libgccjit: Support signed char flag
Hi. This patch adds support for the -fsigned-char flag. I'm not sure how to test it since I stumbled upon this bug when I found this other bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863) which is now fixed. Any idea how I could test this patch? Thanks for the review. From 45719be81ab71983ab10ecb67139eaf02955e4db Mon Sep 17 00:00:00 2001 From: Antoni Boucher Date: Mon, 3 Oct 2022 19:11:39 -0400 Subject: [PATCH] libgccjit: Support signed char flag gcc/jit/ChangeLog: * dummy-frontend.cc (jit_langhook_init): Send flag_signed_char argument to build_common_tree_nodes. --- gcc/jit/dummy-frontend.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/jit/dummy-frontend.cc b/gcc/jit/dummy-frontend.cc index 9f71bca44b1..11615b30f40 100644 --- a/gcc/jit/dummy-frontend.cc +++ b/gcc/jit/dummy-frontend.cc @@ -607,7 +607,7 @@ jit_langhook_init (void) diagnostic_starter (global_dc) = jit_begin_diagnostic; diagnostic_finalizer (global_dc) = jit_end_diagnostic; - build_common_tree_nodes (false); + build_common_tree_nodes (flag_signed_char); build_common_builtin_nodes (); -- 2.43.0
[PATCH] libgccjit: Allow sending a const pointer as argument
Hi.
This patch adds the ability to send const pointer as argument to a
function.
Thanks for the review.
From f53c4600d8103a5612e7de6cb8205cad37421074 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Tue, 24 May 2022 17:44:53 -0400
Subject: [PATCH] libgccjit: Allow sending a const pointer as argument
gcc/jit/ChangeLog:
* jit-recording.h: Remove memento_of_get_const::accepts_writes_from.
gcc/testsuite/ChangeLog:
* jit.dg/all-non-failing-tests.h: Add test-const-pointer-argument.c.
* jit.dg/test-const-pointer-argument.c: New test.
---
gcc/jit/jit-recording.h | 6 --
gcc/testsuite/jit.dg/all-non-failing-tests.h | 10 +++
.../jit.dg/test-const-pointer-argument.c | 76 +++
3 files changed, 86 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-const-pointer-argument.c
diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
index 4a8082991fb..21aeb7d0bbd 100644
--- a/gcc/jit/jit-recording.h
+++ b/gcc/jit/jit-recording.h
@@ -720,12 +720,6 @@ public:
memento_of_get_const (type *other_type)
: decorated_type (other_type) {}
- bool accepts_writes_from (type */*rtype*/) final override
- {
-/* Can't write to a "const". */
-return false;
- }
-
/* Strip off the "const", giving the underlying type. */
type *unqualified () final override { return m_other_type; }
diff --git a/gcc/testsuite/jit.dg/all-non-failing-tests.h b/gcc/testsuite/jit.dg/all-non-failing-tests.h
index e762563f9bd..6ac9173ea7d 100644
--- a/gcc/testsuite/jit.dg/all-non-failing-tests.h
+++ b/gcc/testsuite/jit.dg/all-non-failing-tests.h
@@ -126,6 +126,13 @@
#undef create_code
#undef verify_code
+/* test-const-pointer-argument.c */
+#define create_code create_code_const_pointer_argument
+#define verify_code verify_code_const_pointer_argument
+#include "test-const-pointer-argument.c"
+#undef create_code
+#undef verify_code
+
/* test-debug-strings.c */
#define create_code create_code_debug_strings
#define verify_code verify_code_debug_strings
@@ -437,6 +444,9 @@ const struct testcase testcases[] = {
{"constants",
create_code_constants,
verify_code_constants},
+ {"const_pointer_argument",
+ create_code_const_pointer_argument,
+ verify_code_const_pointer_argument},
{"debug_strings",
create_code_debug_strings,
verify_code_debug_strings},
diff --git a/gcc/testsuite/jit.dg/test-const-pointer-argument.c b/gcc/testsuite/jit.dg/test-const-pointer-argument.c
new file mode 100644
index 000..836634f1dd0
--- /dev/null
+++ b/gcc/testsuite/jit.dg/test-const-pointer-argument.c
@@ -0,0 +1,76 @@
+#include
+#include
+#include
+#include
+
+#include "libgccjit.h"
+
+#include "harness.h"
+
+void
+create_code (gcc_jit_context *ctxt, void *user_data)
+{
+ /* Let's try to inject the equivalent of:
+
+ int test_ptr(const int* value)
+ {
+ return *foo;
+ }
+
+ int main (void)
+ {
+ int value = 10;
+ const int *ptr = &value;
+ int res = test_ptr (ptr);
+ return res;
+ }
+ */
+ gcc_jit_type *int_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_INT);
+ gcc_jit_type *int_ptr_type =
+gcc_jit_type_get_pointer (int_type);
+ gcc_jit_type *const_ptr_type =
+gcc_jit_type_get_const (int_ptr_type);
+
+ /* Build the test_ptr. */
+ gcc_jit_param *param =
+gcc_jit_context_new_param (ctxt, NULL, const_ptr_type, "value");
+ gcc_jit_function *test_ptr =
+gcc_jit_context_new_function (ctxt, NULL,
+ GCC_JIT_FUNCTION_EXPORTED,
+ int_type,
+ "test_ptr",
+ 1, ¶m,
+ 0);
+ gcc_jit_block *block = gcc_jit_function_new_block (test_ptr, NULL);
+ gcc_jit_block_end_with_return (block,
+NULL,
+gcc_jit_lvalue_as_rvalue (
+ gcc_jit_rvalue_dereference (gcc_jit_param_as_rvalue (param), NULL)));
+
+ /* Build main. */
+ gcc_jit_function *main =
+gcc_jit_context_new_function (ctxt, NULL,
+ GCC_JIT_FUNCTION_EXPORTED,
+ int_type,
+ "main",
+ 0, NULL,
+ 0);
+ gcc_jit_block *main_block = gcc_jit_function_new_block (main, NULL);
+ gcc_jit_lvalue *variable =
+gcc_jit_function_new_local (main, NULL, int_type, "value");
+ gcc_jit_lvalue *pointer =
+gcc_jit_function_new_local (main, NULL, const_ptr_type, "ptr");
+ gcc_jit_block_add_assignment (main_block, NULL, pointer,
+gcc_jit_lvalue_get_address (variable, NULL));
+ gcc_jit_rvalue *ptr_rvalue = gcc_jit_lvalue_as_rvalue (pointer);
+ gcc_jit_rvalue *res =
+gcc_jit_context_new_call (ctxt, NULL, test_ptr, 1, &ptr_rvalue);
+ gcc_jit_block_end_with_return (main_block, NULL, res);
+}
+
+void
+verify_code (gcc_jit_context *ctxt, gcc_jit_result *result)
+{
+ CHECK_NON_NULL (result);
+}
--
2.43.0
[PATCH] libgccjit: Add convert vector
Hi.
This patch adds the support for the convert vector internal function.
I'll need to double-check that making the decl a register is necessary.
Thanks for the review.
From ca4b3606c853b3425cf4ef9e88fbd5939f0e8f7c Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sat, 14 May 2022 17:24:29 -0400
Subject: [PATCH] libgccjit: Add convert vector
gcc/jit/ChangeLog:
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_26): New ABI tag.
* docs/topics/expressions.rst: Document gcc_jit_context_convert_vector.
* jit-playback.cc (convert_vector): New method.
* jit-playback.h: New method.
* jit-recording.cc (recording::context::new_convert_vector,
recording::convert_vector::replay_into,
recording::convert_vector::visit_children,
recording::convert_vector::make_debug_string,
recording::convert_vector::write_reproducer): New methods.
* jit-recording.h (class convert_vector): New class.
(context::new_convert_vector): New method.
* libgccjit.cc (gcc_jit_context_convert_vector): New function.
* libgccjit.h (gcc_jit_context_convert_vector): New function.
* libgccjit.map: New function.
gcc/testsuite/ChangeLog:
* jit.dg/all-non-failing-tests.h: New test.
* jit.dg/test-convert-vector.c: New test.
---
gcc/jit/docs/topics/compatibility.rst| 7 ++
gcc/jit/docs/topics/expressions.rst | 18 +
gcc/jit/jit-playback.cc | 31 +
gcc/jit/jit-playback.h | 5 ++
gcc/jit/jit-recording.cc | 72
gcc/jit/jit-recording.h | 34 +
gcc/jit/libgccjit.cc | 36 ++
gcc/jit/libgccjit.h | 8 +++
gcc/jit/libgccjit.map| 5 ++
gcc/testsuite/jit.dg/all-non-failing-tests.h | 10 +++
gcc/testsuite/jit.dg/test-convert-vector.c | 56 +++
11 files changed, 282 insertions(+)
create mode 100644 gcc/testsuite/jit.dg/test-convert-vector.c
diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst
index ebede440ee4..33eb1a0bc06 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -378,3 +378,10 @@ alignment of a variable:
``LIBGCCJIT_ABI_25`` covers the addition of
:func:`gcc_jit_type_get_restrict`
+
+.. _LIBGCCJIT_ABI_26:
+
+``LIBGCCJIT_ABI_26``
+
+``LIBGCCJIT_ABI_26`` covers the addition of
+:func:`gcc_jit_context_convert_vector`
diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst
index 42cfee36302..a75e69bf1f4 100644
--- a/gcc/jit/docs/topics/expressions.rst
+++ b/gcc/jit/docs/topics/expressions.rst
@@ -699,6 +699,24 @@ Type-coercion
#ifdef LIBGCCJIT_HAVE_gcc_jit_context_new_bitcast
+.. function:: gcc_jit_rvalue *
+ gcc_jit_context_convert_vector (gcc_jit_context *ctxt, \
+ gcc_jit_location *loc, \
+ gcc_jit_rvalue *vector, \
+ gcc_jit_type *type)
+
+ Given a vector rvalue, cast it to the type ``type``.
+
+ The number of elements in ``vector`` and ``type`` must match.
+ The ``type`` must be a vector type.
+
+ This entrypoint was added in :ref:`LIBGCCJIT_ABI_26`; you can test for
+ its presence using
+
+ .. code-block:: c
+
+ #ifdef LIBGCCJIT_HAVE_gcc_jit_context_convert_vector
+
Lvalues
---
diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
index 537f3b1..48901d71418 100644
--- a/gcc/jit/jit-playback.cc
+++ b/gcc/jit/jit-playback.cc
@@ -1527,6 +1527,37 @@ new_array_access (location *loc,
}
}
+/* Construct a playback::rvalue instance (wrapping a tree) for a
+ vector conversion. */
+
+playback::rvalue *
+playback::context::
+convert_vector (location *loc,
+ rvalue *vector,
+ type *type)
+{
+ gcc_assert (vector);
+ gcc_assert (type);
+
+ /* For comparison, see:
+ c/c-common.cc: c_build_vec_convert
+ */
+
+ tree t_vector = vector->as_tree ();
+
+ /* It seems IFN_VEC_CONVERT only work on registers, not on memory. */
+ if (TREE_CODE (t_vector) == VAR_DECL)
+DECL_REGISTER (t_vector) = 1;
+ tree t_result =
+build_call_expr_internal_loc (UNKNOWN_LOCATION, IFN_VEC_CONVERT,
+ type->as_tree (), 1, t_vector);
+
+ if (loc)
+set_tree_location (t_result, loc);
+
+ return new rvalue (this, t_result);
+}
+
/* Construct a tree for a field access. */
tree
diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
index b0166f8f6ce..59ffd739875 100644
--- a/gcc/jit/jit-playback.h
+++ b/gcc/jit/jit-playback.h
@@ -191,6 +191,11 @@ public:
rvalue *ptr,
rvalue *index);
+ rvalue *
+ convert_vector (location *loc,
+ rvalue *vector,
+ type *type);
+
void
set_str_option (enum gcc_jit_str_option opt,
const char *value);
diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recordi
[PATCH] libgccjit: Add missing builtins needed by optimizations
Hi.
This patch adds missing builtins needed by optimizations.
Thanks for the review.
From 5ef20748a140d3384294a4218e6db7420cef692d Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Tue, 3 Jan 2023 15:04:41 -0500
Subject: [PATCH] libgccjit: Add missing builtins needed by optimizations
gcc/jit/ChangeLog:
* jit-builtins.cc (ensure_optimization_builtins_exist): Add
popcount builtins.
gcc/testsuite/ChangeLog:
* jit.dg/all-non-failing-tests.h: New test.
* jit.dg/test-popcount.c: New test.
---
gcc/jit/jit-builtins.cc | 3 +
gcc/testsuite/jit.dg/all-non-failing-tests.h | 10 +++
gcc/testsuite/jit.dg/test-popcount.c | 84
3 files changed, 97 insertions(+)
create mode 100644 gcc/testsuite/jit.dg/test-popcount.c
diff --git a/gcc/jit/jit-builtins.cc b/gcc/jit/jit-builtins.cc
index fdd0739789d..c84f2613f6a 100644
--- a/gcc/jit/jit-builtins.cc
+++ b/gcc/jit/jit-builtins.cc
@@ -609,6 +609,9 @@ builtins_manager::ensure_optimization_builtins_exist ()
We can't loop through all of the builtin_data array, we don't
support all types yet. */
(void)get_builtin_function_by_id (BUILT_IN_TRAP);
+ (void)get_builtin_function_by_id (BUILT_IN_POPCOUNT);
+ (void)get_builtin_function_by_id (BUILT_IN_POPCOUNTL);
+ (void)get_builtin_function_by_id (BUILT_IN_POPCOUNTLL);
}
/* Playback support. */
diff --git a/gcc/testsuite/jit.dg/all-non-failing-tests.h b/gcc/testsuite/jit.dg/all-non-failing-tests.h
index e762563f9bd..b768c8977f0 100644
--- a/gcc/testsuite/jit.dg/all-non-failing-tests.h
+++ b/gcc/testsuite/jit.dg/all-non-failing-tests.h
@@ -268,6 +268,13 @@
#undef create_code
#undef verify_code
+/* test-popcount.c */
+#define create_code create_code_popcount
+#define verify_code verify_code_popcount
+#include "test-popcount.c"
+#undef create_code
+#undef verify_code
+
/* test-pr103562.c: We don't add this one, since it touches
the optimization level of the context as a whole. */
@@ -488,6 +495,9 @@ const struct testcase testcases[] = {
{"nested_loop",
create_code_nested_loop,
verify_code_nested_loop},
+ {"popcount",
+ create_code_popcount,
+ verify_code_popcount},
{"pr66700_observing_write_through_ptr",
create_code_pr66700_observing_write_through_ptr,
verify_code_pr66700_observing_write_through_ptr},
diff --git a/gcc/testsuite/jit.dg/test-popcount.c b/gcc/testsuite/jit.dg/test-popcount.c
new file mode 100644
index 000..6ad241fd2de
--- /dev/null
+++ b/gcc/testsuite/jit.dg/test-popcount.c
@@ -0,0 +1,84 @@
+#include
+#include
+#include
+#include
+
+#include "libgccjit.h"
+
+#include "harness.h"
+
+void
+create_code (gcc_jit_context *ctxt, void *user_data)
+{
+ /* Let's try to inject the equivalent of:
+int
+popcount (unsigned int x)
+{
+ int i = 0;
+ while (x)
+{
+ x &= x - 1;
+ ++i;
+}
+ return i;
+}
+ */
+ gcc_jit_type *int_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_INT);
+ gcc_jit_type *uint_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_UNSIGNED_INT);
+
+ gcc_jit_param *param_x =
+gcc_jit_context_new_param (
+ ctxt,
+ NULL,
+ uint_type, "x");
+ gcc_jit_param *params[1] = {param_x};
+ gcc_jit_function *func =
+gcc_jit_context_new_function (ctxt,
+ NULL,
+ GCC_JIT_FUNCTION_EXPORTED,
+ int_type,
+ "popcount",
+ 1, params, 0);
+
+ gcc_jit_lvalue *x = gcc_jit_param_as_lvalue (param_x);
+ gcc_jit_rvalue *x_rvalue = gcc_jit_lvalue_as_rvalue (x);
+ gcc_jit_lvalue *i =
+gcc_jit_function_new_local (func, NULL, int_type, "i");
+ gcc_jit_rvalue *zero = gcc_jit_context_zero (ctxt, int_type);
+
+ gcc_jit_block *initial =
+gcc_jit_function_new_block (func, "initial");
+ gcc_jit_block *while_block =
+gcc_jit_function_new_block (func, "while");
+
+ gcc_jit_block_add_assignment (initial, NULL, i, zero);
+ gcc_jit_block_end_with_jump (initial, NULL, while_block);
+
+ gcc_jit_block *after =
+gcc_jit_function_new_block (func, "after");
+
+ gcc_jit_block *while_body =
+gcc_jit_function_new_block (func, "while_body");
+ gcc_jit_rvalue *uzero = gcc_jit_context_zero (ctxt, uint_type);
+ gcc_jit_rvalue *cmp =
+gcc_jit_context_new_comparison (ctxt, NULL, GCC_JIT_COMPARISON_NE, x_rvalue, uzero);
+ gcc_jit_block_end_with_conditional (while_block, NULL, cmp, while_body, after);
+
+ gcc_jit_rvalue *uone = gcc_jit_context_one (ctxt, uint_type);
+ gcc_jit_rvalue *sub = gcc_jit_context_new_binary_op (ctxt, NULL, GCC_JIT_BINARY_OP_MINUS, uint_type, x_rvalue, uone);
+ gcc_jit_block_add_assignment_op (while_body, NULL, x, GCC_JIT_BINARY_OP_BITWISE_AND, sub);
+
+ gcc_jit_rvalue *one = gcc_jit_context_one (ctxt, int_type);
+ gcc_jit_block_add_assignment_op (while_body, NULL, i, GCC_JIT_BINARY_OP_PLUS, one);
+ gcc_jit_block_end_with_jump (whi
[PATCH] libgccjit: Implement sizeof operator
Hi.
This patch adds the support of the sizeof operator.
I was wondering if this new API entrypoint should take a location as a
parameter. What do you think?
Thanks for the review.
From e86e00efae450f04bc92ae6e4e61cf92c38d9b7d Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Tue, 19 Sep 2023 22:10:47 -0400
Subject: [PATCH] libgccjit: Implement sizeof operator
gcc/jit/ChangeLog:
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_26): New ABI tag.
* docs/topics/expressions.rst: Document gcc_jit_context_new_sizeof.
* jit-playback.cc (new_sizeof): New method.
* jit-playback.h (new_sizeof): New method.
* jit-recording.cc (recording::context::new_sizeof,
recording::memento_of_new_sizeof::replay_into,
recording::memento_of_new_sizeof::make_debug_string,
recording::memento_of_new_sizeof::write_reproducer): New methods.
* jit-recording.h (class memento_of_new_sizeof): New class.
* libgccjit.cc (gcc_jit_context_new_sizeof): New function.
* libgccjit.h (gcc_jit_context_new_sizeof): New function.
* libgccjit.map: New function.
gcc/testsuite/ChangeLog:
* jit.dg/all-non-failing-tests.h: New test.
* jit.dg/test-sizeof.c: New test.
---
gcc/jit/docs/topics/compatibility.rst| 7 +++
gcc/jit/docs/topics/expressions.rst | 14 ++
gcc/jit/jit-playback.cc | 10
gcc/jit/jit-playback.h | 3 ++
gcc/jit/jit-recording.cc | 52
gcc/jit/jit-recording.h | 28 +++
gcc/jit/libgccjit.cc | 18 +++
gcc/jit/libgccjit.h | 12 +
gcc/jit/libgccjit.map| 5 ++
gcc/testsuite/jit.dg/all-non-failing-tests.h | 10
gcc/testsuite/jit.dg/test-sizeof.c | 50 +++
11 files changed, 209 insertions(+)
create mode 100644 gcc/testsuite/jit.dg/test-sizeof.c
diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst
index ebede440ee4..00cf88a4666 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -378,3 +378,10 @@ alignment of a variable:
``LIBGCCJIT_ABI_25`` covers the addition of
:func:`gcc_jit_type_get_restrict`
+
+.. _LIBGCCJIT_ABI_26:
+
+``LIBGCCJIT_ABI_26``
+
+``LIBGCCJIT_ABI_26`` covers the addition of
+:func:`gcc_jit_context_new_sizeof`
diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst
index 42cfee36302..a18909f4890 100644
--- a/gcc/jit/docs/topics/expressions.rst
+++ b/gcc/jit/docs/topics/expressions.rst
@@ -126,6 +126,20 @@ Simple expressions
underlying string, so it is valid to pass in a pointer to an on-stack
buffer.
+.. function:: gcc_jit_rvalue *\
+ gcc_jit_context_new_sizeof (gcc_jit_context *ctxt, \
+ gcc_jit_type *type)
+
+ Generate an rvalue that is equal to the size of ``type``.
+
+ The parameter ``type`` must be non-NULL.
+
+ This is equivalent to this C code:
+
+ .. code-block:: c
+
+ sizeof (type)
+
Constructor expressions
***
diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
index 537f3b1..09b5e89942f 100644
--- a/gcc/jit/jit-playback.cc
+++ b/gcc/jit/jit-playback.cc
@@ -974,6 +974,16 @@ new_rvalue_from_const (type *type,
/* Construct a playback::rvalue instance (wrapping a tree). */
+playback::rvalue *
+playback::context::
+new_sizeof (type *type)
+{
+ tree inner = TYPE_SIZE_UNIT (type->as_tree ());
+ return new rvalue (this, inner);
+}
+
+/* Construct a playback::rvalue instance (wrapping a tree). */
+
playback::rvalue *
playback::context::
new_string_literal (const char *value)
diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
index b0166f8f6ce..a537a5433c3 100644
--- a/gcc/jit/jit-playback.h
+++ b/gcc/jit/jit-playback.h
@@ -139,6 +139,9 @@ public:
new_rvalue_from_const (type *type,
HOST_TYPE value);
+ rvalue *
+ new_sizeof (type *type);
+
rvalue *
new_string_literal (const char *value);
diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc
index 9b5b8005ebe..c1e4e68cae6 100644
--- a/gcc/jit/jit-recording.cc
+++ b/gcc/jit/jit-recording.cc
@@ -1076,6 +1076,21 @@ recording::context::new_global_init_rvalue (lvalue *variable,
gbl->set_rvalue_init (init); /* Needed by the global for write dump. */
}
+/* Create a recording::memento_of_sizeof instance and add it
+ to this context's list of mementos.
+
+ Implements the post-error-checking part of
+ gcc_jit_context_new_sizeof. */
+
+recording::rvalue *
+recording::context::new_sizeof (recording::type *type)
+{
+ recording::rvalue *result =
+new memento_of_new_sizeof (this, NULL, type);
+ record (result);
+ return result;
+}
+
/* Create a recording::memento_of_new_string_literal instance and add it
to this context's list of mementos.
@@
[PATCH] libgccjit: Add support for setting the comment ident
Hi.
This patch adds support for setting the comment ident (analogous to
#ident "comment" in C).
Thanks for the review.
From 1af4e77540001cce8c30e86040c1da785e435810 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Fri, 27 Oct 2023 17:36:03 -0400
Subject: [PATCH] libgccjit: Add support for setting the comment ident
gcc/jit/ChangeLog:
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_26): New ABI tag.
* docs/topics/contexts.rst: Document gcc_jit_context_set_output_ident.
* jit-playback.cc (set_output_ident): New method.
* jit-playback.h (set_output_ident): New method.
* jit-recording.cc (recording::context::set_output_ident,
recording::output_ident::output_ident,
recording::output_ident::~output_ident,
recording::output_ident::replay_into,
recording::output_ident::make_debug_string,
recording::output_ident::write_reproducer): New methods.
* jit-recording.h (class output_ident): New class.
* libgccjit.cc (gcc_jit_context_set_output_ident): New function.
* libgccjit.h (gcc_jit_context_set_output_ident): New function.
* libgccjit.map: New function.
gcc/testsuite/ChangeLog:
* jit.dg/all-non-failing-tests.h: New test.
* jit.dg/test-output-ident.c: New test.
---
gcc/jit/docs/topics/compatibility.rst| 7 +++
gcc/jit/docs/topics/contexts.rst | 22
gcc/jit/jit-playback.cc | 7 +++
gcc/jit/jit-playback.h | 3 ++
gcc/jit/jit-recording.cc | 53
gcc/jit/jit-recording.h | 22
gcc/jit/libgccjit.cc | 15 ++
gcc/jit/libgccjit.h | 6 +++
gcc/jit/libgccjit.map| 5 ++
gcc/testsuite/jit.dg/all-non-failing-tests.h | 3 ++
gcc/testsuite/jit.dg/test-output-ident.c | 23 +
11 files changed, 166 insertions(+)
create mode 100644 gcc/testsuite/jit.dg/test-output-ident.c
diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst
index ebede440ee4..c4de996506b 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -378,3 +378,10 @@ alignment of a variable:
``LIBGCCJIT_ABI_25`` covers the addition of
:func:`gcc_jit_type_get_restrict`
+
+.. _LIBGCCJIT_ABI_26:
+
+``LIBGCCJIT_ABI_26``
+
+``LIBGCCJIT_ABI_26`` covers the addition of
+:func:`gcc_jit_context_set_output_ident`
diff --git a/gcc/jit/docs/topics/contexts.rst b/gcc/jit/docs/topics/contexts.rst
index b22eb2aa983..c51cf5a82ea 100644
--- a/gcc/jit/docs/topics/contexts.rst
+++ b/gcc/jit/docs/topics/contexts.rst
@@ -599,3 +599,25 @@ Additional command-line options
.. code-block:: c
#ifdef LIBGCCJIT_HAVE_gcc_jit_context_add_driver_option
+
+Output options
+**
+
+.. function:: void gcc_jit_context_set_output_ident (gcc_jit_context *ctxt,\
+ const char* output_ident)
+
+ Set the identifier to write in the .comment section of the output file to
+ ``output_ident``. Analogous to:
+
+ .. code-block:: c
+
+ #ident "My comment"
+
+ in C.
+
+ This entrypoint was added in :ref:`LIBGCCJIT_ABI_26`; you can test for
+ its presence using
+
+ .. code-block:: c
+
+ #ifdef LIBGCCJIT_HAVE_gcc_jit_context_set_output_ident
diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
index 537f3b1..243a9fdf972 100644
--- a/gcc/jit/jit-playback.cc
+++ b/gcc/jit/jit-playback.cc
@@ -319,6 +319,13 @@ get_type (enum gcc_jit_types type_)
return new type (type_node);
}
+void
+playback::context::
+set_output_ident (const char* ident)
+{
+ targetm.asm_out.output_ident (ident);
+}
+
/* Construct a playback::type instance (wrapping a tree) for the given
array type. */
diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
index b0166f8f6ce..c6ed15517e9 100644
--- a/gcc/jit/jit-playback.h
+++ b/gcc/jit/jit-playback.h
@@ -66,6 +66,9 @@ public:
type *
get_type (enum gcc_jit_types type);
+ void
+ set_output_ident (const char* ident);
+
type *
new_array_type (location *loc,
type *element_type,
diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc
index 9b5b8005ebe..d86616f45ef 100644
--- a/gcc/jit/jit-recording.cc
+++ b/gcc/jit/jit-recording.cc
@@ -1346,6 +1346,13 @@ recording::context::set_str_option (enum gcc_jit_str_option opt,
log_str_option (opt);
}
+void
+recording::context::set_output_ident (const char *ident)
+{
+ recording::output_ident *memento = new output_ident (this, ident);
+ record (memento);
+}
+
/* Set the given integer option for this context, or add an error if
it's not recognized.
@@ -2185,6 +2192,52 @@ recording::string::write_reproducer (reproducer &)
/* Empty. */
}
+/* The implementation of class gcc::jit::recording::output_ident. */
+
+/* Constructor for gcc::jit::recording::output_ident, allocating a
+ copy of
Re: [PATCH] libgccjit: Add ability to get CPU features
See more answers below. 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. This detects the capabilities of the host that libgccjit is currently running on. > > > > > > > > > > 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. To add to this, libgccjit will just report that the feature is not detected when cross-compiling. > > > > > > > > > > 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 > > > > > > > > > > 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. It does build. > > > > > > > > > > [...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: Fix GGC segfault when using -flto
Here's the updated patch.
The failure was due to the test being in the test array while it should
not have been there since it changes the context.
Thanks for the review.
On Sun, 2023-11-12 at 18:03 -0500, David Malcolm wrote:
> On Fri, 2023-11-10 at 18:14 -0500, David Malcolm wrote:
> > On Fri, 2023-11-10 at 11:02 -0500, Antoni Boucher wrote:
> > > Hi.
> > > This patch fixes the segfault when using -flto with libgccjit
> > > (bug
> > > 111396).
> > >
> > > You mentioned in bugzilla that this didn't fix the reproducer for
> > > you,
> >
> > Rereading https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111396 it
> > looks
> > like all I tested back in August was your reproducer; I didn't yet
> > test
> > your patch.
> >
> > > but it does for me.
> > > At first, the test case would not pass, but running "make
> > > install"
> > > made
> > > it pass.
> > > Not sure if this is normal.
> > >
> > > Could you please check if this fixes the issue on your side as
> > > well?
> > > Since this patch changes files outside of gcc/jit, what tests
> > > should
> > > I
> > > run to make sure it didn't break anything?
> >
> > I'm trying your patch in my tester now.
>
> Bootstrapped with x86_64-pc-linux-gnu/build. No changes to non-jit
> tests, but had this effect on jit.sum:
>
> Changes to jit.sum
> --
>
> FAIL: 9->11 (+2)
> PASS: 14827->11434 (-3393)
>
> apparently due to:
> FAIL: test-combination.c.exe iteration 1 of 5:
> verify_code_accessing_bitfield: result is NULL
> FAIL: test-combination.c.exe killed: 997638 exp16 0 0 CHILDKILLED
> SIGABRT SIGABRT
>
> >
> > BTW, we shouldn't add test-ggc-bugfix to since it adds options to
> > the
> > context: this would affect all the other tests.
>
>
From 4024224e57a465e414fa26d21a57e188aadb349c Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Fri, 10 Nov 2023 09:52:32 -0500
Subject: [PATCH] libgccjit: Fix GGC segfault when using -flto
gcc/ChangeLog:
PR jit/111396
* ipa-fnsummary.cc (ipa_fnsummary_cc_finalize): Call
ipa_free_size_summary.
* ipa-icf.cc (ipa_icf_cc_finalize): New function.
* ipa-profile.cc (ipa_profile_cc_finalize): New function.
* ipa-prop.cc (ipa_prop_cc_finalize): New function.
* ipa-prop.h (ipa_prop_cc_finalize): New function.
* ipa-sra.cc (ipa_sra_cc_finalize): New function.
* ipa-utils.h (ipa_profile_cc_finalize, ipa_icf_cc_finalize,
ipa_sra_cc_finalize): New functions.
* toplev.cc (toplev::finalize): Call ipa_icf_cc_finalize,
ipa_prop_cc_finalize, ipa_profile_cc_finalize and
ipa_sra_cc_finalize
Include ipa-utils.h.
gcc/testsuite/ChangeLog:
PR jit/111396
* jit.dg/all-non-failing-tests.h: Add note about test-ggc-bugfix.
* jit.dg/test-ggc-bugfix.c: New test.
---
gcc/ipa-fnsummary.cc | 1 +
gcc/ipa-icf.cc | 9 ++
gcc/ipa-profile.cc | 10 ++
gcc/ipa-prop.cc | 18 +++
gcc/ipa-prop.h | 2 ++
gcc/ipa-sra.cc | 12 +++
gcc/ipa-utils.h | 7
gcc/testsuite/jit.dg/all-non-failing-tests.h | 4 +++
gcc/testsuite/jit.dg/test-ggc-bugfix.c | 34
gcc/toplev.cc| 5 +++
10 files changed, 102 insertions(+)
create mode 100644 gcc/testsuite/jit.dg/test-ggc-bugfix.c
diff --git a/gcc/ipa-fnsummary.cc b/gcc/ipa-fnsummary.cc
index a2495ffe63e..34e011c4b50 100644
--- a/gcc/ipa-fnsummary.cc
+++ b/gcc/ipa-fnsummary.cc
@@ -5090,4 +5090,5 @@ void
ipa_fnsummary_cc_finalize (void)
{
ipa_free_fn_summary ();
+ ipa_free_size_summary ();
}
diff --git a/gcc/ipa-icf.cc b/gcc/ipa-icf.cc
index bbdfd445397..ba6c6899ce6 100644
--- a/gcc/ipa-icf.cc
+++ b/gcc/ipa-icf.cc
@@ -3657,3 +3657,12 @@ make_pass_ipa_icf (gcc::context *ctxt)
{
return new ipa_icf::pass_ipa_icf (ctxt);
}
+
+/* Reset all state within ipa-icf.cc so that we can rerun the compiler
+ within the same process. For use by toplev::finalize. */
+
+void
+ipa_icf_cc_finalize (void)
+{
+ ipa_icf::optimizer = NULL;
+}
diff --git a/gcc/ipa-profile.cc b/gcc/ipa-profile.cc
index 78a40a118bc..8083b8195a8 100644
--- a/gcc/ipa-profile.cc
+++ b/gcc/ipa-profile.cc
@@ -1065,3 +1065,13 @@ make_pass_ipa_profile (gcc::context *ctxt)
{
return new pass_ipa_profile (ctxt);
}
+
+/* Reset all state within ipa-profile.cc so that we can rerun the compiler
+ within the same process. For use by toplev::finalize. */
+
+void
+ipa_profile_cc_finalize (void)
+{
+ delete call_sums;
+ call_sums = NULL;
+}
diff --git a/gcc/ipa-prop.cc b/gcc/ipa
Re: [PATCH] libgccjit: Add vector permutation and vector access operations
All of these are fixed in this new patch.
Thanks for the review.
On Mon, 2023-11-20 at 18:05 -0500, David Malcolm wrote:
> On Fri, 2023-11-17 at 17:36 -0500, Antoni Boucher wrote:
> > Hi.
> > This patch adds a vector permutation and vector access operations
> > (bug
> > 112602).
> >
> > This was split from this patch:
> > https://gcc.gnu.org/pipermail/jit/2023q1/001606.html
> >
>
> Thanks for the patch.
>
> Overall, looks good, but 3 minor nitpicks:
>
> [...snip...]
>
> > diff --git a/gcc/jit/docs/topics/compatibility.rst
> > b/gcc/jit/docs/topics/compatibility.rst
> > index ebede440ee4..a764e3968d1 100644
> > --- a/gcc/jit/docs/topics/compatibility.rst
> > +++ b/gcc/jit/docs/topics/compatibility.rst
> > @@ -378,3 +378,13 @@ alignment of a variable:
> >
> > ``LIBGCCJIT_ABI_25`` covers the addition of
> > :func:`gcc_jit_type_get_restrict`
> > +
> > +
> > +.. _LIBGCCJIT_ABI_26:
> > +
> > +``LIBGCCJIT_ABI_26``
> > +
> > +``LIBGCCJIT_ABI_26`` covers the addition of functions to
> > manipulate vectors:
> > +
> > + * :func:`gcc_jit_context_new_rvalue_vector_perm`
> > + * :func:`gcc_jit_context_new_vector_access`
> > diff --git a/gcc/jit/docs/topics/expressions.rst
> > b/gcc/jit/docs/topics/expressions.rst
> > index 42cfee36302..4a45aa13f5c 100644
> > --- a/gcc/jit/docs/topics/expressions.rst
> > +++ b/gcc/jit/docs/topics/expressions.rst
> > @@ -295,6 +295,35 @@ Vector expressions
> >
> > #ifdef LIBGCCJIT_HAVE_gcc_jit_context_new_rvalue_from_vector
> >
> > +.. function:: gcc_jit_rvalue * \
> > + gcc_jit_context_new_rvalue_vector_perm
> > (gcc_jit_context *ctxt, \
> > +
> > gcc_jit_location *loc, \
> > +
> > gcc_jit_rvalue *elements1, \
> > +
> > gcc_jit_rvalue *elements2, \
> > +
> > gcc_jit_rvalue *mask);
> > +
> > + Build a permutation of two vectors.
> > +
> > + "elements1" and "elements2" should have the same type.
> > + The length of "mask" and "elements1" should be the same.
> > + The element type of "mask" should be integral.
> > + The size of the element type of "mask" and "elements1" should
> > be the same.
> > +
> > + This entrypoint was added in :ref:`LIBGCCJIT_ABI_25`; you can
> > test for
> ^^
> Should be 26
>
> [...snip...]
>
> > Unary Operations
> >
> >
> > @@ -1020,3 +1049,27 @@ Field access is provided separately for both
> > lvalues and rvalues.
> > PTR[INDEX]
> >
> > in C (or, indeed, to ``PTR + INDEX``).
> > +
> > +.. function:: gcc_jit_lvalue *\
> > + gcc_jit_context_new_vector_access (gcc_jit_context
> > *ctxt,\
> > + gcc_jit_location
> > *loc,\
> > + gcc_jit_rvalue
> > *vector,\
> > + gcc_jit_rvalue
> > *index)
> > +
> > + Given an rvalue of vector type ``T __attribute__
> > ((__vector_size__ (SIZE)))``, get the element `T` at
> > + the given index.
> > +
> > + This entrypoint was added in :ref:`LIBGCCJIT_ABI_25`; you can
> > test for
> ^^
>
> Likewise here.
>
> [...snip...]
>
> > @@ -4071,6 +4107,79 @@ gcc_jit_context_new_rvalue_from_vector
> > (gcc_jit_context *ctxt,
> > (gcc::jit::recording::rvalue **)elements);
> > }
> >
> > +/* Public entrypoint. See description in libgccjit.h.
> > +
> > + After error-checking, the real work is done by the
> > + gcc::jit::recording::context::new_rvalue_vector_perm method, in
> > + jit-recording.cc. */
> > +
> > +gcc_jit_rvalue *
> > +gcc_jit_context_new_rvalue_vector_perm (gcc_jit_context *ctxt,
> > + gcc_jit_location *loc,
> > + gcc_jit_rvalue *elements1,
> > + gcc_jit_rvalue *elements2,
> > + gcc_jit_rvalue *mask)
> > +{
> > + RETURN_NULL_IF_FAIL (ctxt, NULL, l
Re: [PATCH] libgccjit: Add support for the type bfloat16
David: ping. On Thu, 2023-11-16 at 17:20 -0500, Antoni Boucher wrote: > I forgot to attach the patch. > > On Thu, 2023-11-16 at 17:19 -0500, Antoni Boucher wrote: > > Hi. > > This patch adds the support for the type bfloat16 (bug 112574). > > > > This was asked to be splitted from a another patch sent here: > > https://gcc.gnu.org/pipermail/jit/2023q1/001607.html > > > > Thanks for the review. >
Re: [PATCH] Add support for function attributes and variable attributes
It seems like you forgot to prefix the commit message with "libgccjit: ". On Thu, 2023-11-30 at 10:55 +0100, Guillaume Gomez wrote: > Ping David. :) > > Le jeu. 23 nov. 2023 à 22:59, Antoni Boucher a > écrit : > > David: I found back the comment you made. Here it is: > > > > I see you have patches to add function and variable attributes; > > I > > wonder if this would be cleaner internally if there was a > > recording::attribute class, rather than the std::pair currently > > in > > use > > (some attributes have int arguments rather than string, others > > have > > multiple args). > > > > I also wondered if a "gcc_jit_attribute" type could be exposed > > to > > the > > user, e.g.: > > > > attr1 = gcc_jit_context_new_attribute (ctxt, "noreturn"); > > attr2 = gcc_jit_context_new_attribute_with_string (ctxt, > > "alias", > > "__foo"); > > gcc_jit_function_add_attribute (ctxt, attr1); > > gcc_jit_function_add_attribute (ctxt, attr2); > > > > or somesuch? But I think the API you currently have is OK. > > > > On Thu, 2023-11-23 at 22:52 +0100, Guillaume Gomez wrote: > > > Ping David. :) > > > > > > Le mer. 15 nov. 2023 à 17:56, Antoni Boucher a > > > écrit : > > > > > > > > David: another thing I remember you mentioned when you reviewed > > > > an > > > > earlier version of this patch is the usage of `std::pair`. > > > > I can't find where you said that, but I remember you mentioned > > > > that > > > > we > > > > should use a struct instead. > > > > Can you please elaborate again? > > > > Thanks. > > > > > > > > On Wed, 2023-11-15 at 17:53 +0100, Guillaume Gomez wrote: > > > > > Hi, > > > > > > > > > > This patch adds the (incomplete) support for function and > > > > > variable > > > > > attributes. The added attributes are the ones we're using in > > > > > rustc_codegen_gcc but all the groundwork is done to add more > > > > > (and > > > > > we > > > > > will very likely add more as we didn't add all the ones we > > > > > use in > > > > > rustc_codegen_gcc yet). > > > > > > > > > > The only big question with this patch is about `inline`. We > > > > > currently > > > > > handle it as an attribute because it is more convenient for > > > > > us > > > > > but is > > > > > it ok or should we create a separate function to mark a > > > > > function > > > > > as > > > > > inlined? > > > > > > > > > > Thanks in advance for the review. > > > > > >
[PATCH] libgccjit: Fix get_size of size_t
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.
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.
Thanks for the review.
From 37d25e55a0c79893c7ea7f4cb9f0842b8a9b4906 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Fri, 3 Nov 2023 17:49:18 -0400
Subject: [PATCH] libgccjit: Fix get_size of size_t
gcc/jit/ChangeLog:
PR jit/112910
* jit-recording.cc (recording::memento_of_get_type::get_size):
Correctly compute the size of size_t.
---
gcc/jit/jit-recording.cc | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc
index 9b5b8005ebe..ea1f76d4415 100644
--- a/gcc/jit/jit-recording.cc
+++ b/gcc/jit/jit-recording.cc
@@ -2392,7 +2392,34 @@ recording::memento_of_get_type::get_size ()
size = LONG_DOUBLE_TYPE_SIZE;
break;
case GCC_JIT_TYPE_SIZE_T:
- size = MAX_BITS_PER_WORD;
+ /* Compare with tree.cc's build_common_tree_nodes. */
+ if (strcmp (SIZE_TYPE, "unsigned int") == 0)
+size = INT_TYPE_SIZE;
+ else if (strcmp (SIZE_TYPE, "long unsigned int") == 0)
+size = LONG_TYPE_SIZE;
+ else if (strcmp (SIZE_TYPE, "long long unsigned int") == 0)
+size = LONG_LONG_TYPE_SIZE;
+ else if (strcmp (SIZE_TYPE, "short unsigned int") == 0)
+size = SHORT_TYPE_SIZE;
+ else
+ {
+int i;
+
+for (i = 0; i < NUM_INT_N_ENTS; i++)
+ if (int_n_enabled_p[i])
+ {
+fprintf (stderr, "%d\n", i);
+char name[50], altname[50];
+sprintf (name, "__int%d unsigned", int_n_data[i].bitsize);
+sprintf (altname, "__int%d__ unsigned", int_n_data[i].bitsize);
+
+if (strcmp (name, SIZE_TYPE) == 0 || strcmp (altname, SIZE_TYPE) == 0)
+{
+ return int_n_data[i].bitsize / BITS_PER_UNIT;
+}
+ }
+gcc_unreachable ();
+ }
break;
default:
/* As this function is called by
--
2.43.0
[PATCH] libgccjit: Make new_array_type take unsigned long
Hi.
This patches update gcc_jit_context_new_array_type to take the size as
an unsigned long instead of a int, to allow creating bigger array
types.
I haven't written the ChangeLog yet because I wasn't sure it's allowed
to change the type of a function like that.
If it isn't, what would you suggest?
Thanks.
From 59b7e8af99d5f680e6d622631b1b75609fe1b982 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sat, 4 Mar 2023 00:44:49 -0500
Subject: [PATCH] libgccjit: Make new_array_type take unsigned long
---
gcc/jit/jit-playback.cc | 2 +-
gcc/jit/jit-playback.h | 2 +-
gcc/jit/jit-recording.cc | 6 +++---
gcc/jit/jit-recording.h | 8
gcc/jit/libgccjit.cc | 2 +-
gcc/jit/libgccjit.h | 2 +-
6 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
index 537f3b1..9da05b0b4b1 100644
--- a/gcc/jit/jit-playback.cc
+++ b/gcc/jit/jit-playback.cc
@@ -326,7 +326,7 @@ playback::type *
playback::context::
new_array_type (playback::location *loc,
playback::type *element_type,
- int num_elements)
+ unsigned long num_elements)
{
gcc_assert (element_type);
diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
index b0166f8f6ce..848cb5f25e8 100644
--- a/gcc/jit/jit-playback.h
+++ b/gcc/jit/jit-playback.h
@@ -69,7 +69,7 @@ public:
type *
new_array_type (location *loc,
type *element_type,
- int num_elements);
+ unsigned long num_elements);
field *
new_field (location *loc,
diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc
index 9b5b8005ebe..4ab4f0df25b 100644
--- a/gcc/jit/jit-recording.cc
+++ b/gcc/jit/jit-recording.cc
@@ -840,7 +840,7 @@ recording::context::get_int_type (int num_bytes, int is_signed)
recording::type *
recording::context::new_array_type (recording::location *loc,
recording::type *element_type,
-int num_elements)
+unsigned long num_elements)
{
if (struct_ *s = element_type->dyn_cast_struct ())
if (!s->get_fields ())
@@ -3113,7 +3113,7 @@ recording::string *
recording::array_type::make_debug_string ()
{
return string::from_printf (m_ctxt,
- "%s[%d]",
+ "%s[%ld]",
m_element_type->get_debug_string (),
m_num_elements);
}
@@ -3129,7 +3129,7 @@ recording::array_type::write_reproducer (reproducer &r)
"gcc_jit_context_new_array_type (%s,\n"
"%s, /* gcc_jit_location *loc */\n"
"%s, /* gcc_jit_type *element_type */\n"
- "%i); /* int num_elements */\n",
+ "%li); /* int num_elements */\n",
id,
r.get_identifier (get_context ()),
r.get_identifier (m_loc),
diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
index 4a8082991fb..0bb035a5ae5 100644
--- a/gcc/jit/jit-recording.h
+++ b/gcc/jit/jit-recording.h
@@ -91,7 +91,7 @@ public:
type *
new_array_type (location *loc,
type *element_type,
- int num_elements);
+ unsigned long num_elements);
field *
new_field (location *loc,
@@ -859,7 +859,7 @@ class array_type : public type
array_type (context *ctxt,
location *loc,
type *element_type,
- int num_elements)
+ unsigned long num_elements)
: type (ctxt),
m_loc (loc),
m_element_type (element_type),
@@ -873,7 +873,7 @@ class array_type : public type
bool is_bool () const final override { return false; }
type *is_pointer () final override { return NULL; }
type *is_array () final override { return m_element_type; }
- int num_elements () { return m_num_elements; }
+ unsigned long num_elements () { return m_num_elements; }
bool is_signed () const final override { return false; }
void replay_into (replayer *) final override;
@@ -885,7 +885,7 @@ class array_type : public type
private:
location *m_loc;
type *m_element_type;
- int m_num_elements;
+ unsigned long m_num_elements;
};
class function_type : public type
diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
index 0451b4df7f9..1424a5c305f 100644
--- a/gcc/jit/libgccjit.cc
+++ b/gcc/jit/libgccjit.cc
@@ -766,7 +766,7 @@ gcc_jit_type *
gcc_jit_context_new_array_type (gcc_jit_context *ctxt,
gcc_jit_location *loc,
gcc_jit_type *element_type,
-int num_elements)
+unsigned long num_elements)
{
RETURN_NULL_IF_FAIL (ctxt, NULL, loc, "NULL context");
JIT_LOG_FUNC (ctxt->get_logger ());
diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
index 749f6c24177..88399b6124d 100644
--- a/gcc/jit/libgccjit.h
+++ b/gcc/jit/libgccjit.h
@@ -661,7 +661,7 @@ extern gcc_jit_type *
gcc_jit_context_new_array_type (gcc_jit_context *ctxt,
gcc_jit_location *loc,
gcc_jit_type *element_type,
-int num_elements);
+unsigned long num_elements);
/* Struct-handling. */
--
2.43.0
[PATCH] libgccjit: Make is_int return false on vector types
Hi.
This patch changes the function is_int to return false on vector types.
Thanks for the review.
From 60ebfb998bd349ca2f05b115de5452378027e4de Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Thu, 26 Oct 2023 19:17:55 -0400
Subject: [PATCH] libgccjit: Make is_int return false on vector types
gcc/jit/ChangeLog:
* jit-recording.h (is_numeric_vector, vector_type::new_int): New
functions.
* libgccjit.cc (gcc_jit_context_new_unary_op,
gcc_jit_context_new_binary_op): add checks for
is_numeric_vector.
gcc/testsuite/ChangeLog:
* jit.dg/test-reflection.c: Add check to make sure
gcc_jit_type_is_integral returns 0 on a vector type.
---
gcc/jit/jit-recording.h| 12 +++-
gcc/jit/libgccjit.cc | 4 ++--
gcc/testsuite/jit.dg/test-reflection.c | 1 +
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
index 4a8082991fb..ffadbe968af 100644
--- a/gcc/jit/jit-recording.h
+++ b/gcc/jit/jit-recording.h
@@ -567,6 +567,7 @@ public:
virtual bool is_int () const = 0;
virtual bool is_float () const = 0;
virtual bool is_bool () const = 0;
+ virtual bool is_numeric_vector () const { return false; }
virtual type *is_pointer () = 0;
virtual type *is_volatile () { return NULL; }
virtual type *is_restrict () { return NULL; }
@@ -701,9 +702,10 @@ public:
size_t get_size () final override { return m_other_type->get_size (); };
- bool is_int () const final override { return m_other_type->is_int (); }
+ bool is_int () const override { return m_other_type->is_int (); }
bool is_float () const final override { return m_other_type->is_float (); }
bool is_bool () const final override { return m_other_type->is_bool (); }
+ bool is_numeric_vector () const override { return m_other_type->is_numeric_vector (); }
type *is_pointer () final override { return m_other_type->is_pointer (); }
type *is_array () final override { return m_other_type->is_array (); }
struct_ *is_struct () final override { return m_other_type->is_struct (); }
@@ -826,6 +828,14 @@ public:
: decorated_type (other_type),
m_num_units (num_units) {}
+ bool is_int () const final override {
+return false;
+ }
+
+ bool is_numeric_vector () const final override {
+return true;
+ }
+
size_t get_num_units () const { return m_num_units; }
vector_type *dyn_cast_vector_type () final override { return this; }
diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
index 0451b4df7f9..852f4103839 100644
--- a/gcc/jit/libgccjit.cc
+++ b/gcc/jit/libgccjit.cc
@@ -2114,7 +2114,7 @@ gcc_jit_context_new_unary_op (gcc_jit_context *ctxt,
op);
RETURN_NULL_IF_FAIL (result_type, ctxt, loc, "NULL result_type");
RETURN_NULL_IF_FAIL_PRINTF3 (
-result_type->is_numeric (), ctxt, loc,
+result_type->is_numeric () || result_type->is_numeric_vector (), ctxt, loc,
"gcc_jit_unary_op %s with operand %s "
"has non-numeric result_type: %s",
gcc::jit::unary_op_reproducer_strings[op],
@@ -2171,7 +2171,7 @@ gcc_jit_context_new_binary_op (gcc_jit_context *ctxt,
b->get_debug_string (),
b->get_type ()->get_debug_string ());
RETURN_NULL_IF_FAIL_PRINTF4 (
-result_type->is_numeric (), ctxt, loc,
+result_type->is_numeric () || result_type->is_numeric_vector (), ctxt, loc,
"gcc_jit_binary_op %s with operands a: %s b: %s "
"has non-numeric result_type: %s",
gcc::jit::binary_op_reproducer_strings[op],
diff --git a/gcc/testsuite/jit.dg/test-reflection.c b/gcc/testsuite/jit.dg/test-reflection.c
index 112a2455c07..afa76ff81f6 100644
--- a/gcc/testsuite/jit.dg/test-reflection.c
+++ b/gcc/testsuite/jit.dg/test-reflection.c
@@ -59,6 +59,7 @@ verify_code (gcc_jit_context *ctxt, gcc_jit_result *result)
CHECK (vec_type != double_type);
CHECK_VALUE (gcc_jit_vector_type_get_element_type(vector_type), double_type);
CHECK_VALUE (gcc_jit_vector_type_get_num_units(vector_type), 4);
+ CHECK (!gcc_jit_type_is_integral(vec_type));
CHECK (!gcc_jit_type_is_pointer(double_type));
CHECK_VALUE (gcc_jit_type_is_pointer(gcc_jit_type_get_pointer(double_type)), double_type);
--
2.43.0
[PATCH] libgccjit: Add type checks in gcc_jit_block_add_assignment_op
Hi.
This patch adds checks gcc_jit_block_add_assignment_op to make sure it
is only ever called on numeric types.
With the previous patch, this might require a change to also allow
vector types here.
Thanks for the review.
From 932048619671c61af224708a3da484b9f54a30a3 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Wed, 18 Oct 2023 18:33:18 -0400
Subject: [PATCH] libgccjit: Add type checks in gcc_jit_block_add_assignment_op
gcc/jit/ChangeLog:
* libgccjit.cc (RETURN_IF_FAIL_PRINTF3): New macro.
(gcc_jit_block_add_assignment_op): Add numeric checks.
gcc/testsuite/ChangeLog:
* jit.dg/test-error-bad-assignment-op.c: New test.
---
gcc/jit/libgccjit.cc | 21 +++
.../jit.dg/test-error-bad-assignment-op.c | 57 +++
2 files changed, 78 insertions(+)
create mode 100644 gcc/testsuite/jit.dg/test-error-bad-assignment-op.c
diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
index 0451b4df7f9..eb6817a0a99 100644
--- a/gcc/jit/libgccjit.cc
+++ b/gcc/jit/libgccjit.cc
@@ -267,6 +267,16 @@ struct gcc_jit_extended_asm : public gcc::jit::recording::extended_asm
}\
JIT_END_STMT
+#define RETURN_IF_FAIL_PRINTF3(TEST_EXPR, CTXT, LOC, ERR_FMT, A0, A1, A2) \
+ JIT_BEGIN_STMT \
+if (!(TEST_EXPR)) \
+ {\
+ jit_error ((CTXT), (LOC), "%s: " ERR_FMT,\
+ __func__, (A0), (A1), (A2)); \
+ return; \
+ }\
+ JIT_END_STMT
+
#define RETURN_IF_FAIL_PRINTF4(TEST_EXPR, CTXT, LOC, ERR_FMT, A0, A1, A2, A3) \
JIT_BEGIN_STMT \
if (!(TEST_EXPR)) \
@@ -2890,6 +2900,17 @@ gcc_jit_block_add_assignment_op (gcc_jit_block *block,
lvalue->get_type ()->get_debug_string (),
rvalue->get_debug_string (),
rvalue->get_type ()->get_debug_string ());
+ // TODO: check if it is a numeric vector?
+ RETURN_IF_FAIL_PRINTF3 (
+lvalue->get_type ()->is_numeric () && rvalue->get_type ()->is_numeric (), ctxt, loc,
+"gcc_jit_block_add_assignment_op %s has non-numeric lvalue %s (type: %s)",
+gcc::jit::binary_op_reproducer_strings[op],
+lvalue->get_debug_string (), lvalue->get_type ()->get_debug_string ());
+ RETURN_IF_FAIL_PRINTF3 (
+rvalue->get_type ()->is_numeric () && rvalue->get_type ()->is_numeric (), ctxt, loc,
+"gcc_jit_block_add_assignment_op %s has non-numeric rvalue %s (type: %s)",
+gcc::jit::binary_op_reproducer_strings[op],
+rvalue->get_debug_string (), rvalue->get_type ()->get_debug_string ());
gcc::jit::recording::statement *stmt = block->add_assignment_op (loc, lvalue, op, rvalue);
diff --git a/gcc/testsuite/jit.dg/test-error-bad-assignment-op.c b/gcc/testsuite/jit.dg/test-error-bad-assignment-op.c
new file mode 100644
index 000..683ebbfb1fe
--- /dev/null
+++ b/gcc/testsuite/jit.dg/test-error-bad-assignment-op.c
@@ -0,0 +1,57 @@
+#include
+#include
+
+#include "libgccjit.h"
+
+#include "harness.h"
+
+void
+create_code (gcc_jit_context *ctxt, void *user_data)
+{
+ /* Let's try to inject the equivalent of:
+
+ void
+ test_fn ()
+ {
+const char *variable;
+variable += "test";
+ }
+
+ and verify that the API complains about the mismatching types
+ in the assignments.
+ */
+ gcc_jit_type *void_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_VOID);
+ gcc_jit_type *const_char_ptr_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_CONST_CHAR_PTR);
+
+ gcc_jit_function *func =
+gcc_jit_context_new_function (ctxt, NULL,
+ GCC_JIT_FUNCTION_EXPORTED,
+ void_type,
+ "test_fn",
+ 0, NULL,
+ 0);
+
+ gcc_jit_lvalue *variable = gcc_jit_function_new_local (func, NULL, const_char_ptr_type, "variable");
+ gcc_jit_block *initial =
+gcc_jit_function_new_block (func, "initial");
+ gcc_jit_rvalue *string =
+gcc_jit_context_new_string_literal (ctxt, "test");
+ gcc_jit_block_add_assignment_op (initial, NULL, variable, GCC_JIT_BINARY_OP_PLUS, string);
+
+ gcc_jit_block_end_with_void_return (initial, NULL);
+}
+
+void
+verify_code (gcc_jit_context *ctxt, gcc_jit_result *result)
+{
+ CHECK_VALUE (result, NULL);
+
+ /* Verify that the correct error messages were emitted. */
+ CHECK_STRING_VALUE (gcc_jit_context_get_first_error (ctxt),
+ "gcc_jit_block_add_assignment_op:"
+ " gcc_jit_block_add_assignment_op GCC_JIT_BINARY_OP_PLUS"
+ " has non-numeric lvalue variable (type: const char *)");
+}
+
--
2.43.0
Re: [PATCH] libgccjit: Make is_int return false on vector types
Can I merge this on master even though we're not in phase 1 anymore? On Thu, 2023-12-07 at 20:07 -0500, David Malcolm wrote: > On Thu, 2023-12-07 at 17:32 -0500, Antoni Boucher wrote: > > Hi. > > This patch changes the function is_int to return false on vector > > types. > > Thanks for the review. > > Thanks; looks good to me > > Dave >
Re: [PATCH] libgccjit: Fix GGC segfault when using -flto
I'm not sure how to do this. I tried the following commands, but this fails even on master: ../../gcc/configure --enable-host-shared --enable- languages=c,jit,c++,fortran,objc,lto --enable-checking=release -- disable-werror --prefix=/opt/gcc make bootstrap -j24 make -k check -j24 >From what I can understand, the unexpected failures are in g++: === g++ Summary === # of expected passes72790 # of unexpected failures1 # of expected failures 1011 # of unsupported tests 3503 === g++ Summary === # of expected passes4750 # of unexpected failures27 # of expected failures 16 # of unsupported tests 43 Am I doing something wrong? On Fri, 2023-12-01 at 12:49 -0500, David Malcolm wrote: > On Thu, 2023-11-30 at 17:13 -0500, Antoni Boucher wrote: > > Here's the updated patch. > > The failure was due to the test being in the test array while it > > should > > not have been there since it changes the context. > > Thanks for the updated patch. > > Did you do a full bootstrap and regression test with this one, or do > you want me to? > > Dave >
[PATCH] libgccjit: Add ability to get CPU features
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 review. From 302f9f0bb22deae3deb8249a9127447c3ec4f7c7 Mon Sep 17 00:00:00 2001 From: Antoni Boucher Date: Mon, 26 Jun 2023 18:29:15 -0400 Subject: [PATCH] libgccjit: Add ability to get CPU features gcc/ChangeLog: PR jit/112466 * Makefile.in (tm_jit_file_list, tm_jit_include_list, TM_JIT_H, JIT_TARGET_DEF, JIT_TARGET_H, JIT_TARGET_OBJS): New variables. (tm_jit.h, cs-tm_jit.h, jit/jit-target-hooks-def.h, s-jit-target-hooks-def-h): New rules. (s-tm-texi): Also check timestamp on jit-target.def. (generated_files): Add TM_JIT_H and jit/jit-target-hooks-def.h. (build/genhooks.o): Also depend on JIT_TARGET_DEF. * config.gcc (tm_jit_file, jit_target_objs, target_has_targetjitm): New variables. * config/i386/t-i386 (i386-jit.o): New rule. * config/t-linux (linux-jit.o): New rule. * configure: Regenerate. * configure.ac (tm_jit_file_list, tm_jit_include_list, jit_target_objs): Add substitutes. * doc/tm.texi: Regenerate. * doc/tm.texi.in (targetjitm): Document. (target_has_targetjitm): Document. * genhooks.cc: Include jit/jit-target.def. * config/default-jit.cc: New file. * config/i386/i386-jit.cc: New file. * config/i386/i386-jit.h: New file. * config/linux-jit.cc: New file. gcc/jit/ChangeLog: PR jit/112466 * Make-lang.in (JIT_OBJS): New variable. * jit-playback.cc (replay): Include jit-target.h and initialize target. * jit-playback.h (class get_target_info): New class. * jit-recording.cc (recording::context::get_target_info): New method. * jit-recording.h (recording::context::get_target_info): New method. * libgccjit.cc: Include jit-target.h. (struct gcc_jit_target_info): New struct. (gcc_jit_context_get_target_info, gcc_jit_target_info_release, gcc_jit_target_info_cpu_supports, gcc_jit_target_info_arch, gcc_jit_target_info_supports_128bit_int): New functions. * libgccjit.h (gcc_jit_context_get_target_info, gcc_jit_target_info_release, gcc_jit_target_info_cpu_supports, gcc_jit_target_info_arch, gcc_jit_target_info_supports_128bit_int): New functions. * libgccjit.map (LIBGCCJIT_ABI_26): New ABI tag. * docs/topics/compilation.rst: Add documentation for the functions gcc_jit_context_get_target_info, gcc_jit_target_info_release, gcc_jit_target_info_cpu_supports, gcc_jit_target_info_arch, gcc_jit_target_info_supports_128bit_int. * docs/topics/compatibility.rst (LIBGCCJIT_ABI_26): New ABI tag. * jit-target-def.h: New file. * jit-target.cc: New file. * jit-target.def: New file. * jit-target.h: New file. gcc/testsuite/ChangeLog: PR jit/112466 * jit.dg/all-non-failing-tests.h: Mention test-target-info.c. * jit.dg/test-target-info.c: New test. --- gcc/Makefile.in | 29 ++- gcc/config.gcc | 21 ++ gcc/config/default-jit.cc| 29 +++ gcc/config/i386/i386-jit.cc | 195 +++ gcc/config/i386/i386-jit.h | 22 +++ gcc/config/i386/t-i386 | 4 + gcc/config/linux-jit.cc | 36 gcc/config/t-linux | 4 + gcc/configure| 14 ++ gcc/configure.ac | 14 ++ gcc/doc/tm.texi | 26 +++ gcc/doc/tm.texi.in | 16 ++ gcc/genhooks.cc | 1 + gcc/jit/Make-lang.in | 8 +- gcc/jit/docs/topics/compatibility.rst| 14 ++ gcc/jit/docs/topics/compilation.rst | 51 + gcc/jit/jit-playback.cc | 2 + gcc/jit/jit-playback.h | 17 +- gcc/jit/jit-recording.cc | 19 ++ gcc/jit/jit-recording.h | 3 + gcc/jit/jit-target-def.h | 20 ++ gcc/jit/jit-target.cc| 89 + gcc/jit/jit-target.def | 52 + gcc/jit/jit-target.h | 73 +++ gcc/jit/libgccjit.cc | 43 gcc/jit/libgccjit.h | 60 ++ gcc/jit/libgccjit.map| 9 + gcc/testsuite/jit.dg/all-non-failing-tests.h | 3 + gcc/testsuite/jit.dg/test-target-info.c | 63 ++ 29 files changed, 931 insertions(+), 6 deletions(-) create mode 100644 gcc/config/default-jit.cc create mode 100644 gcc/config/i386/i386-jit.cc create mode 100644 gcc/config/i386/i386-jit.h create mode 100644 gcc/config/linux-jit.cc create mode 100644 gcc/jit/jit-target-def.h create mode 100644 gcc/jit/jit-target.
Re: [PATCH] libgccjit: Add ability to get CPU features
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 > > 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 >
[PATCH] libgccjit: Fix GGC segfault when using -flto
Hi.
This patch fixes the segfault when using -flto with libgccjit (bug
111396).
You mentioned in bugzilla that this didn't fix the reproducer for you,
but it does for me.
At first, the test case would not pass, but running "make install" made
it pass.
Not sure if this is normal.
Could you please check if this fixes the issue on your side as well?
Since this patch changes files outside of gcc/jit, what tests should I
run to make sure it didn't break anything?
Thanks for the review.
From f26d0f37e8d83bce1f5aa53c393961a8bd518d16 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Fri, 10 Nov 2023 09:52:32 -0500
Subject: [PATCH] libgccjit: Fix GGC segfault when using -flto
gcc/ChangeLog:
PR jit/111396
* ipa-fnsummary.cc (ipa_fnsummary_cc_finalize): Call
ipa_free_size_summary.
* ipa-icf.cc (ipa_icf_cc_finalize): New function.
* ipa-profile.cc (ipa_profile_cc_finalize): New function.
* ipa-prop.cc (ipa_prop_cc_finalize): New function.
* ipa-prop.h (ipa_prop_cc_finalize): New function.
* ipa-sra.cc (ipa_sra_cc_finalize): New function.
* ipa-utils.h (ipa_profile_cc_finalize, ipa_icf_cc_finalize,
ipa_sra_cc_finalize): New functions.
* toplev.cc (toplev::finalize): Call ipa_icf_cc_finalize,
ipa_prop_cc_finalize, ipa_profile_cc_finalize and
ipa_sra_cc_finalize
Include ipa-utils.h.
gcc/testsuite/ChangeLog:
PR jit/111396
* jit.dg/all-non-failing-tests.h: Add new test-ggc-bugfix.
* jit.dg/test-ggc-bugfix.c: New test.
---
gcc/ipa-fnsummary.cc | 1 +
gcc/ipa-icf.cc | 9 ++
gcc/ipa-profile.cc | 10 ++
gcc/ipa-prop.cc | 18 +++
gcc/ipa-prop.h | 2 ++
gcc/ipa-sra.cc | 12 +++
gcc/ipa-utils.h | 7
gcc/testsuite/jit.dg/all-non-failing-tests.h | 12 ++-
gcc/testsuite/jit.dg/test-ggc-bugfix.c | 34
gcc/toplev.cc| 5 +++
10 files changed, 109 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/jit.dg/test-ggc-bugfix.c
diff --git a/gcc/ipa-fnsummary.cc b/gcc/ipa-fnsummary.cc
index a2495ffe63e..34e011c4b50 100644
--- a/gcc/ipa-fnsummary.cc
+++ b/gcc/ipa-fnsummary.cc
@@ -5090,4 +5090,5 @@ void
ipa_fnsummary_cc_finalize (void)
{
ipa_free_fn_summary ();
+ ipa_free_size_summary ();
}
diff --git a/gcc/ipa-icf.cc b/gcc/ipa-icf.cc
index bbdfd445397..ba6c6899ce6 100644
--- a/gcc/ipa-icf.cc
+++ b/gcc/ipa-icf.cc
@@ -3657,3 +3657,12 @@ make_pass_ipa_icf (gcc::context *ctxt)
{
return new ipa_icf::pass_ipa_icf (ctxt);
}
+
+/* Reset all state within ipa-icf.cc so that we can rerun the compiler
+ within the same process. For use by toplev::finalize. */
+
+void
+ipa_icf_cc_finalize (void)
+{
+ ipa_icf::optimizer = NULL;
+}
diff --git a/gcc/ipa-profile.cc b/gcc/ipa-profile.cc
index 78a40a118bc..8083b8195a8 100644
--- a/gcc/ipa-profile.cc
+++ b/gcc/ipa-profile.cc
@@ -1065,3 +1065,13 @@ make_pass_ipa_profile (gcc::context *ctxt)
{
return new pass_ipa_profile (ctxt);
}
+
+/* Reset all state within ipa-profile.cc so that we can rerun the compiler
+ within the same process. For use by toplev::finalize. */
+
+void
+ipa_profile_cc_finalize (void)
+{
+ delete call_sums;
+ call_sums = NULL;
+}
diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
index 827bdb691ba..32cfb7754be 100644
--- a/gcc/ipa-prop.cc
+++ b/gcc/ipa-prop.cc
@@ -5904,5 +5904,23 @@ ipcp_transform_function (struct cgraph_node *node)
return modified_mem_access ? TODO_update_ssa_only_virtuals : 0;
}
+/* Reset all state within ipa-prop.cc so that we can rerun the compiler
+ within the same process. For use by toplev::finalize. */
+
+void
+ipa_prop_cc_finalize (void)
+{
+ if (function_insertion_hook_holder)
+symtab->remove_cgraph_insertion_hook (function_insertion_hook_holder);
+ function_insertion_hook_holder = NULL;
+
+ if (ipa_edge_args_sum)
+ggc_delete (ipa_edge_args_sum);
+ ipa_edge_args_sum = NULL;
+
+ if (ipa_node_params_sum)
+ggc_delete (ipa_node_params_sum);
+ ipa_node_params_sum = NULL;
+}
#include "gt-ipa-prop.h"
diff --git a/gcc/ipa-prop.h b/gcc/ipa-prop.h
index fcd0e5c638f..4409c4afee9 100644
--- a/gcc/ipa-prop.h
+++ b/gcc/ipa-prop.h
@@ -1255,6 +1255,8 @@ tree ipcp_get_aggregate_const (struct function *func, tree parm, bool by_ref,
bool unadjusted_ptr_and_unit_offset (tree op, tree *ret,
poly_int64 *offset_ret);
+void ipa_prop_cc_finalize (void);
+
/* From tree-sra.cc: */
tree build_ref_for_offset (location_t, tree, poly_int64, bool, tree,
gimple_stmt_iterator *, bool);
diff --git a/gcc/ipa-sra.cc b/gcc/ipa-sra.cc
index 6ffad335db4..2ac6fee14c4 100644
--- a/gcc/ipa-sra.cc
+++ b/gcc/ipa-sra.cc
@@ -4707,5 +4707,17 @@ make_pass_ipa_sra (gcc::context *ctxt)
return new pass_ipa_sra (ctxt);
}
+/* Reset all state within ipa-sra.cc so that we can rerun
Re: [PATCH] Add support for function attributes and variable attributes
David: another thing I remember you mentioned when you reviewed an earlier version of this patch is the usage of `std::pair`. I can't find where you said that, but I remember you mentioned that we should use a struct instead. Can you please elaborate again? Thanks. On Wed, 2023-11-15 at 17:53 +0100, Guillaume Gomez wrote: > Hi, > > This patch adds the (incomplete) support for function and variable > attributes. The added attributes are the ones we're using in > rustc_codegen_gcc but all the groundwork is done to add more (and we > will very likely add more as we didn't add all the ones we use in > rustc_codegen_gcc yet). > > The only big question with this patch is about `inline`. We currently > handle it as an attribute because it is more convenient for us but is > it ok or should we create a separate function to mark a function as > inlined? > > Thanks in advance for the review.
[PATCH] libgccjit: Add support for the type bfloat16
Hi. This patch adds the support for the type bfloat16 (bug 112574). This was asked to be splitted from a another patch sent here: https://gcc.gnu.org/pipermail/jit/2023q1/001607.html Thanks for the review.
Re: [PATCH] libgccjit: Add support for the type bfloat16
I forgot to attach the patch.
On Thu, 2023-11-16 at 17:19 -0500, Antoni Boucher wrote:
> Hi.
> This patch adds the support for the type bfloat16 (bug 112574).
>
> This was asked to be splitted from a another patch sent here:
> https://gcc.gnu.org/pipermail/jit/2023q1/001607.html
>
> Thanks for the review.
From 0e57583bba7e9fe5f5ff89559d4f29bf1bd7a240 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Thu, 16 Nov 2023 10:59:22 -0500
Subject: [PATCH] libgccjit: Add support for the type bfloat16
gcc/jit/ChangeLog:
PR jit/112574
* docs/topics/types.rst: Document GCC_JIT_TYPE_BFLOAT16.
* jit-common.h: Update NUM_GCC_JIT_TYPES.
* jit-playback.cc (get_tree_node_for_type): Support bfloat16.
* jit-recording.cc (recording::memento_of_get_type::get_size,
recording::memento_of_get_type::dereference,
recording::memento_of_get_type::is_int,
recording::memento_of_get_type::is_signed,
recording::memento_of_get_type::is_float,
recording::memento_of_get_type::is_bool): Support bfloat16.
* libgccjit.h (enum gcc_jit_types): Add GCC_JIT_TYPE_BFLOAT16.
gcc/testsuite/ChangeLog:
PR jit/112574
* jit.dg/test-types.c: Test GCC_JIT_TYPE_BFLOAT16.
* jit.dg/test-bfloat16.c: New test.
---
gcc/jit/docs/topics/types.rst| 2 ++
gcc/jit/jit-common.h | 2 +-
gcc/jit/jit-playback.cc | 2 ++
gcc/jit/jit-recording.cc | 11 +
gcc/jit/libgccjit.h | 4 ++-
gcc/testsuite/jit.dg/test-bfloat16.c | 37
gcc/testsuite/jit.dg/test-types.c| 2 ++
7 files changed, 58 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-bfloat16.c
diff --git a/gcc/jit/docs/topics/types.rst b/gcc/jit/docs/topics/types.rst
index d8c1d15d69d..1ae814a349d 100644
--- a/gcc/jit/docs/topics/types.rst
+++ b/gcc/jit/docs/topics/types.rst
@@ -113,6 +113,8 @@ Standard types
- C99's ``__int128_t``
* - :c:data:`GCC_JIT_TYPE_FLOAT`
-
+ * - :c:data:`GCC_JIT_TYPE_BFLOAT16`
+ - C's ``__bfloat16``
* - :c:data:`GCC_JIT_TYPE_DOUBLE`
-
* - :c:data:`GCC_JIT_TYPE_LONG_DOUBLE`
diff --git a/gcc/jit/jit-common.h b/gcc/jit/jit-common.h
index 80c1618da96..983c9190d44 100644
--- a/gcc/jit/jit-common.h
+++ b/gcc/jit/jit-common.h
@@ -36,7 +36,7 @@ along with GCC; see the file COPYING3. If not see
#endif
#endif
-const int NUM_GCC_JIT_TYPES = GCC_JIT_TYPE_INT128_T + 1;
+const int NUM_GCC_JIT_TYPES = GCC_JIT_TYPE_BFLOAT16 + 1;
/* This comment is included by the docs.
diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
index 18cc4da25b8..7e1c97a4638 100644
--- a/gcc/jit/jit-playback.cc
+++ b/gcc/jit/jit-playback.cc
@@ -280,6 +280,8 @@ get_tree_node_for_type (enum gcc_jit_types type_)
case GCC_JIT_TYPE_FLOAT:
return float_type_node;
+case GCC_JIT_TYPE_BFLOAT16:
+ return bfloat16_type_node;
case GCC_JIT_TYPE_DOUBLE:
return double_type_node;
case GCC_JIT_TYPE_LONG_DOUBLE:
diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc
index 9b5b8005ebe..af8b7a421ec 100644
--- a/gcc/jit/jit-recording.cc
+++ b/gcc/jit/jit-recording.cc
@@ -2385,6 +2385,10 @@ recording::memento_of_get_type::get_size ()
case GCC_JIT_TYPE_FLOAT:
size = FLOAT_TYPE_SIZE;
break;
+#ifdef HAVE_BFmode
+case GCC_JIT_TYPE_BFLOAT16:
+ return GET_MODE_UNIT_SIZE (BFmode);
+#endif
case GCC_JIT_TYPE_DOUBLE:
size = DOUBLE_TYPE_SIZE;
break;
@@ -2444,6 +2448,7 @@ recording::memento_of_get_type::dereference ()
case GCC_JIT_TYPE_INT64_T:
case GCC_JIT_TYPE_INT128_T:
case GCC_JIT_TYPE_FLOAT:
+case GCC_JIT_TYPE_BFLOAT16:
case GCC_JIT_TYPE_DOUBLE:
case GCC_JIT_TYPE_LONG_DOUBLE:
case GCC_JIT_TYPE_COMPLEX_FLOAT:
@@ -2508,6 +2513,7 @@ recording::memento_of_get_type::is_int () const
return true;
case GCC_JIT_TYPE_FLOAT:
+case GCC_JIT_TYPE_BFLOAT16:
case GCC_JIT_TYPE_DOUBLE:
case GCC_JIT_TYPE_LONG_DOUBLE:
return false;
@@ -2566,6 +2572,7 @@ recording::memento_of_get_type::is_signed () const
case GCC_JIT_TYPE_UINT128_T:
case GCC_JIT_TYPE_FLOAT:
+case GCC_JIT_TYPE_BFLOAT16:
case GCC_JIT_TYPE_DOUBLE:
case GCC_JIT_TYPE_LONG_DOUBLE:
@@ -2625,6 +2632,7 @@ recording::memento_of_get_type::is_float () const
return false;
case GCC_JIT_TYPE_FLOAT:
+case GCC_JIT_TYPE_BFLOAT16:
case GCC_JIT_TYPE_DOUBLE:
case GCC_JIT_TYPE_LONG_DOUBLE:
return true;
@@ -2688,6 +2696,7 @@ recording::memento_of_get_type::is_bool () const
return false;
case GCC_JIT_TYPE_FLOAT:
+case GCC_JIT_TYPE_BFLOAT16:
case GCC_JIT_TYPE_DOUBLE:
case GCC_JIT_TYPE_LONG_DOUBLE:
return false;
@@ -2768,6 +2777,7 @@ static const char * const get_type_strings[] = {
"__int64_t",/* GCC_JIT_TYPE_INT64_T */
"__int128_t", /* GCC_JIT_TYPE_INT128_T */
+ "bfloat16&q
[PATCH] libgccjit: Fix ira cost segfault
Hi. This patch fixes a segfault that happens when compiling librsvg (more specifically its dependency aho-corasick) with rustc_codegen_gcc (bug 112575). I was not able to create a reproducer for this bug: I'm assuming I might need to concat all the reproducers together in the same file in order to be able to reproduce the issue. I'm also not sure I put the cleanup in the correct location. Is there any finalizer function for target specific code? Thanks to fix this issue. From e0f4f51682266bc9f507afdb64908ed3695a2f5e Mon Sep 17 00:00:00 2001 From: Antoni Boucher Date: Thu, 2 Nov 2023 17:18:35 -0400 Subject: [PATCH] libgccjit: Fix ira cost segfault gcc/ChangeLog: PR jit/112575 * config/i386/i386-options.cc (ix86_option_override_internal): Cleanup target_attribute_cache. --- gcc/config/i386/i386-options.cc | 6 ++ 1 file changed, 6 insertions(+) diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc index df7d24352d1..f596c0fb53c 100644 --- a/gcc/config/i386/i386-options.cc +++ b/gcc/config/i386/i386-options.cc @@ -3070,6 +3070,12 @@ ix86_option_override_internal (bool main_args_p, = opts->x_flag_unsafe_math_optimizations; target_option_default_node = target_option_current_node = build_target_option_node (opts, opts_set); + /* TODO: check if this is the correct location. It should probably be in + some finalizer function, but I don't + know if there's one. */ + target_attribute_cache[0] = NULL; + target_attribute_cache[1] = NULL; + target_attribute_cache[2] = NULL; } if (opts->x_flag_cf_protection != CF_NONE) -- 2.42.1
[PATCH] libgccjit Fix a RTL bug for libgccjit
Hi.
This patch fixes a RTL bug when using some target-specific builtins in
libgccjit (bug 112576).
The test use a function from an unmerged patch:
https://gcc.gnu.org/pipermail/jit/2023q1/001605.html
Thanks for the review!
From 9236998f5ad3156ebe39e97c03d1a28ce80dd95a Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Thu, 9 Jun 2022 20:57:41 -0400
Subject: [PATCH] libgccjit Fix a RTL bug for libgccjit
This fixes a 'unrecognizable insn' error when generating some code using
target-specific builtins.
gcc/ChangeLog:
PR jit/112576
* emit-rtl.cc (init_emit_once): Do not initialize const_int_rtx
if already initialized.
gcc/testsuite:
PR jit/112576
* jit.dg/all-non-failing-tests.h: Mention test-rtl-bug-target-builtins.c.
* jit.dg/test-rtl-bug-target-builtins.c: New test.
---
gcc/emit-rtl.cc | 9 +-
gcc/testsuite/jit.dg/all-non-failing-tests.h | 3 +
.../jit.dg/test-rtl-bug-target-builtins.c | 87 +++
3 files changed, 97 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-rtl-bug-target-builtins.c
diff --git a/gcc/emit-rtl.cc b/gcc/emit-rtl.cc
index 84b6833225e..a18ac1de98c 100644
--- a/gcc/emit-rtl.cc
+++ b/gcc/emit-rtl.cc
@@ -6216,8 +6216,13 @@ init_emit_once (void)
/* Don't use gen_rtx_CONST_INT here since gen_rtx_CONST_INT in this case
tries to use these variables. */
for (i = - MAX_SAVED_CONST_INT; i <= MAX_SAVED_CONST_INT; i++)
-const_int_rtx[i + MAX_SAVED_CONST_INT] =
- gen_rtx_raw_CONST_INT (VOIDmode, (HOST_WIDE_INT) i);
+ {
+// Do not initialize twice the constants because there are used elsewhere
+// and libgccjit execute this function twice.
+if (const_int_rtx[i + MAX_SAVED_CONST_INT] == NULL)
+ const_int_rtx[i + MAX_SAVED_CONST_INT]
+ = gen_rtx_raw_CONST_INT (VOIDmode, (HOST_WIDE_INT) i);
+ }
if (STORE_FLAG_VALUE >= - MAX_SAVED_CONST_INT
&& STORE_FLAG_VALUE <= MAX_SAVED_CONST_INT)
diff --git a/gcc/testsuite/jit.dg/all-non-failing-tests.h b/gcc/testsuite/jit.dg/all-non-failing-tests.h
index e762563f9bd..3da2e285b80 100644
--- a/gcc/testsuite/jit.dg/all-non-failing-tests.h
+++ b/gcc/testsuite/jit.dg/all-non-failing-tests.h
@@ -322,6 +322,9 @@
/* test-setting-alignment.c: This can't be in the testcases array as it
is target-specific. */
+/* test-rtl-bug-target-builtins.c: This can't be in the testcases array as it
+ is target-specific. */
+
/* test-string-literal.c */
#define create_code create_code_string_literal
#define verify_code verify_code_string_literal
diff --git a/gcc/testsuite/jit.dg/test-rtl-bug-target-builtins.c b/gcc/testsuite/jit.dg/test-rtl-bug-target-builtins.c
new file mode 100644
index 000..d4a686271f9
--- /dev/null
+++ b/gcc/testsuite/jit.dg/test-rtl-bug-target-builtins.c
@@ -0,0 +1,87 @@
+/* { dg-do compile { target x86_64-*-* } } */
+
+#include
+#include
+
+#include "libgccjit.h"
+
+#define TEST_PROVIDES_MAIN
+#include "harness.h"
+
+void
+create_code (gcc_jit_context *ctxt, void *user_data)
+{
+ gcc_jit_context_add_command_line_option (ctxt, "-mavx512vl");
+ gcc_jit_function *builtin =
+gcc_jit_context_get_target_builtin_function (ctxt,
+"__builtin_ia32_cvtpd2udq128_mask");
+
+ gcc_jit_type *u8_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_UINT8_T);
+ gcc_jit_type *double_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_DOUBLE);
+ gcc_jit_type *v2df = gcc_jit_type_get_vector (double_type, 2);
+ gcc_jit_type *int_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_INT);
+ gcc_jit_type *v4si = gcc_jit_type_get_vector (int_type, 4);
+
+ gcc_jit_function *func =
+gcc_jit_context_new_function (ctxt, NULL,
+ GCC_JIT_FUNCTION_EXPORTED,
+ v4si,
+ "epu32",
+ 0, NULL,
+ 0);
+ gcc_jit_block *block = gcc_jit_function_new_block (func, NULL);
+ gcc_jit_lvalue *var1 = gcc_jit_function_new_local (func, NULL, v2df, "var1");
+ gcc_jit_lvalue *var2 = gcc_jit_function_new_local (func, NULL, v4si, "var2");
+ gcc_jit_rvalue *args[3] = {
+gcc_jit_lvalue_as_rvalue (var1),
+gcc_jit_lvalue_as_rvalue (var2),
+gcc_jit_context_zero (ctxt, u8_type),
+ };
+ gcc_jit_rvalue *call = gcc_jit_context_new_call (ctxt, NULL, builtin, 3, args);
+ gcc_jit_block_end_with_return (block, NULL, call);
+}
+
+void
+verify_code (gcc_jit_context *ctxt, gcc_jit_result *result)
+{
+ CHECK_NON_NULL (result);
+}
+
+int
+main (int argc, char **argv)
+{
+ /* This is the same as the main provided by harness.h, but it first create a dummy context and compile
+ in order to add the target builtins to libgccjit's internal state. */
+ gcc_jit_context *ctxt;
+ ctxt = gcc_jit_context_acquire ();
+ if (!ctxt)
+{
+ fail ("gcc_jit_context_acquire failed");
+ return -1;
+}
+ gcc_jit_result *result;
+ result = gcc_jit_contex
Re: [PATCH] libgccjit Fix a RTL bug for libgccjit
In contrast with the other frontends, libgccjit can be executed multiple times in a row in the same process. This is the source of multiple bugs due to global variables as can be seen by several patches I sent these past years. On Fri, 2023-11-17 at 14:06 -0700, Jeff Law wrote: > > > On 11/16/23 15:36, Antoni Boucher wrote: > > Hi. > > This patch fixes a RTL bug when using some target-specific builtins > > in > > libgccjit (bug 112576). > > > > The test use a function from an unmerged patch: > > https://gcc.gnu.org/pipermail/jit/2023q1/001605.html > > > > Thanks for the review! > The natural question here is why does libgccjit call init_emit_once > more > than one time? The whole point of that routine is doing one time > initializations. It's not supposed to be called more than once. > > David? Thoughts here? > > jeff
[PATCH] libgccjit: Add vector permutation and vector access operations
Hi. This patch adds a vector permutation and vector access operations (bug 112602). This was split from this patch: https://gcc.gnu.org/pipermail/jit/2023q1/001606.html Thanks for the review. From 25b386334f22845d7ba1b60658730373eb6ddbb3 Mon Sep 17 00:00:00 2001 From: Antoni Boucher Date: Fri, 17 Nov 2023 17:23:28 -0500 Subject: [PATCH] libgccjit: Add vector permutation and vector access operations gcc/jit/ChangeLog: PR jit/112602 * docs/topics/compatibility.rst (LIBGCCJIT_ABI_26): New ABI tag. * docs/topics/expressions.rst: Document gcc_jit_context_new_rvalue_vector_perm and gcc_jit_context_new_vector_access. * jit-playback.cc (playback::context::new_rvalue_vector_perm, common_mark_addressable_vec, gnu_vector_type_p, lvalue_p, convert_vector_to_array_for_subscript, new_vector_access): new functions. * jit-playback.h (new_rvalue_vector_perm, new_vector_access): New functions. * jit-recording.cc (recording::context::new_rvalue_vector_perm, recording::context::new_vector_access, memento_of_new_rvalue_vector_perm, recording::memento_of_new_rvalue_vector_perm::replay_into, recording::memento_of_new_rvalue_vector_perm::visit_children, recording::memento_of_new_rvalue_vector_perm::make_debug_string, recording::memento_of_new_rvalue_vector_perm::write_reproducer, recording::vector_access::replay_into, recording::vector_access::visit_children, recording::vector_access::make_debug_string, recording::vector_access::write_reproducer): New methods. * jit-recording.h (class memento_of_new_rvalue_vector_perm, class vector_access): New classes. * libgccjit.cc (gcc_jit_context_new_vector_access, gcc_jit_context_new_rvalue_vector_perm): New functions. * libgccjit.h (gcc_jit_context_new_rvalue_vector_perm, gcc_jit_context_new_vector_access): New functions. * libgccjit.map: New functions. gcc/testsuite/ChangeLog: PR jit/112602 * jit.dg/all-non-failing-tests.h: New test test-vector-perm.c. * jit.dg/test-vector-perm.c: New test. --- gcc/jit/docs/topics/compatibility.rst| 10 ++ gcc/jit/docs/topics/expressions.rst | 53 ++ gcc/jit/jit-playback.cc | 150 gcc/jit/jit-playback.h | 11 ++ gcc/jit/jit-recording.cc | 169 +++ gcc/jit/jit-recording.h | 72 gcc/jit/libgccjit.cc | 109 gcc/jit/libgccjit.h | 29 gcc/jit/libgccjit.map| 6 + gcc/testsuite/jit.dg/all-non-failing-tests.h | 12 +- gcc/testsuite/jit.dg/test-vector-perm.c | 96 +++ 11 files changed, 716 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/jit.dg/test-vector-perm.c diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst index ebede440ee4..a764e3968d1 100644 --- a/gcc/jit/docs/topics/compatibility.rst +++ b/gcc/jit/docs/topics/compatibility.rst @@ -378,3 +378,13 @@ alignment of a variable: ``LIBGCCJIT_ABI_25`` covers the addition of :func:`gcc_jit_type_get_restrict` + + +.. _LIBGCCJIT_ABI_26: + +``LIBGCCJIT_ABI_26`` + +``LIBGCCJIT_ABI_26`` covers the addition of functions to manipulate vectors: + + * :func:`gcc_jit_context_new_rvalue_vector_perm` + * :func:`gcc_jit_context_new_vector_access` diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst index 42cfee36302..4a45aa13f5c 100644 --- a/gcc/jit/docs/topics/expressions.rst +++ b/gcc/jit/docs/topics/expressions.rst @@ -295,6 +295,35 @@ Vector expressions #ifdef LIBGCCJIT_HAVE_gcc_jit_context_new_rvalue_from_vector +.. function:: gcc_jit_rvalue * \ + gcc_jit_context_new_rvalue_vector_perm (gcc_jit_context *ctxt, \ + gcc_jit_location *loc, \ + gcc_jit_rvalue *elements1, \ + gcc_jit_rvalue *elements2, \ + gcc_jit_rvalue *mask); + + Build a permutation of two vectors. + + "elements1" and "elements2" should have the same type. + The length of "mask" and "elements1" should be the same. + The element type of "mask" should be integral. + The size of the element type of "mask" and "elements1" should be the same. + + This entrypoint was added in :ref:`LIBGCCJIT_ABI_25`; you can test for + its presence using + + .. code-block:: c + + #ifdef LIBGCCJIT_HAVE_VECTOR_OPERATIONS + +Analogous to: + +.. code-block:: c + + __builtin_shuffle (elements1, elements2, mask) + +in C. + Unary Operations @@ -1020,3 +1049,27 @@ Field access is provided separately for both lvalues and rvalues. PTR[INDEX]
[PATCH] libgccjit: Add ways to set the personality function
Hi.
This adds functions to set the personality function (bug 112603).
I'm not sure I can make a test for this: it seems the personality
function will not be set if there are no try/catch inside the
functions.
Do you know a way to keep the personality function that is set in this
case?
Or should we wait until I send the patch for try/catch?
Thanks for the review.
From 6beb6452c7bac9ecbdaea750d61d6e6c6bd3ed8f Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sun, 16 Apr 2023 13:19:20 -0400
Subject: [PATCH] libgccjit: Add ways to set the personality function
gcc/ChangeLog:
PR jit/112603
* expr.cc (build_personality_function_with_name): New function.
* tree.cc (tree_cc_finalize): Cleanup gcc_eh_personality_decl.
* tree.h (build_personality_function_with_name): New decl.
gcc/jit/ChangeLog:
PR jit/112603
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_26): New ABI tag.
* docs/topics/functions.rst: Document the functions
gcc_jit_set_global_personality_function_name and
gcc_jit_function_set_personality_function.
* dummy-frontend.cc (jit_gc_root): New variable.
(jit_preserve_from_gc): New function.
(jit_langhook_init): Initialize new variables.
(jit_langhook_eh_personality): New hook.
(LANG_HOOKS_EH_PERSONALITY): New hook.
* jit-playback.cc (set_personality_function): New function.
* jit-playback.h: New decl.
* jit-recording.cc
(memento_of_set_personality_function::make_debug_string,
recording::memento_of_set_personality_function::write_reproducer,
recording::function::set_personality_function,
recording::memento_of_set_personality_function::replay_into):
New functions
* jit-recording.h (class memento_of_set_personality_function):
New class.
(recording::function::set_personality_function): New function.
* libgccjit.cc (gcc_jit_function_set_personality_function,
gcc_jit_set_global_personality_function_name): New functions.
* libgccjit.h (gcc_jit_set_global_personality_function_name,
gcc_jit_function_set_personality_function): New functions.
* libgccjit.map: New functions.
gcc/testsuite/ChangeLog:
* jit.dg/test-personality-function.c: New test.
* jit.dg/all-non-failing-tests.h: Mention
test-personality-function.c.
---
gcc/expr.cc | 8 +++
gcc/jit/docs/topics/compatibility.rst | 10
gcc/jit/docs/topics/functions.rst | 28 ++
gcc/jit/dummy-frontend.cc | 36
gcc/jit/jit-playback.cc | 8 +++
gcc/jit/jit-playback.h| 3 +
gcc/jit/jit-recording.cc | 44 +++
gcc/jit/jit-recording.h | 23
gcc/jit/libgccjit.cc | 22
gcc/jit/libgccjit.h | 8 +++
gcc/jit/libgccjit.map | 6 ++
gcc/testsuite/jit.dg/all-non-failing-tests.h | 3 +
.../jit.dg/test-personality-function.c| 55 +++
gcc/tree.cc | 1 +
gcc/tree.h| 1 +
15 files changed, 256 insertions(+)
create mode 100644 gcc/testsuite/jit.dg/test-personality-function.c
diff --git a/gcc/expr.cc b/gcc/expr.cc
index 556bcf7ef59..25d50289b24 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -13559,6 +13559,14 @@ build_personality_function (const char *lang)
name = ACONCAT (("__", lang, "_personality", unwind_and_version, NULL));
+ return build_personality_function_with_name (name);
+}
+
+tree
+build_personality_function_with_name (const char *name)
+{
+ tree decl, type;
+
type = build_function_type_list (unsigned_type_node,
integer_type_node, integer_type_node,
long_long_unsigned_type_node,
diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst
index ebede440ee4..31c3ef6401a 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -378,3 +378,13 @@ alignment of a variable:
``LIBGCCJIT_ABI_25`` covers the addition of
:func:`gcc_jit_type_get_restrict`
+
+.. _LIBGCCJIT_ABI_26:
+
+``LIBGCCJIT_ABI_26``
+
+``LIBGCCJIT_ABI_26`` covers the addition of functions to set the personality
+function:
+
+ * :func:`gcc_jit_function_set_personality_function`
+ * :func:`gcc_jit_set_global_personality_function_name`
diff --git a/gcc/jit/docs/topics/functions.rst b/gcc/jit/docs/topics/functions.rst
index cf5cb716daf..e59885c3549 100644
--- a/gcc/jit/docs/topics/functions.rst
+++ b/gcc/jit/docs/topics/functions.rst
@@ -197,6 +197,34 @@ Functions
.. type:: gcc_jit_case
+.. function:: void
+ gcc_jit_function_set_personality_function (gcc_jit_function *fn,
+ gcc_jit_function *personality_func)
+
+ Set the personality function of ``fn`` to ``personality_func``.
+
+ were added in :ref:`LIBGCCJIT_ABI_26`; you can test for
Re: [PATCH] Add support for function attributes and variable attributes
David: I found back the comment you made. Here it is: I see you have patches to add function and variable attributes; I wonder if this would be cleaner internally if there was a recording::attribute class, rather than the std::pair currently in use (some attributes have int arguments rather than string, others have multiple args). I also wondered if a "gcc_jit_attribute" type could be exposed to the user, e.g.: attr1 = gcc_jit_context_new_attribute (ctxt, "noreturn"); attr2 = gcc_jit_context_new_attribute_with_string (ctxt, "alias", "__foo"); gcc_jit_function_add_attribute (ctxt, attr1); gcc_jit_function_add_attribute (ctxt, attr2); or somesuch? But I think the API you currently have is OK. On Thu, 2023-11-23 at 22:52 +0100, Guillaume Gomez wrote: > Ping David. :) > > Le mer. 15 nov. 2023 à 17:56, Antoni Boucher a > écrit : > > > > David: another thing I remember you mentioned when you reviewed an > > earlier version of this patch is the usage of `std::pair`. > > I can't find where you said that, but I remember you mentioned that > > we > > should use a struct instead. > > Can you please elaborate again? > > Thanks. > > > > On Wed, 2023-11-15 at 17:53 +0100, Guillaume Gomez wrote: > > > Hi, > > > > > > This patch adds the (incomplete) support for function and > > > variable > > > attributes. The added attributes are the ones we're using in > > > rustc_codegen_gcc but all the groundwork is done to add more (and > > > we > > > will very likely add more as we didn't add all the ones we use in > > > rustc_codegen_gcc yet). > > > > > > The only big question with this patch is about `inline`. We > > > currently > > > handle it as an attribute because it is more convenient for us > > > but is > > > it ok or should we create a separate function to mark a function > > > as > > > inlined? > > > > > > Thanks in advance for the review. > >
Re: [PATCH] libgccjit: Add support for machine-dependent builtins
Hi.
I did split the patch and sent one for the bfloat16 support and another
one for the vector support.
Here's the updated patch for the machine-dependent builtins.
Regards.
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.
From e025f95f4790ae861e709caf23cbc0723c1a3804 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Mon, 23 Jan 2023 17:21:15 -0500
Subject: [PATCH] libgccjit: Add support for machine-dependent builtins
gcc/ChangeLog:
PR jit/108762
* config/i386/i386-builtins.cc: New function (clear_builtin_types).
gcc/jit/ChangeLog:
PR jit/108762
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_26): New ABI tag.
* docs/topics/functions.rst: Add documentation for the function
gcc_jit_context_get_target_builtin_function.
* dummy-frontend.cc: Include headers target.h, jit-recording.h,
print-tree.h, unordered_map and string, new variables (target_builtins,
target_function_types, and target_builtins_ctxt), new function
(tree_type_to_jit_type).
* jit-builtins.cc: Specify that the function types are not from
target builtins.
* jit-playback.cc: New argument is_target_builtin to new_function.
* jit-playback.h: New argument is_target_builtin to
new_function.
* jit-recording.cc: New argument is_target_builtin to
new_function_type, function_type constructor and function
constructor, new function
(get_target_builtin_function).
* jit-recording.h: Include headers string and unordered_map, new
variable target_function_types, new argument is_target_builtin
to new_function_type, function_type and function, new functions
(get_target_builtin_function, copy).
* libgccjit.cc: New function
(gcc_jit_context_get_target_builtin_function).
* libgccjit.h: New function
(gcc_jit_context_get_target_builtin_function).
* libgccjit.map: New functions
(gcc_jit_context_get_target_builtin_function).
gcc/testsuite:
PR jit/108762
* jit.dg/all-non-failing-tests.h: New test test-target-builtins.c.
* jit.dg/test-target-builtins.c: New test.
---
gcc/config/i386/i386-builtins.cc | 18 ++
gcc/jit/docs/topics/compatibility.rst| 9 +
gcc/jit/docs/topics/functions.rst| 19 ++
gcc/jit/dummy-frontend.cc| 204 ++-
gcc/jit/jit-builtins.cc | 6 +-
gcc/jit/jit-playback.cc | 11 +-
gcc/jit/jit-playback.h | 5 +-
gcc/jit/jit-recording.cc | 76 ++-
gcc/jit/jit-recording.h | 111 +-
gcc/jit/libgccjit.cc | 18 ++
gcc/jit/libgccjit.h | 13 ++
gcc/jit/libgccjit.map| 4 +
gcc/testsuite/jit.dg/all-non-failing-tests.h | 3 +
gcc/testsuite/jit.dg/test-target-builtins.c | 77 +++
14 files changed, 554 insertions(+), 20 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-target-builtins.c
diff --git a/gcc/config/i386/i386-builtins.cc b/gcc/config/i386/i386-builtins.cc
index 42fc3751676..5cc1d6f4d2e 100644
--- a/gcc/config/i386/i386-builtins.cc
+++ b/gcc/config/i386/i386-builtins.cc
@@ -225,6 +225,22 @@ static GTY(()) tree ix86_builtins[(int) IX86_BUILTIN_MAX];
struct builtin_isa ix86_builtins_isa[(int) IX86_BUILTIN_MAX];
+static void
+clear_builtin_types (void)
+{
+ for (int i = 0 ; i < IX86_BT_LAST_CPTR + 1 ; i++)
+ix86_builtin_type_tab[i] = NULL;
+
+ for (int i = 0 ; i < IX86_BUILTIN_MAX ; i++)
+ {
+ix86_builtins[i] = NULL;
+ix86_builtins_isa[i].set_and_not_built_p = true;
+ }
+
+ for (int i = 0 ; i < IX86_BT_LAST_ALIAS + 1 ; i++)
+ix86_builtin_func_type_tab[i] = NULL;
+}
+
tree get_ix86_builtin (enum ix86_builtins c)
{
return ix86_builtins[
Re: [PATCH] libgccjit: Add support for machine-dependent builtins
I will need to not forget to update the function tree_type_to_jit_type in dummy-frontend.cc to add back the support for bfloat16 when the patch for it is merged. On Thu, 2023-11-23 at 17:17 -0500, Antoni Boucher wrote: > Hi. > I did split the patch and sent one for the bfloat16 support and > another > one for the vector support. > > Here's the updated patch for the machine-dependent builtins. > > Regards. > > 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. >
Re: [PATCH] libgccjit: Make new_array_type take unsigned long
Thanks for the review. I'm a bit concerned about using unsigned long. Would it be OK if I change the type to uint64_t? I could rename the function to gcc_jit_context_new_array_type_u64. Regards. Le 2024-06-26 à 11 h 34, David Malcolm a écrit : On Fri, 2024-02-23 at 09:55 -0500, Antoni Boucher wrote: I had forgotten to add the doc since there is now a new API. Here it is. Sorry for the delay; the updated patch looks good to me (but may need usual ABI tag changes when pushing). Thanks Dave On Wed, 2024-02-21 at 19:45 -0500, Antoni Boucher wrote: Thanks for the review. Here's the updated patch. On Thu, 2023-12-07 at 20:04 -0500, David Malcolm wrote: On Thu, 2023-12-07 at 17:29 -0500, Antoni Boucher wrote: Hi. This patches update gcc_jit_context_new_array_type to take the size as an unsigned long instead of a int, to allow creating bigger array types. I haven't written the ChangeLog yet because I wasn't sure it's allowed to change the type of a function like that. If it isn't, what would you suggest? We've kept ABI compatibility all the way back to the version in GCC 5, so it seems a shame to break ABI. How about a new API entrypoint: gcc_jit_context_new_array_type_unsigned_long whilst keeping the old one. Then everything internally can use "unsigned long"; we just keep the old entrypoint accepting int (which internally promotes the arg to unsigned long, if positive, sharing all the implementation). Alternatively, I think there may be a way to do this with symbol versioning: https://gcc.gnu.org/wiki/SymbolVersioning see e.g. Section 3.7 of Ulrich Drepper's "How To Write Shared Libraries", but I'm a bit wary of cross-platform compatibility with that. Dave
Re: [PATCH] libgccjit: Fix get_size of size_t
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
Re: Frontend access to target features (was Re: [PATCH] libgccjit: Add ability to get CPU features)
David: Ping. Le 2024-06-12 à 08 h 21, Antoni Boucher a écrit : David: Ping. Le 2024-04-26 à 09 h 51, Antoni Boucher a écrit : Now that we have a more general way to check if target-dependent types are supported (see this commit: https://github.com/rust-lang/gcc/commit/1c9a9b2f1fd914cad911467ec1d29f158643c2ce#diff-018089519ab2b14a34313ded0ae1a2f9fcab5f7bcb2fa31f147e1dc757bbdd7aR4016), perhaps we should remove gcc_jit_target_info_supports_128bit_int from this patch, or change it to include the more general way. David, what are your thoughts on this? Le 2024-04-19 à 08 h 34, Antoni Boucher a écrit : 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
Re: [PATCH] libgccjit: Fix get_size of size_t
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
Re: Frontend access to target features (was Re: [PATCH] libgccjit: Add ability to get CPU features)
David: Ping. Le 2024-04-26 à 09 h 51, Antoni Boucher a écrit : Now that we have a more general way to check if target-dependent types are supported (see this commit: https://github.com/rust-lang/gcc/commit/1c9a9b2f1fd914cad911467ec1d29f158643c2ce#diff-018089519ab2b14a34313ded0ae1a2f9fcab5f7bcb2fa31f147e1dc757bbdd7aR4016), perhaps we should remove gcc_jit_target_info_supports_128bit_int from this patch, or change it to include the more general way. David, what are your thoughts on this? Le 2024-04-19 à 08 h 34, Antoni Boucher a écrit : 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: 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.
Re: [PATCH] Add rvalue::get_name method (and its C equivalent)
Please move the function to be on lvalue since there are no rvalue types
that are not lvalues that have a name.
Le 2024-04-22 à 09 h 04, Guillaume Gomez a écrit :
Hey Arthur :)
Is there any reason for that getter to return a mutable pointer to the
name? Would something like this work instead if you're just looking at
getting the name?
+ virtual string * get_name () const { return NULL; }
With of course adequate modifications to the inheriting classes.
Good catch, thanks!
Updated the patch and attached the new version to this email.
Cordially.
Le lun. 22 avr. 2024 à 11:51, Arthur Cohen a écrit :
Hey Guillaume :)
On 4/20/24 01:05, Guillaume Gomez wrote:
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.
virtual bool get_wide_int (wide_int *) const { return false; }
+ virtual string * get_name () { return NULL; }
+
private:
virtual enum precedence get_precedence () const = 0;
Is there any reason for that getter to return a mutable pointer to the
name? Would something like this work instead if you're just looking at
getting the name?
+ virtual string * get_name () const { return NULL; }
With of course adequate modifications to the inheriting classes.
Best,
Arthur
Re: [PATCH] Add rvalue::get_name method (and its C equivalent)
I believe you forgot to regenerate the ChangeLog.
Le 2024-04-22 à 09 h 16, Guillaume Gomez a écrit :
Good point!
New patch attached.
Le lun. 22 avr. 2024 à 15:13, Antoni Boucher a écrit :
Please move the function to be on lvalue since there are no rvalue types
that are not lvalues that have a name.
Le 2024-04-22 à 09 h 04, Guillaume Gomez a écrit :
Hey Arthur :)
Is there any reason for that getter to return a mutable pointer to the
name? Would something like this work instead if you're just looking at
getting the name?
+ virtual string * get_name () const { return NULL; }
With of course adequate modifications to the inheriting classes.
Good catch, thanks!
Updated the patch and attached the new version to this email.
Cordially.
Le lun. 22 avr. 2024 à 11:51, Arthur Cohen a écrit :
Hey Guillaume :)
On 4/20/24 01:05, Guillaume Gomez wrote:
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.
virtual bool get_wide_int (wide_int *) const { return false; }
+ virtual string * get_name () { return NULL; }
+
private:
virtual enum precedence get_precedence () const = 0;
Is there any reason for that getter to return a mutable pointer to the
name? Would something like this work instead if you're just looking at
getting the name?
+ virtual string * get_name () const { return NULL; }
With of course adequate modifications to the inheriting classes.
Best,
Arthur
Re: [PATCH] Add rvalue::get_name method (and its C equivalent)
For your new API endpoint, please add a check like:
RETURN_IF_FAIL (lvalue->is_global () || lvalue->is_local (),
NULL,
NULL,
"lvalue should be a variable");
Le 2024-04-22 à 09 h 16, Guillaume Gomez a écrit :
Good point!
New patch attached.
Le lun. 22 avr. 2024 à 15:13, Antoni Boucher a écrit :
Please move the function to be on lvalue since there are no rvalue types
that are not lvalues that have a name.
Le 2024-04-22 à 09 h 04, Guillaume Gomez a écrit :
Hey Arthur :)
Is there any reason for that getter to return a mutable pointer to the
name? Would something like this work instead if you're just looking at
getting the name?
+ virtual string * get_name () const { return NULL; }
With of course adequate modifications to the inheriting classes.
Good catch, thanks!
Updated the patch and attached the new version to this email.
Cordially.
Le lun. 22 avr. 2024 à 11:51, Arthur Cohen a écrit :
Hey Guillaume :)
On 4/20/24 01:05, Guillaume Gomez wrote:
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.
virtual bool get_wide_int (wide_int *) const { return false; }
+ virtual string * get_name () { return NULL; }
+
private:
virtual enum precedence get_precedence () const = 0;
Is there any reason for that getter to return a mutable pointer to the
name? Would something like this work instead if you're just looking at
getting the name?
+ virtual string * get_name () const { return NULL; }
With of course adequate modifications to the inheriting classes.
Best,
Arthur
Re: Frontend access to target features (was Re: [PATCH] libgccjit: Add ability to get CPU features)
Now that we have a more general way to check if target-dependent types are supported (see this commit: https://github.com/rust-lang/gcc/commit/1c9a9b2f1fd914cad911467ec1d29f158643c2ce#diff-018089519ab2b14a34313ded0ae1a2f9fcab5f7bcb2fa31f147e1dc757bbdd7aR4016), perhaps we should remove gcc_jit_target_info_supports_128bit_int from this patch, or change it to include the more general way. David, what are your thoughts on this? Le 2024-04-19 à 08 h 34, Antoni Boucher a écrit : 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: Allow sending a const pointer as argument
David: Ping. Le 2024-02-17 à 11 h 55, Antoni Boucher a écrit : David: Ping. On Fri, 2024-01-19 at 15:59 -0500, Antoni Boucher wrote: David: Ping. On Thu, 2023-12-21 at 11:59 -0500, Antoni Boucher wrote: Hi. This patch adds the ability to send const pointer as argument to a function. Thanks for the review.
