Re: [PATCH] libgccjit: Add new gcc_jit_context_new_blob entry point
On Mon, 2020-08-03 at 10:07 +0200, Andrea Corallo wrote:
> David Malcolm writes:
>
> > On Fri, 2020-07-24 at 18:05 -0400, David Malcolm via Gcc-patches wrote:
> >
> > [...]
> >
> >> I haven't thought this through in detail, and I'm not sure exactly
> >> how
> >> it would work for arbitrary types, but I thought it worth sharing.
> >> (For example I can think of nasty issues if we ever want to support
> >> cross-compilation, e.g. where sizeof types or endianness differs
> >> between host and target).
> >
> > ...which is an argument in favor of retaining the name "blob", perhaps
> > as the name of the argument in the header file e.g.:
> >
> > extern void
> > gcc_jit_global_set_initializer (gcc_jit_lvalue *global,
> > const void *blob,
> > size_t num_bytes);
> >
> >
> > as a subtle hint to the user that they need to be wary about binary
> > layouts ("here be dragons").
> >
> > [...]
>
> Hi Dave & all,
>
> following up this is my take on the implementation of:
>
> gcc_jit_global_set_initializer (gcc_jit_lvalue *global,
> const void *blob,
> size_t num_bytes);
>
> 'global' must be an array but in the seek of generality it now supports
> all the various integral types and is not limited to char[].
>
> As you anticipated the implementation I came up is currently not safe
> for cross-compilation, not sure is requirement tho.
>
> make check-jit is clean
>
> Feedback very welcome
>
> Thanks!
Thanks for the updated patch. Comments inline below.
> Andrea
>
> gcc/jit/ChangeLog
>
> 2020-08-01 Andrea Corallo
>
> * docs/topics/compatibility.rst (LIBGCCJIT_ABI_14): New ABI tag.
> * docs/topics/expressions.rst (gcc_jit_global_set_initializer):
> Document new entry point in section 'Global variables'.
> * jit-playback.c (global_new_decl, global_finalize_lvalue): New
> method.
> (playback::context::new_global): Make use of global_new_decl,
> global_finalize_lvalue.
> (load_blob_in_ctor): New template function in use by the
> following.
> (playback::context::new_global_initialized): New method.
> * jit-playback.h (class context): Decl 'new_global_initialized',
> 'global_new_decl', 'global_finalize_lvalue'.
> (lvalue::set_initializer): Add implementation.
> * jit-recording.c (recording::memento_of_get_pointer::get_size)
> (recording::memento_of_get_type::get_size): Add implementation.
> (recording::global::write_initializer_reproducer): New function in
> use by 'recording::global::write_reproducer'.
> (recording::global::replay_into)
> (recording::global::write_to_dump)
> (recording::global::write_reproducer): Handle
> initialized case.
> * jit-recording.h (class type): Decl 'get_size' and
> 'num_elements'.
> * libgccjit++.h (class lvalue): Declare new 'set_initializer'
> method.
> (class lvalue): Decl 'is_global' and 'set_initializer'.
> (class class global) Decl 'write_initializer_reproducer'. Add
> 'm_initializer', 'm_initializer_num_bytes' fields. Implement
> 'set_initializer'.
> * libgccjit.c (gcc_jit_global_set_initializer): New function.
> * libgccjit.h (gcc_jit_global_set_initializer): New function
> declaration.
> * libgccjit.map (LIBGCCJIT_ABI_14): New ABI tag.
>
> gcc/testsuite/ChangeLog
>
> 2020-08-01 Andrea Corallo
>
> * jit.dg/all-non-failing-tests.h: Add test-blob.c.
> * jit.dg/test-global-set-initializer.c: New testcase.
[...]
> diff --git a/gcc/jit/docs/topics/expressions.rst
> b/gcc/jit/docs/topics/expressions.rst
> index d783ceea51a8..7699dcfd27be 100644
> --- a/gcc/jit/docs/topics/expressions.rst
> +++ b/gcc/jit/docs/topics/expressions.rst
> @@ -582,6 +582,27 @@ Global variables
>referring to it. Analogous to using an "extern" global from a
>header file.
>
> +.. function:: gcc_jit_lvalue *\
> + gcc_jit_global_set_initializer (gcc_jit_lvalue *global,\
> + const void *blob,\
> + size_t num_bytes)
> +
> + Set an initializer for an object using the memory content pointed
> + by ``blob`` for ``num_bytes``. ``global`` must be an arrays of an
Typo: "arrays" -> "array"
> + integral type.
Why the non-void return type? Looking at libgccjit.c I see it returns
"global" if it succeeds, or NULL if it fails. Wouldn't it be better to
simply have void return type, and rely on the normaly error-handling
mechanisms?
Or is this inspired by the inline asm patch? (for PR 87291)
[...]
> --- a/gcc/jit/jit-playback.h
> +++ b/gcc/jit/jit-playback.h
> @@ -111,6 +111,15 @@ public:
> type *type,
> const
Re: [PATCH] libgccjit: Add new gcc_jit_context_new_blob entry point
David Malcolm writes:
> On Fri, 2020-07-24 at 18:05 -0400, David Malcolm via Gcc-patches wrote:
>
> [...]
>
>> I haven't thought this through in detail, and I'm not sure exactly
>> how
>> it would work for arbitrary types, but I thought it worth sharing.
>> (For example I can think of nasty issues if we ever want to support
>> cross-compilation, e.g. where sizeof types or endianness differs
>> between host and target).
>
> ...which is an argument in favor of retaining the name "blob", perhaps
> as the name of the argument in the header file e.g.:
>
> extern void
> gcc_jit_global_set_initializer (gcc_jit_lvalue *global,
> const void *blob,
> size_t num_bytes);
>
>
> as a subtle hint to the user that they need to be wary about binary
> layouts ("here be dragons").
>
> [...]
Hi Dave & all,
following up this is my take on the implementation of:
gcc_jit_global_set_initializer (gcc_jit_lvalue *global,
const void *blob,
size_t num_bytes);
'global' must be an array but in the seek of generality it now supports
all the various integral types and is not limited to char[].
As you anticipated the implementation I came up is currently not safe
for cross-compilation, not sure is requirement tho.
make check-jit is clean
Feedback very welcome
Thanks!
Andrea
gcc/jit/ChangeLog
2020-08-01 Andrea Corallo
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_14): New ABI tag.
* docs/topics/expressions.rst (gcc_jit_global_set_initializer):
Document new entry point in section 'Global variables'.
* jit-playback.c (global_new_decl, global_finalize_lvalue): New
method.
(playback::context::new_global): Make use of global_new_decl,
global_finalize_lvalue.
(load_blob_in_ctor): New template function in use by the
following.
(playback::context::new_global_initialized): New method.
* jit-playback.h (class context): Decl 'new_global_initialized',
'global_new_decl', 'global_finalize_lvalue'.
(lvalue::set_initializer): Add implementation.
* jit-recording.c (recording::memento_of_get_pointer::get_size)
(recording::memento_of_get_type::get_size): Add implementation.
(recording::global::write_initializer_reproducer): New function in
use by 'recording::global::write_reproducer'.
(recording::global::replay_into)
(recording::global::write_to_dump)
(recording::global::write_reproducer): Handle
initialized case.
* jit-recording.h (class type): Decl 'get_size' and
'num_elements'.
* libgccjit++.h (class lvalue): Declare new 'set_initializer'
method.
(class lvalue): Decl 'is_global' and 'set_initializer'.
(class class global) Decl 'write_initializer_reproducer'. Add
'm_initializer', 'm_initializer_num_bytes' fields. Implement
'set_initializer'.
* libgccjit.c (gcc_jit_global_set_initializer): New function.
* libgccjit.h (gcc_jit_global_set_initializer): New function
declaration.
* libgccjit.map (LIBGCCJIT_ABI_14): New ABI tag.
gcc/testsuite/ChangeLog
2020-08-01 Andrea Corallo
* jit.dg/all-non-failing-tests.h: Add test-blob.c.
* jit.dg/test-global-set-initializer.c: New testcase.
>From 74bd96fde6d4baed978555279d17898b989c00ad Mon Sep 17 00:00:00 2001
From: Andrea Corallo
Date: Sat, 30 May 2020 10:33:08 +0100
Subject: [PATCH] Add new gcc_jit_global_set_initializer entry point
gcc/jit/ChangeLog
2020-08-01 Andrea Corallo
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_14): New ABI tag.
* docs/topics/expressions.rst (gcc_jit_global_set_initializer):
Document new entry point in section 'Global variables'.
* jit-playback.c (global_new_decl, global_finalize_lvalue): New
method.
(playback::context::new_global): Make use of global_new_decl,
global_finalize_lvalue.
(load_blob_in_ctor): New template function in use by the
following.
(playback::context::new_global_initialized): New method.
* jit-playback.h (class context): Decl 'new_global_initialized',
'global_new_decl', 'global_finalize_lvalue'.
(lvalue::set_initializer): Add implementation.
* jit-recording.c (recording::memento_of_get_pointer::get_size)
(recording::memento_of_get_type::get_size): Add implementation.
(recording::global::write_initializer_reproducer): New function in
use by 'recording::global::write_reproducer'.
(recording::global::replay_into)
(recording::global::write_to_dump)
(recording::global::write_reproducer): Handle
initialized case.
* jit-recording.h (class type): Decl 'get_size' and
'num_elements'.
* libgccjit++.h (class lvalue): Declare new 'set_initializer'
Re: [PATCH] libgccjit: Add new gcc_jit_context_new_blob entry point
On Fri, 2020-07-24 at 18:05 -0400, David Malcolm via Gcc-patches wrote:
[...]
> I haven't thought this through in detail, and I'm not sure exactly
> how
> it would work for arbitrary types, but I thought it worth sharing.
> (For example I can think of nasty issues if we ever want to support
> cross-compilation, e.g. where sizeof types or endianness differs
> between host and target).
...which is an argument in favor of retaining the name "blob", perhaps
as the name of the argument in the header file e.g.:
extern void
gcc_jit_global_set_initializer (gcc_jit_lvalue *global,
const void *blob,
size_t num_bytes);
as a subtle hint to the user that they need to be wary about binary
layouts ("here be dragons").
[...]
Re: [PATCH] libgccjit: Add new gcc_jit_context_new_blob entry point
On Wed, 2020-07-01 at 18:14 +0200, Andrea Corallo wrote: > Andrea Corallo writes: > > > > It occurred to me that the entrypoint is combining two things: > > > - creating a global char[] > > > - creating an initializer for that global > > > > > > which got me wondering if we should instead have a way to add > > > initializers for globals. > > > > > > My first thought was something like: > > > > > > gcc_jit_context_new_global_with_initializer > > > > > > which would be like gcc_jit_context_new_global but would have an > > > additional gcc_jit_rvalue *init_value param? > > > The global would have to be of kind GCC_JIT_GLOBAL_EXPORTED or > > > GCC_JIT_GLOBAL_INTERNAL, not GCC_JIT_GLOBAL_IMPORTED. > > > > > > Alternatively, maybe it would be better to have > > > > > > gcc_jit_global_set_initializer (gcc_jit_lvalue *global, > > > gcc_jit_rvalue *init_val); > > > > > > to make the API more flexible. > > > > > > But even if we had this, we'd still need some way to create the > > > rvalue > > > for that initial value. Also, maybe there ought to be a > > > distinction > > > between rvalues that can vary at runtime vs those that can be > > > computed > > > at compile-time (and are thus suitable for use in static > > > initialization). > > > > > > I suspect you may have gone through the same thought process and > > > come > > > up with a simpler approach. (I'm mostly just "thinking out > > > loud" > > > here, sorry if it isn't very coherent). > > > > Yes I had kind of similar thoughs. > > > > Ideally would be good to have a generic solution, the complication > > is > > that as you mentioned not every rvalue is suitable for initializing > > every global, but rather the opposite. My fear was that the space > > to be > > covered would be non trivial for a robust solution in this case. > > > > Also I believe we currently have no way to express in libgccjit > > rvalues > > an array with some content, so how to use this as > > initializer? Perhaps > > also we should have a new type gcc_jit_initializer? > > > > On the other hand I thought that for simple things like integers > > the > > problem is tipically already solved with an assignment in some init > > code > > (infact I think so far nobody complained) while the real standing > > limitation is for blobs (perhaps I'm wrong). And in the end if you > > can > > stuff some data in, you can use it later for any scope. > > > > Another "hybrid" solution would be to have specific entry point for > > each > > type of the subset we want to allow for static > > initialization. This way > > we still control the creation of the initializer internally so it's > > safe. In this view this blob entry point would be just one of > > these > > (probably with a different name like > > 'gcc_jit_context_new_glob_init_char_array'). > > > > Hi Dave, > > wanted to ask if you formed an opinion about the patch and/or more in > general the problem of static initialize data. Sorry for the delay in responding. Another idea that occurred to me is, as before, to generalize the entrypoint to cover creating globals with arbitrary types and to support initializers (either with a new gcc_jit_context_new_global_with_initializer or a new: gcc_jit_global_set_initializer as above, but instead of passing in a gcc_jit_rvalue *init_val, to pass in a const void *initializer size_t num_bytes pair pointing to the initializer buffer, with the behavior that these are the bytes that will be used for the initial value of the global, whatever that means for the given type. Something like either: extern gcc_jit_lvalue * gcc_jit_context_new_global_with_initializer (gcc_jit_context *ctxt, gcc_jit_location *loc, enum gcc_jit_global_kind kind, gcc_jit_type *type, const char *name, const void *initializer, size_t num_bytes); or: extern void gcc_jit_global_set_initializer (gcc_jit_lvalue *global, const void *initializer, size_t num_bytes); or somesuch. The former is similar to the proposed new entrypoint from your patch, but gains a type argument (and is modeled more closely on the existing entrypoint for creating globals). I haven't thought this through in detail, and I'm not sure exactly how it would work for arbitrary types, but I thought it worth sharing. (For example I can think of nasty issues if we ever want to support cross-compilation, e.g. where sizeof types or endianness differs between host and target). Maybe we can make it work initially for char[] types, rejecting others, assuming that that's the most pressing need in your work, and we can add support for other types internally as followups without needing to add
Re: [PATCH] libgccjit: Add new gcc_jit_context_new_blob entry point
Andrea Corallo writes: > Andrea Corallo writes: > >>> It occurred to me that the entrypoint is combining two things: >>> - creating a global char[] >>> - creating an initializer for that global >>> >>> which got me wondering if we should instead have a way to add >>> initializers for globals. >>> >>> My first thought was something like: >>> >>> gcc_jit_context_new_global_with_initializer >>> >>> which would be like gcc_jit_context_new_global but would have an >>> additional gcc_jit_rvalue *init_value param? >>> The global would have to be of kind GCC_JIT_GLOBAL_EXPORTED or >>> GCC_JIT_GLOBAL_INTERNAL, not GCC_JIT_GLOBAL_IMPORTED. >>> >>> Alternatively, maybe it would be better to have >>> >>> gcc_jit_global_set_initializer (gcc_jit_lvalue *global, >>> gcc_jit_rvalue *init_val); >>> >>> to make the API more flexible. >>> >>> But even if we had this, we'd still need some way to create the rvalue >>> for that initial value. Also, maybe there ought to be a distinction >>> between rvalues that can vary at runtime vs those that can be computed >>> at compile-time (and are thus suitable for use in static >>> initialization). >>> >>> I suspect you may have gone through the same thought process and come >>> up with a simpler approach. (I'm mostly just "thinking out loud" >>> here, sorry if it isn't very coherent). >> >> Yes I had kind of similar thoughs. >> >> Ideally would be good to have a generic solution, the complication is >> that as you mentioned not every rvalue is suitable for initializing >> every global, but rather the opposite. My fear was that the space to be >> covered would be non trivial for a robust solution in this case. >> >> Also I believe we currently have no way to express in libgccjit rvalues >> an array with some content, so how to use this as initializer? Perhaps >> also we should have a new type gcc_jit_initializer? >> >> On the other hand I thought that for simple things like integers the >> problem is tipically already solved with an assignment in some init code >> (infact I think so far nobody complained) while the real standing >> limitation is for blobs (perhaps I'm wrong). And in the end if you can >> stuff some data in, you can use it later for any scope. >> >> Another "hybrid" solution would be to have specific entry point for each >> type of the subset we want to allow for static initialization. This way >> we still control the creation of the initializer internally so it's >> safe. In this view this blob entry point would be just one of these >> (probably with a different name like >> 'gcc_jit_context_new_glob_init_char_array'). >> > > Hi Dave, > > wanted to ask if you formed an opinion about the patch and/or more in > general the problem of static initialize data. > > Thanks > > Andrea Ping
Re: [PATCH] libgccjit: Add new gcc_jit_context_new_blob entry point
Andrea Corallo writes: >> It occurred to me that the entrypoint is combining two things: >> - creating a global char[] >> - creating an initializer for that global >> >> which got me wondering if we should instead have a way to add >> initializers for globals. >> >> My first thought was something like: >> >> gcc_jit_context_new_global_with_initializer >> >> which would be like gcc_jit_context_new_global but would have an >> additional gcc_jit_rvalue *init_value param? >> The global would have to be of kind GCC_JIT_GLOBAL_EXPORTED or >> GCC_JIT_GLOBAL_INTERNAL, not GCC_JIT_GLOBAL_IMPORTED. >> >> Alternatively, maybe it would be better to have >> >> gcc_jit_global_set_initializer (gcc_jit_lvalue *global, >> gcc_jit_rvalue *init_val); >> >> to make the API more flexible. >> >> But even if we had this, we'd still need some way to create the rvalue >> for that initial value. Also, maybe there ought to be a distinction >> between rvalues that can vary at runtime vs those that can be computed >> at compile-time (and are thus suitable for use in static >> initialization). >> >> I suspect you may have gone through the same thought process and come >> up with a simpler approach. (I'm mostly just "thinking out loud" >> here, sorry if it isn't very coherent). > > Yes I had kind of similar thoughs. > > Ideally would be good to have a generic solution, the complication is > that as you mentioned not every rvalue is suitable for initializing > every global, but rather the opposite. My fear was that the space to be > covered would be non trivial for a robust solution in this case. > > Also I believe we currently have no way to express in libgccjit rvalues > an array with some content, so how to use this as initializer? Perhaps > also we should have a new type gcc_jit_initializer? > > On the other hand I thought that for simple things like integers the > problem is tipically already solved with an assignment in some init code > (infact I think so far nobody complained) while the real standing > limitation is for blobs (perhaps I'm wrong). And in the end if you can > stuff some data in, you can use it later for any scope. > > Another "hybrid" solution would be to have specific entry point for each > type of the subset we want to allow for static initialization. This way > we still control the creation of the initializer internally so it's > safe. In this view this blob entry point would be just one of these > (probably with a different name like > 'gcc_jit_context_new_glob_init_char_array'). > Hi Dave, wanted to ask if you formed an opinion about the patch and/or more in general the problem of static initialize data. Thanks Andrea
Re: [PATCH] libgccjit: Add new gcc_jit_context_new_blob entry point
David Malcolm writes: > Thanks for the patch. > > Is this entrypoint only needed for the ahead-of-time use case? If the > client code is instead going to do an in-memory compilation, then I > believe it can simply build the buffer of data in memory and expose it > to the jitted code via gcc_jit_context_new_rvalue_from_ptr. Hi Dave, correct, if you can leak pointers into the generated code this entry point is likely to be unnecessary. > It occurred to me that the entrypoint is combining two things: > - creating a global char[] > - creating an initializer for that global > > which got me wondering if we should instead have a way to add > initializers for globals. > > My first thought was something like: > > gcc_jit_context_new_global_with_initializer > > which would be like gcc_jit_context_new_global but would have an > additional gcc_jit_rvalue *init_value param? > The global would have to be of kind GCC_JIT_GLOBAL_EXPORTED or > GCC_JIT_GLOBAL_INTERNAL, not GCC_JIT_GLOBAL_IMPORTED. > > Alternatively, maybe it would be better to have > > gcc_jit_global_set_initializer (gcc_jit_lvalue *global, > gcc_jit_rvalue *init_val); > > to make the API more flexible. > > But even if we had this, we'd still need some way to create the rvalue > for that initial value. Also, maybe there ought to be a distinction > between rvalues that can vary at runtime vs those that can be computed > at compile-time (and are thus suitable for use in static > initialization). > > I suspect you may have gone through the same thought process and come > up with a simpler approach. (I'm mostly just "thinking out loud" > here, sorry if it isn't very coherent). Yes I had kind of similar thoughs. Ideally would be good to have a generic solution, the complication is that as you mentioned not every rvalue is suitable for initializing every global, but rather the opposite. My fear was that the space to be covered would be non trivial for a robust solution in this case. Also I believe we currently have no way to express in libgccjit rvalues an array with some content, so how to use this as initializer? Perhaps also we should have a new type gcc_jit_initializer? On the other hand I thought that for simple things like integers the problem is tipically already solved with an assignment in some init code (infact I think so far nobody complained) while the real standing limitation is for blobs (perhaps I'm wrong). And in the end if you can stuff some data in, you can use it later for any scope. Another "hybrid" solution would be to have specific entry point for each type of the subset we want to allow for static initialization. This way we still control the creation of the initializer internally so it's safe. In this view this blob entry point would be just one of these (probably with a different name like 'gcc_jit_context_new_glob_init_char_array'). > Should it be a "const char[]" rather than just a "char[]"? Good question, I believe depends on the usecase so I left out the const. Perhaps should be a parameter of the entry point. > One specific nit about the patch: in compatibility.rst, there should be > a: > > .. _LIBGCCJIT_ABI_14: > > label before the heading. Ops > Hope this is constructive > Dave Sure it is. Thanks Andrea
Re: [PATCH] libgccjit: Add new gcc_jit_context_new_blob entry point
On Wed, 2020-06-03 at 12:11 +0200, Andrea Corallo wrote: > Hi all, > > I'd like to submit this patch to extend libgccjit to allow for > storing > binary blobs (equivalent to initialized char arrays). > > The use-case is when libgccjit is used as a back-end for dynamic > programming languages. In this case is often necessary to store > serialized objects into the compilation unit as support to the > generated code. > > The proposed entry point is the following: > > gcc_jit_lvalue * > gcc_jit_context_new_blob (gcc_jit_context *ctxt, > gcc_jit_location *loc, > enum gcc_jit_global_kind kind, > const void *ptr, > size_t size, > const char *name); > > This create a special kind of libgccjit global that will be > initialized > with the memory content pointed by 'ptr'. > > I've added a testcase and the regression is clean. I've also tested > it with the libgccjit based Emacs disabling the current workaround we > have > for this. > > Feedback is very welcome. Thanks for the patch. Is this entrypoint only needed for the ahead-of-time use case? If the client code is instead going to do an in-memory compilation, then I believe it can simply build the buffer of data in memory and expose it to the jitted code via gcc_jit_context_new_rvalue_from_ptr. It occurred to me that the entrypoint is combining two things: - creating a global char[] - creating an initializer for that global which got me wondering if we should instead have a way to add initializers for globals. My first thought was something like: gcc_jit_context_new_global_with_initializer which would be like gcc_jit_context_new_global but would have an additional gcc_jit_rvalue *init_value param? The global would have to be of kind GCC_JIT_GLOBAL_EXPORTED or GCC_JIT_GLOBAL_INTERNAL, not GCC_JIT_GLOBAL_IMPORTED. Alternatively, maybe it would be better to have gcc_jit_global_set_initializer (gcc_jit_lvalue *global, gcc_jit_rvalue *init_val); to make the API more flexible. But even if we had this, we'd still need some way to create the rvalue for that initial value. Also, maybe there ought to be a distinction between rvalues that can vary at runtime vs those that can be computed at compile-time (and are thus suitable for use in static initialization). I suspect you may have gone through the same thought process and come up with a simpler approach. (I'm mostly just "thinking out loud" here, sorry if it isn't very coherent). Should it be a "const char[]" rather than just a "char[]"? One specific nit about the patch: in compatibility.rst, there should be a: .. _LIBGCCJIT_ABI_14: label before the heading. Hope this is constructive Dave > Andrea > > gcc/jit/ChangeLog > > 2020-06-02 Andrea Corallo > > * docs/topics/compatibility.rst (LIBGCCJIT_ABI_14): New ABI > tag. > > * docs/topics/expressions.rst (Binary Blobs): New section > documenting gcc_jit_context_new_blob. > > * jit-common.h: Document class blob. > > * jit-playback.c (playback::context::global_new_decl) > (playback::context::global_finalize_lvalue): New methods. > (playback::context::new_global): Make use of global_new_decl, > global_finalize_lvalue. > (playback::context::new_blob): New method. > > * jit-playback.h (new_blob, global_new_decl): New method > declarations. > > * jit-recording.c (recording::context::new_blob) > (recording::blob::replay_into) > (recording::global::write_qualifier_to_dump): New methods. > (recording::global::write_to_dump): Use > write_qualifier_to_dump. > (recording::blob::write_to_dump): New method. > > * jit-recording.h (class blob): New class. > (class global): Have m_kind and m_name as protected. > (class global): Remove FINAL qualifier to replay_into and > write_to_dump. > (class global): New method write_qualifier_to_dump decl. > (class context): New method new_blob decl. > > * libgccjit++.h (context::new_blob): New method. > > * libgccjit.c (gcc_jit_lvalue_as_rvalue): New function. > > * libgccjit.h (gcc_jit_context_new_blob): New function > declaration. > (LIBGCCJIT_HAVE_gcc_jit_context_new_blob): New macro. > > * libgccjit.map (LIBGCCJIT_ABI_14): New ABI tag. > > gcc/testsuite/ChangeLog > > 2020-06-02 Andrea Corallo > > * jit.dg/all-non-failing-tests.h: Add test-blob.c. > > * jit.dg/test-blob.c: New test. >
[PATCH] libgccjit: Add new gcc_jit_context_new_blob entry point
Hi all, I'd like to submit this patch to extend libgccjit to allow for storing binary blobs (equivalent to initialized char arrays). The use-case is when libgccjit is used as a back-end for dynamic programming languages. In this case is often necessary to store serialized objects into the compilation unit as support to the generated code. The proposed entry point is the following: gcc_jit_lvalue * gcc_jit_context_new_blob (gcc_jit_context *ctxt, gcc_jit_location *loc, enum gcc_jit_global_kind kind, const void *ptr, size_t size, const char *name); This create a special kind of libgccjit global that will be initialized with the memory content pointed by 'ptr'. I've added a testcase and the regression is clean. I've also tested it with the libgccjit based Emacs disabling the current workaround we have for this. Feedback is very welcome. Andrea gcc/jit/ChangeLog 2020-06-02 Andrea Corallo * docs/topics/compatibility.rst (LIBGCCJIT_ABI_14): New ABI tag. * docs/topics/expressions.rst (Binary Blobs): New section documenting gcc_jit_context_new_blob. * jit-common.h: Document class blob. * jit-playback.c (playback::context::global_new_decl) (playback::context::global_finalize_lvalue): New methods. (playback::context::new_global): Make use of global_new_decl, global_finalize_lvalue. (playback::context::new_blob): New method. * jit-playback.h (new_blob, global_new_decl): New method declarations. * jit-recording.c (recording::context::new_blob) (recording::blob::replay_into) (recording::global::write_qualifier_to_dump): New methods. (recording::global::write_to_dump): Use write_qualifier_to_dump. (recording::blob::write_to_dump): New method. * jit-recording.h (class blob): New class. (class global): Have m_kind and m_name as protected. (class global): Remove FINAL qualifier to replay_into and write_to_dump. (class global): New method write_qualifier_to_dump decl. (class context): New method new_blob decl. * libgccjit++.h (context::new_blob): New method. * libgccjit.c (gcc_jit_lvalue_as_rvalue): New function. * libgccjit.h (gcc_jit_context_new_blob): New function declaration. (LIBGCCJIT_HAVE_gcc_jit_context_new_blob): New macro. * libgccjit.map (LIBGCCJIT_ABI_14): New ABI tag. gcc/testsuite/ChangeLog 2020-06-02 Andrea Corallo * jit.dg/all-non-failing-tests.h: Add test-blob.c. * jit.dg/test-blob.c: New test. >From b861fbbfbcbf18cc1b69dc4b7f91c596af40c8e4 Mon Sep 17 00:00:00 2001 From: Andrea Corallo Date: Sat, 30 May 2020 10:33:08 +0100 Subject: [PATCH] Add new gcc_jit_context_new_blob entry point gcc/jit/ChangeLog 2020-06-02 Andrea Corallo * docs/topics/compatibility.rst (LIBGCCJIT_ABI_14): New ABI tag. * docs/topics/expressions.rst (Binary Blobs): New section documenting gcc_jit_context_new_blob. * jit-common.h: Document class blob. * jit-playback.c (playback::context::global_new_decl) (playback::context::global_finalize_lvalue): New methods. (playback::context::new_global): Make use of global_new_decl, global_finalize_lvalue. (playback::context::new_blob): New method. * jit-playback.h (new_blob, global_new_decl): New method declarations. * jit-recording.c (recording::context::new_blob) (recording::blob::replay_into) (recording::global::write_qualifier_to_dump): New methods. (recording::global::write_to_dump): Use write_qualifier_to_dump. (recording::blob::write_to_dump): New method. * jit-recording.h (class blob): New class. (class global): Have m_kind and m_name as protected. (class global): Remove FINAL qualifier to replay_into and write_to_dump. (class global): New method write_qualifier_to_dump decl. (class context): New method new_blob decl. * libgccjit++.h (context::new_blob): New method. * libgccjit.c (gcc_jit_lvalue_as_rvalue): New function. * libgccjit.h (gcc_jit_context_new_blob): New function declaration. (LIBGCCJIT_HAVE_gcc_jit_context_new_blob): New macro. * libgccjit.map (LIBGCCJIT_ABI_14): New ABI tag. gcc/testsuite/ChangeLog 2020-06-02 Andrea Corallo * jit.dg/all-non-failing-tests.h: Add test-blob.c. * jit.dg/test-blob.c: New test. --- gcc/jit/docs/topics/compatibility.rst| 5 ++ gcc/jit/docs/topics/expressions.rst | 49 ++ gcc/jit/jit-common.h | 1 + gcc/jit/jit-playback.c | 67 -- gcc/jit/jit-playback.h | 16 gcc/jit/jit-recording.c | 95 +--- gcc/jit/jit-recording.h | 48 +- gcc/jit/libgccjit++.h| 21 + gcc/jit/libgccjit.c
