Re: [PATCH] ggc, jit: forcibly clear GTY roots in jit
I added it to bugzilla here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111396
Since this only reproduces part of the issue, please let me test again
with rustc_codegen_gcc after adding the missing fix.
I confirmed that the fix is in
https://github.com/antoyo/gcc/commit/9d5b6b20efa20825926196759d50706a604c64a8
so you might as well include all of this (except the linetable
condition in toplev.cc).
On Tue, 2023-09-12 at 14:38 -0400, David Malcolm wrote:
> On Tue, 2023-09-12 at 13:36 -0400, Antoni Boucher wrote:
> > In the mean time, here's a (Rust) reproducer for the issue:
> >
> > fn main() {
> > for _ in 0..5 {
> > let context = Context::default();
> > context.add_command_line_option("-flto");
> >
> > context.set_optimization_level(OptimizationLevel::Aggressive);
> > context.add_driver_option("-nostdlib");
> >
> > let int_type = context.new_type::();
> >
> > let function = context.new_function(None,
> > FunctionType::Exported, int_type, &[], "main", false);
> > let block = function.new_block("start");
> > let value = context.new_rvalue_from_int(int_type, 42);
> > block.end_with_return(None, value);
> >
> > context.compile_to_file(OutputKind::Executable, "my_exe");
> > }
> > }
>
> Can we get this in bugzilla please? If you generate a .c version of
> the context (via gcc_jit_context_dump_reproducer_to_file) I can try
> to
> debug it.
>
> Thanks
> Dave
>
Re: [PATCH] ggc, jit: forcibly clear GTY roots in jit
In the mean time, here's a (Rust) reproducer for the issue:
fn main() {
for _ in 0..5 {
let context = Context::default();
context.add_command_line_option("-flto");
context.set_optimization_level(OptimizationLevel::Aggressive);
context.add_driver_option("-nostdlib");
let int_type = context.new_type::();
let function = context.new_function(None,
FunctionType::Exported, int_type, &[], "main", false);
let block = function.new_block("start");
let value = context.new_rvalue_from_int(int_type, 42);
block.end_with_return(None, value);
context.compile_to_file(OutputKind::Executable, "my_exe");
}
}
On Tue, 2023-09-12 at 12:00 -0400, Antoni Boucher via Jit wrote:
> It seems to not be enough to fix the issue.
> Let me find out what's missing from my patch.
>
> On Tue, 2023-09-12 at 11:35 +0200, Richard Biener via Jit wrote:
> > On Wed, Sep 6, 2023 at 3:41 PM David Malcolm via Gcc-patches
> > wrote:
> > >
> > > As part of Antoyo's work on supporting LTO in rustc_codegen_gcc,
> > > he
> > > noticed an ICE inside libgccjit when compiling certain rust
> > > files.
> > >
> > > Debugging libgccjit showed that outdated information from a
> > > previous
> > > in-memory compile was referring to ad-hoc locations in the
> > > previous
> > > compile's line_table.
> > >
> > > The issue turned out to be the function decls in
> > > internal_fn_fnspec_array
> > > from the previous compile keeping alive the symtab nodes for
> > > these
> > > functions, and from this finding other functions in the previous
> > > compile, walking their CFGs, and finding ad-hoc data pointers in
> > > an
> > > edge
> > > with a location_t using ad-hoc data from the previous line_table
> > > instance, and thus a use-after-free ICE attempting to use this
> > > ad-
> > > hoc
> > > data.
> > >
> > > Previously in toplev::finalize we've fixed global state
> > > "piecemeal"
> > > by
> > > calling out to individual source_name_cc_finalize functions.
> > > However,
> > > it occurred to me that we have run-time information on where the
> > > GTY-marked pointers are.
> > >
> > > Hence this patch takes something of a "big hammer" approach by
> > > adding a
> > > new ggc_common_finalize that walks the GC roots, zeroing all of
> > > the
> > > pointers. I stepped through this in the debugger and observed
> > > that, in
> > > particular, this correctly zeroes the internal_fn_fnspec_array at
> > > the end
> > > of a libgccjit compile. Antoyo reports that this fixes the ICE
> > > for
> > > him.
> > > Doing so uncovered an ICE with libgccjit in dwarf2cfi.cc due to
> > > reuse of
> > > global variables from the previous compile, which this patch also
> > > fixes.
> > >
> > > I noticed that in ggc_mark_roots when clearing deletable roots we
> > > only
> > > clear the initial element in each gcc_root_tab_t. This looks
> > > like
> > > a
> > > latent bug to me, which the patch fixes. That said, there don't
> > > seem to
> > > be any deletable roots where the number of elements != 1.
> > >
> > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> > >
> > > OK for trunk?
> >
> > OK.
> >
> > Thanks,
> > Richard.
> >
> > > Thanks
> > > Dave
> > >
> > > gcc/ChangeLog:
> > > * dwarf2cfi.cc (dwarf2cfi_cc_finalize): New.
> > > * dwarf2out.h (dwarf2cfi_cc_finalize): New decl.
> > > * ggc-common.cc (ggc_mark_roots): Multiply by rti->nelt
> > > when
> > > clearing the deletable gcc_root_tab_t.
> > > (ggc_common_finalize): New.
> > > * ggc.h (ggc_common_finalize): New decl.
> > > * toplev.cc (toplev::finalize): Call
> > > dwarf2cfi_cc_finalize
> > > and
> > > ggc_common_finalize.
> > > ---
> > > gcc/dwarf2cfi.cc | 9 +
> > > gcc/dwarf2out.h | 1 +
> > > gcc/ggc-common.cc | 23 ++-
> > > gcc/ggc.h | 2 ++
> > > gcc/toplev.cc | 3 +++
> > > 5 files changed, 37 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/gcc/dwarf2cfi.cc b/gcc/dwarf2cfi.cc
> > > index ddc728f4ad00..f1777c0a4cf1 100644
> > > --- a/gcc/dwarf2cfi.cc
> > > +++ b/gcc/dwarf2cfi.cc
> > > @@ -3822,4 +3822,13 @@ make_pass_dwarf2_frame (gcc::context
> > > *ctxt)
> > > return new pass_dwarf2_frame (ctxt);
> > > }
> > >
> > > +void dwarf2cfi_cc_finalize ()
> > > +{
> > > + add_cfi_insn = NULL;
> > > + add_cfi_vec = NULL;
> > > + cur_trace = NULL;
> > > + cur_row = NULL;
> > > + cur_cfa = NULL;
> > > +}
> > > +
> > > #include "gt-dwarf2cfi.h"
> > > diff --git a/gcc/dwarf2out.h b/gcc/dwarf2out.h
> > > index 870b56a6a372..61a996050ff9 100644
> > > --- a/gcc/dwarf2out.h
> > > +++ b/gcc/dwarf2out.h
> > > @@ -419,6 +419,7 @@ struct fixed_point_type_info
> > > } scale_factor;
> > > };
> > >
> > > +void dwarf2cfi_cc_finalize (void);
> > > void dwarf2out_cc_finalize (void);
> > >
> > > /* Some DWARF internals are exposed for the needs of DWARF-based
> > > debug
> > > diff --git
Re: [PATCH] ggc, jit: forcibly clear GTY roots in jit
It seems to not be enough to fix the issue.
Let me find out what's missing from my patch.
On Tue, 2023-09-12 at 11:35 +0200, Richard Biener via Jit wrote:
> On Wed, Sep 6, 2023 at 3:41 PM David Malcolm via Gcc-patches
> wrote:
> >
> > As part of Antoyo's work on supporting LTO in rustc_codegen_gcc, he
> > noticed an ICE inside libgccjit when compiling certain rust files.
> >
> > Debugging libgccjit showed that outdated information from a
> > previous
> > in-memory compile was referring to ad-hoc locations in the previous
> > compile's line_table.
> >
> > The issue turned out to be the function decls in
> > internal_fn_fnspec_array
> > from the previous compile keeping alive the symtab nodes for these
> > functions, and from this finding other functions in the previous
> > compile, walking their CFGs, and finding ad-hoc data pointers in an
> > edge
> > with a location_t using ad-hoc data from the previous line_table
> > instance, and thus a use-after-free ICE attempting to use this ad-
> > hoc
> > data.
> >
> > Previously in toplev::finalize we've fixed global state "piecemeal"
> > by
> > calling out to individual source_name_cc_finalize functions.
> > However,
> > it occurred to me that we have run-time information on where the
> > GTY-marked pointers are.
> >
> > Hence this patch takes something of a "big hammer" approach by
> > adding a
> > new ggc_common_finalize that walks the GC roots, zeroing all of the
> > pointers. I stepped through this in the debugger and observed
> > that, in
> > particular, this correctly zeroes the internal_fn_fnspec_array at
> > the end
> > of a libgccjit compile. Antoyo reports that this fixes the ICE for
> > him.
> > Doing so uncovered an ICE with libgccjit in dwarf2cfi.cc due to
> > reuse of
> > global variables from the previous compile, which this patch also
> > fixes.
> >
> > I noticed that in ggc_mark_roots when clearing deletable roots we
> > only
> > clear the initial element in each gcc_root_tab_t. This looks like
> > a
> > latent bug to me, which the patch fixes. That said, there don't
> > seem to
> > be any deletable roots where the number of elements != 1.
> >
> > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> >
> > OK for trunk?
>
> OK.
>
> Thanks,
> Richard.
>
> > Thanks
> > Dave
> >
> > gcc/ChangeLog:
> > * dwarf2cfi.cc (dwarf2cfi_cc_finalize): New.
> > * dwarf2out.h (dwarf2cfi_cc_finalize): New decl.
> > * ggc-common.cc (ggc_mark_roots): Multiply by rti->nelt
> > when
> > clearing the deletable gcc_root_tab_t.
> > (ggc_common_finalize): New.
> > * ggc.h (ggc_common_finalize): New decl.
> > * toplev.cc (toplev::finalize): Call dwarf2cfi_cc_finalize
> > and
> > ggc_common_finalize.
> > ---
> > gcc/dwarf2cfi.cc | 9 +
> > gcc/dwarf2out.h | 1 +
> > gcc/ggc-common.cc | 23 ++-
> > gcc/ggc.h | 2 ++
> > gcc/toplev.cc | 3 +++
> > 5 files changed, 37 insertions(+), 1 deletion(-)
> >
> > diff --git a/gcc/dwarf2cfi.cc b/gcc/dwarf2cfi.cc
> > index ddc728f4ad00..f1777c0a4cf1 100644
> > --- a/gcc/dwarf2cfi.cc
> > +++ b/gcc/dwarf2cfi.cc
> > @@ -3822,4 +3822,13 @@ make_pass_dwarf2_frame (gcc::context *ctxt)
> > return new pass_dwarf2_frame (ctxt);
> > }
> >
> > +void dwarf2cfi_cc_finalize ()
> > +{
> > + add_cfi_insn = NULL;
> > + add_cfi_vec = NULL;
> > + cur_trace = NULL;
> > + cur_row = NULL;
> > + cur_cfa = NULL;
> > +}
> > +
> > #include "gt-dwarf2cfi.h"
> > diff --git a/gcc/dwarf2out.h b/gcc/dwarf2out.h
> > index 870b56a6a372..61a996050ff9 100644
> > --- a/gcc/dwarf2out.h
> > +++ b/gcc/dwarf2out.h
> > @@ -419,6 +419,7 @@ struct fixed_point_type_info
> > } scale_factor;
> > };
> >
> > +void dwarf2cfi_cc_finalize (void);
> > void dwarf2out_cc_finalize (void);
> >
> > /* Some DWARF internals are exposed for the needs of DWARF-based
> > debug
> > diff --git a/gcc/ggc-common.cc b/gcc/ggc-common.cc
> > index bed7a9d4d021..95803fa95a17 100644
> > --- a/gcc/ggc-common.cc
> > +++ b/gcc/ggc-common.cc
> > @@ -86,7 +86,7 @@ ggc_mark_roots (void)
> >
> > for (rt = gt_ggc_deletable_rtab; *rt; rt++)
> > for (rti = *rt; rti->base != NULL; rti++)
> > - memset (rti->base, 0, rti->stride);
> > + memset (rti->base, 0, rti->stride * rti->nelt);
> >
> > for (rt = gt_ggc_rtab; *rt; rt++)
> > ggc_mark_root_tab (*rt);
> > @@ -1293,3 +1293,24 @@ report_heap_memory_use ()
> > SIZE_AMOUNT (MALLINFO_FN ().arena));
> > #endif
> > }
> > +
> > +/* Forcibly clear all GTY roots. */
> > +
> > +void
> > +ggc_common_finalize ()
> > +{
> > + const struct ggc_root_tab *const *rt;
> > + const_ggc_root_tab_t rti;
> > +
> > + for (rt = gt_ggc_deletable_rtab; *rt; rt++)
> > + for (rti = *rt; rti->base != NULL; rti++)
> > + memset (rti->base, 0, rti->stride * rti->nelt);
> > +
> > + for (rt = gt_ggc_rtab; *rt; rt++)
> > + for (rti = *rt; rti->base != NULL; rti++)
> > + memset
Re: [PATCH] ggc, jit: forcibly clear GTY roots in jit
Hi.
I'll do another test to make sure this is enough since I tested with a
few more finalize functions.
Thanks a lot for finding this!
On Wed, 2023-09-06 at 09:40 -0400, David Malcolm via Jit wrote:
> As part of Antoyo's work on supporting LTO in rustc_codegen_gcc, he
> noticed an ICE inside libgccjit when compiling certain rust files.
>
> Debugging libgccjit showed that outdated information from a previous
> in-memory compile was referring to ad-hoc locations in the previous
> compile's line_table.
>
> The issue turned out to be the function decls in
> internal_fn_fnspec_array
> from the previous compile keeping alive the symtab nodes for these
> functions, and from this finding other functions in the previous
> compile, walking their CFGs, and finding ad-hoc data pointers in an
> edge
> with a location_t using ad-hoc data from the previous line_table
> instance, and thus a use-after-free ICE attempting to use this ad-hoc
> data.
>
> Previously in toplev::finalize we've fixed global state "piecemeal"
> by
> calling out to individual source_name_cc_finalize functions.
> However,
> it occurred to me that we have run-time information on where the
> GTY-marked pointers are.
>
> Hence this patch takes something of a "big hammer" approach by adding
> a
> new ggc_common_finalize that walks the GC roots, zeroing all of the
> pointers. I stepped through this in the debugger and observed that,
> in
> particular, this correctly zeroes the internal_fn_fnspec_array at the
> end
> of a libgccjit compile. Antoyo reports that this fixes the ICE for
> him.
> Doing so uncovered an ICE with libgccjit in dwarf2cfi.cc due to reuse
> of
> global variables from the previous compile, which this patch also
> fixes.
>
> I noticed that in ggc_mark_roots when clearing deletable roots we
> only
> clear the initial element in each gcc_root_tab_t. This looks like a
> latent bug to me, which the patch fixes. That said, there don't seem
> to
> be any deletable roots where the number of elements != 1.
>
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
>
> OK for trunk?
>
> Thanks
> Dave
>
> gcc/ChangeLog:
> * dwarf2cfi.cc (dwarf2cfi_cc_finalize): New.
> * dwarf2out.h (dwarf2cfi_cc_finalize): New decl.
> * ggc-common.cc (ggc_mark_roots): Multiply by rti->nelt when
> clearing the deletable gcc_root_tab_t.
> (ggc_common_finalize): New.
> * ggc.h (ggc_common_finalize): New decl.
> * toplev.cc (toplev::finalize): Call dwarf2cfi_cc_finalize
> and
> ggc_common_finalize.
> ---
> gcc/dwarf2cfi.cc | 9 +
> gcc/dwarf2out.h | 1 +
> gcc/ggc-common.cc | 23 ++-
> gcc/ggc.h | 2 ++
> gcc/toplev.cc | 3 +++
> 5 files changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/dwarf2cfi.cc b/gcc/dwarf2cfi.cc
> index ddc728f4ad00..f1777c0a4cf1 100644
> --- a/gcc/dwarf2cfi.cc
> +++ b/gcc/dwarf2cfi.cc
> @@ -3822,4 +3822,13 @@ make_pass_dwarf2_frame (gcc::context *ctxt)
> return new pass_dwarf2_frame (ctxt);
> }
>
> +void dwarf2cfi_cc_finalize ()
> +{
> + add_cfi_insn = NULL;
> + add_cfi_vec = NULL;
> + cur_trace = NULL;
> + cur_row = NULL;
> + cur_cfa = NULL;
> +}
> +
> #include "gt-dwarf2cfi.h"
> diff --git a/gcc/dwarf2out.h b/gcc/dwarf2out.h
> index 870b56a6a372..61a996050ff9 100644
> --- a/gcc/dwarf2out.h
> +++ b/gcc/dwarf2out.h
> @@ -419,6 +419,7 @@ struct fixed_point_type_info
> } scale_factor;
> };
>
> +void dwarf2cfi_cc_finalize (void);
> void dwarf2out_cc_finalize (void);
>
> /* Some DWARF internals are exposed for the needs of DWARF-based
> debug
> diff --git a/gcc/ggc-common.cc b/gcc/ggc-common.cc
> index bed7a9d4d021..95803fa95a17 100644
> --- a/gcc/ggc-common.cc
> +++ b/gcc/ggc-common.cc
> @@ -86,7 +86,7 @@ ggc_mark_roots (void)
>
> for (rt = gt_ggc_deletable_rtab; *rt; rt++)
> for (rti = *rt; rti->base != NULL; rti++)
> - memset (rti->base, 0, rti->stride);
> + memset (rti->base, 0, rti->stride * rti->nelt);
>
> for (rt = gt_ggc_rtab; *rt; rt++)
> ggc_mark_root_tab (*rt);
> @@ -1293,3 +1293,24 @@ report_heap_memory_use ()
> SIZE_AMOUNT (MALLINFO_FN ().arena));
> #endif
> }
> +
> +/* Forcibly clear all GTY roots. */
> +
> +void
> +ggc_common_finalize ()
> +{
> + const struct ggc_root_tab *const *rt;
> + const_ggc_root_tab_t rti;
> +
> + for (rt = gt_ggc_deletable_rtab; *rt; rt++)
> + for (rti = *rt; rti->base != NULL; rti++)
> + memset (rti->base, 0, rti->stride * rti->nelt);
> +
> + for (rt = gt_ggc_rtab; *rt; rt++)
> + for (rti = *rt; rti->base != NULL; rti++)
> + memset (rti->base, 0, rti->stride * rti->nelt);
> +
> + for (rt = gt_pch_scalar_rtab; *rt; rt++)
> + for (rti = *rt; rti->base != NULL; rti++)
> + memset (rti->base, 0, rti->stride * rti->nelt);
> +}
> diff --git a/gcc/ggc.h b/gcc/ggc.h
> index 34108e2f0061..3280314f8481 100644
> --- a/gcc/ggc.h
> +++ b/gcc/ggc.h
> @@ -368,4 +368,6 @@ inline
Re: [PATCH] libgccjit: Add support for `restrict` attribute on function parameters
Since the tests in the PR for rustc_codegen_gcc
(https://github.com/rust-lang/rustc_codegen_gcc/pull/312) currently
fails, let's wait a bit before merging the patch, in case it would need
some fixes.
On Thu, 2023-08-17 at 20:09 +0200, Guillaume Gomez via Jit wrote:
> Quick question: do you plan to make the merge or should I ask Antoni?
>
> Le jeu. 17 août 2023 à 17:59, Guillaume Gomez
>
> a écrit :
>
> > Thanks for the review!
> >
> > Le jeu. 17 août 2023 à 17:50, David Malcolm a
> > écrit
> > :
> > >
> > > On Thu, 2023-08-17 at 17:41 +0200, Guillaume Gomez wrote:
> > > > And now I just discovered that a lot of commits from Antoni's
> > > > fork
> > > > haven't been sent upstream which is why the ABI count is so
> > > > high in
> > > > his repository. Fixed that as well.
> > >
> > > Thanks for the updated patch; I was about to comment on that.
> > >
> > > This version is good for gcc trunk.
> > >
> > > Dave
> > >
> > > >
> > > > Le jeu. 17 août 2023 à 17:26, Guillaume Gomez
> > > > a écrit :
> > > > >
> > > > > Antoni spot a typo I made:
> > > > >
> > > > > I added `LIBGCCJIT_HAVE_gcc_jit_type_get_size` instead of
> > > > > `LIBGCCJIT_HAVE_gcc_jit_type_get_restrict`. Fixed in this
> > > > > patch,
> > > > > sorry
> > > > > for the noise.
> > > > >
> > > > > Le jeu. 17 août 2023 à 11:30, Guillaume Gomez
> > > > > a écrit :
> > > > > >
> > > > > > Hi Dave,
> > > > > >
> > > > > > > What kind of testing has the patch had? (e.g. did you run
> > > > > > > "make
> > > > > > > check-
> > > > > > > jit" ? Has this been in use on real Rust code?)
> > > > > >
> > > > > > I tested it as Rust backend directly on this code:
> > > > > >
> > > > > > ```
> > > > > > pub fn foo(a: i32, b: i32, c: ) {
> > > > > > *a += *c;
> > > > > > *b += *c;
> > > > > > }
> > > > > > ```
> > > > > >
> > > > > > I ran it with `rustc` (and the GCC backend) with the
> > > > > > following
> > > > > > flags:
> > > > > > `-C link-args=-lc --emit=asm -O --crate-type=lib` which
> > > > > > gave the
> > > > > > diff
> > > > > > you can see in the attached file. Explanations: the diff on
> > > > > > the
> > > > > > right
> > > > > > has the `__restrict__` attribute used whereas on the left
> > > > > > it is
> > > > > > the
> > > > > > current version where we don't handle it.
> > > > > >
> > > > > > As for C testing, I used this code:
> > > > > >
> > > > > > ```
> > > > > > void t(int *__restrict__ a, int *__restrict__ b, char
> > > > > > *__restrict__ c) {
> > > > > > *a += *c;
> > > > > > *b += *c;
> > > > > > }
> > > > > > ```
> > > > > >
> > > > > > (without the `__restrict__` of course when I need to have a
> > > > > > witness
> > > > > > ASM). I attached the diff as well, this time the file with
> > > > > > the
> > > > > > use of
> > > > > > `__restrict__` in on the left. I compiled with the
> > > > > > following
> > > > > > flags:
> > > > > > `-S -O3`.
> > > > > >
> > > > > > > Please add a feature macro:
> > > > > > > #define LIBGCCJIT_HAVE_gcc_jit_type_get_restrict
> > > > > > > (see the similar ones in the header).
> > > > > >
> > > > > > I added `LIBGCCJIT_HAVE_gcc_jit_type_get_size` and extended
> > > > > > the
> > > > > > documentation as well to mention the ABI change.
> > > > > >
> > > > > > > Please add a new ABI tag (LIBGCCJIT_ABI_25 ?), rather
> > > > > > > than
> > > > > > > adding this
> > > > > > > to ABI_0.
> > > > > >
> > > > > > I added `LIBGCCJIT_ABI_34` as `LIBGCCJIT_ABI_33` was the
> > > > > > last
> > > > > > one.
> > > > > >
> > > > > > > This refers to a "cold attribute"; is this a vestige of a
> > > > > > > copy-
> > > > > > > and-
> > > > > > > paste from a different test case?
> > > > > >
> > > > > > It is a vestige indeed... Missed this one.
> > > > > >
> > > > > > > I see that the test scans the generated assembler. Does
> > > > > > > the
> > > > > > > test
> > > > > > > actually verify that restrict has an effect, or was that
> > > > > > > another
> > > > > > > vestige from a different test case?
> > > > > >
> > > > > > No, this time it's what I wanted. Please see the C diff I
> > > > > > provided
> > > > > > above to see that the ASM has a small diff that allowed me
> > > > > > to
> > > > > > confirm
> > > > > > that the `__restrict__` attribute was correctly set.
> > > > > >
> > > > > > > If this test is meant to run at -O3 and thus can't be
> > > > > > > part of
> > > > > > > test-
> > > > > > > combination.c, please add a comment about it to
> > > > > > > gcc/testsuite/jit.dg/all-non-failing-tests.h (in the
> > > > > > > alphabetical
> > > > > > > place).
> > > > > >
> > > > > > Below `-O3`, this ASM difference doesn't appear
> > > > > > unfortunately.
> > > > > >
> > > > > > > The patch also needs to add documentation for the new
> > > > > > > entrypoint (in
> > > > > > > topics/types.rst), and for the new ABI tag (in
> > > > > > > topics/compatibility.rst).
> > > > > >
> > > > > > Added!
> > > > > >
> > > > > > > Thanks again for the patch; hope
Re: [PATCH] libgccjit: Add support for machine-dependent builtins
I forgot to attach the patch. Here it is. On Sat, 2023-02-11 at 19:30 -0500, Antoni Boucher via Jit 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? > > Thanks for the review. From f1f4a113853b416776253b596d7feeb87e608bfd 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/config: PR jit/108762 * i386/i386-builtins.cc: New function (clear_builtin_types). gcc/jit: PR jit/108762 * docs/topics/compatibility.rst (LIBGCCJIT_ABI_25): New ABI tag. * docs/topics/expressions.rst: Add documentation for the functions gcc_jit_context_new_rvalue_vector_perm and gcc_jit_context_new_vector_access. * docs/topics/functions.rst: Add documentation for the function gcc_jit_context_get_target_builtin_function. * docs/topics/types.rst: Add documentation for GCC_JIT_TYPE_BFLOAT16. * 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, new functions (new_rvalue_vector_perm, common_mark_addressable_vec, gnu_vector_type_p, lvalue_p, convert_vector_to_array_for_subscript, new_vector_access). * jit-playback.h: New argument is_target_builtin to new_function, new functions (new_rvalue_vector_perm, new_vector_access). * jit-recording.cc: New argument is_target_builtin to new_function_type, function_type constructor and function constructor, new functions (get_target_builtin_function, new_rvalue_vector_perm, new_vector_access, memento_of_new_rvalue_vector_perm, memento_of_new_rvalue_vector_perm::replay_into, memento_of_new_rvalue_vector_perm::visit_children, memento_of_new_rvalue_vector_perm::make_debug_string, memento_of_new_rvalue_vector_perm::write_reproducer, vector_access::replay_into, vector_access::visit_children, vector_access::make_debug_string, vector_access::write_reproducer). * 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 classes memento_of_new_rvalue_vector_perm and vector_access, new functions (get_target_builtin_function, new_rvalue_vector_perm, new_vector_access, copy, memento_of_new_rvalue_vector_perm, memento_of_new_rvalue_vector_perm::replay_into, memento_of_new_rvalue_vector_perm::visit_children, memento_of_new_rvalue_vector_perm::make_debug_string, memento_of_new_rvalue_vector_perm::write_reproducer, vector_access::replay_into, vector_access::visit_children, vector_access::make_debug_string, vector_access::write_reproducer). * libgccjit.cc: New functions (gcc_jit_context_get_target_builtin_function, gcc_jit_context_new_vector_access, gcc_jit_context_new_rvalue_vector_perm). * libgccjit.h: New variant GCC_JIT_TYPE_BFLOAT16 en enum gcc_jit_types, new functions (gcc_jit_context_get_target_builtin_function, gcc_jit_context_new_vector_access, gcc_jit_context_new_rvalue_vector_perm). * libgccjit.map: New functions (gcc_jit_context_get_target_builtin_function, gcc_jit_context_new_rvalue_vector_perm, gcc_jit_context_new_vector_access). 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| 10 + gcc/jit/docs/topics/expressions.rst | 45 gcc/jit/docs/topics/functions.rst| 19 ++ gcc/jit/docs/topics/types.rst| 2 + gcc/jit/dummy-frontend.cc| 203 ++- gcc/jit/jit-builtins.cc | 6 +- gcc/jit/jit-common.h | 2 +- gcc/jit/jit-playback.cc | 166 +++- gcc/jit/jit-playback.h | 16 +- gcc/jit/jit-recording.cc | 255 ++- gcc/jit/jit-recording.h | 176 - gcc/jit/libgccjit.cc | 127 + gcc/jit/libgccjit.h | 44 +++- gcc/jit/libgccjit.map| 7 +
[PATCH] libgccjit: Add support for machine-dependent builtins
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? Thanks for the review.
Re: [PATCH] libgccjit: Fix float vector comparison
Ping David:
Some more notes about the try/catch API:
I finally got unwinding implemented in rustc_codegen_gcc with the
following GCC patch:
https://github.com/antoyo/gcc/commit/fd603a3c715d3708f831cb637fbcc48bf4641859
It still requires clean-up, but you can have a look at it.
I'm still unsure for the CFG:
currently, it requires the finally to be terminated which would prevent
a finally reached through unwinding to work correctly; unless you call
unwind_resume, in which case, that would probably prevent a normal
finally (e.g. reached not by unwinding, but by falling off the try).
I'll try to not require the finally block to be terminated, but I
remember having issues making that work.
What are your thoughts on this?
On Fri, 2022-12-02 at 09:29 -0500, Antoni Boucher wrote:
> On Thu, 2022-12-01 at 11:57 -0500, David Malcolm wrote:
> > On Thu, 2022-12-01 at 10:33 -0500, Antoni Boucher wrote:
> > > On Thu, 2022-12-01 at 10:25 -0500, David Malcolm wrote:
> > > > On Thu, 2022-12-01 at 10:01 -0500, Antoni Boucher wrote:
> > > > > Thanks, David.
> > > > > Since we're not in phase 1 anymore, do we need an approval
> > > > > before
> > > > > I
> > > > > merge like last year or can I merge immediately?
> > > >
> > > > I think it counts as a bug fix and thus you can go ahead and
> > > > merge
> > > > (assuming you've done the usual testing).
> > > >
> > > > > I also have many other patches (all in jit) that I need to
> > > > > prepare
> > > > > and
> > > > > post to this mailing list.
> > > > > What do you think?
> > > >
> > > > Given that you're one of the main users of libgccjit I think
> > > > there's
> > > > a
> > > > case for stretching the deadlines a bit here.
> > > >
> > > > Do you have a repo I can look at?
> > >
> > > Yes! The commits are in my fork:
> > > https://github.com/antoyo/gcc
> > >
> > > The only big one is the one adding support for target-dependent
> > > builtins:
> > > https://github.com/antoyo/gcc/commit/6d4313d4c02dd878f43917c978f299f5119330f0
> > >
> > > Regarding this one, there's the issue that since we record the
> > > builtins
> > > on the first context run, we only have access to the builtins
> > > from
> > > the
> > > second run.
> > > Do you have any idea how to fix this?
> > > Or do you consider this is acceptable?
> >
> > This is implemented behind the new
> > gcc_jit_context_get_target_builtin_function entrypoint, right?
>
> Yes.
>
> >
> > If so, perhaps that recording::context::get_target_builtin_function
> > could detect if it's the first time it's been called on this
> > context,
> > and if so make a playback::context to do the detection? That way
> > it
> > would be transparent to the user, and work first time.
>
> Oh, the issue is actually with the type reflection API and also the
> type checking of function calls, so it's in the recording phase.
> While I could think of a workaround for the type checking (e.g.
> delayed
> type checking at the playback phase), I could not think of any better
> solution for the type reflection.
>
> >
> >
> > 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.
>
> Thanks for the suggestion; I'll look into that.
>
> >
> >
> > >
> > > I also have a WIP branch which adds support for try/catch:
> > > https://github.com/antoyo/gcc/commit/6219339fcacb079431596a0bc6cf8d430a1bd5a1
> > > I'm not sure if this one is going to be ready soon or not.
> >
> > I see that the new entrypoints have e.g.:
> >
> > /* Add a try/catch statement.
> > This is equivalent to this C++ code:
> > try {
> > try_block
> > }
> > catch {
> > catch_block
> > }
> > */
> >
> > void
> > gcc_jit_block_add_try_catch (gcc_jit_block *block,
> > gcc_jit_location *loc,
> > gcc_jit_block *try_block,
> > gcc_jit_block *catch_block);
> >
> > but I'm not sure how this is meant to interact with the CFG-like
> > model
> > used by the rest of the gcc_jit_block_* API. What happens at the
> > end
> > of the blocks? Does the generated code use the C++ ABI for
> > exception-
> > handling?
>
> Currently, it requires the try and catch blocks to be terminated, but
> also require the block containing the try/catch to be terminated.
> That doesn't make sense.
> Would it be OK if it
Re: [PATCH] libgccjit: Fix a failing test
Thanks! In your patch, you're missing this line at the end of the commit message: Signed-off-by: Guillaume Gomez On Wed, 2022-12-14 at 14:39 +0100, Guillaume Gomez via Jit wrote: > Hi, > > This fixes bug 107999. > > Thanks in advance for the review.
Re: [PATCH] libgccjit: Allow comparing vector types
Thanks!
David: you mentioned gcc 10. For now, I only intend to make changes to
the next release (13). Is this OK or should I backport all my fixes to
all active releases? (I'm not sure what are GCC policies here.)
On Tue, 2022-12-13 at 16:24 -0500, David Malcolm wrote:
> On Mon, 2022-12-12 at 21:31 -0500, Antoni Boucher via Jit wrote:
> > Hi.
> > This fixes bug 108078.
> > Thanks for the review.
>
> [...snip...]
>
> > diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
> > index 5d7c7177cc3..4ec0fff4843 100644
> > --- a/gcc/jit/jit-recording.h
> > +++ b/gcc/jit/jit-recording.h
> > @@ -806,6 +806,15 @@ public:
> >
> > void replay_into (replayer *) final override;
> >
> > + virtual bool is_same_type_as (type *other)
>
> This would be better with a "final override" (and without the
> "virtual").
>
> > + {
> > + vector_type *other_vec_type = other->dyn_cast_vector_type ();
> > + if (other_vec_type == NULL)
> > + return false;
> > + return get_num_units () == other_vec_type->get_num_units ()
> > + && get_element_type () == other_vec_type->get_element_type
> > ();
> > + }
> > +
>
> OK for active branches with that nit fixed (though for gcc 10 you'd
> have to spell final and override as "FINAL" and "OVERRIDE" due to
> needing to be buildable with a C++98 compiler; not sure if gcc 10's
> libgccjit even has vector types though).
>
> [...snip...]
>
> Thanks for the patch
>
> Dave
>
[PATCH] libgccjit: Allow comparing vector types
Hi.
This fixes bug 108078.
Thanks for the review.
From 016d23eeab1536e2ce0607d422fe4bb42b55c2dc Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Fri, 24 Jun 2022 21:05:29 -0400
Subject: [PATCH] libgccjit: Allow comparing vector types
gcc/jit/ChangeLog:
PR jit/108078
* jit-recording.h: Add vector_type::is_same_type_as method
gcc/testsuite/ChangeLog:
PR jit/108078
* jit.dg/test-vector-types.cc: Add tests for vector type comparison
Co-authored-by: Guillaume Gomez
---
gcc/jit/jit-recording.h | 9 +
gcc/testsuite/jit.dg/test-vector-types.cc | 13 +
2 files changed, 22 insertions(+)
diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
index 5d7c7177cc3..4ec0fff4843 100644
--- a/gcc/jit/jit-recording.h
+++ b/gcc/jit/jit-recording.h
@@ -806,6 +806,15 @@ public:
void replay_into (replayer *) final override;
+ virtual bool is_same_type_as (type *other)
+ {
+vector_type *other_vec_type = other->dyn_cast_vector_type ();
+if (other_vec_type == NULL)
+ return false;
+return get_num_units () == other_vec_type->get_num_units ()
+ && get_element_type () == other_vec_type->get_element_type ();
+ }
+
vector_type *is_vector () final override { return this; }
private:
diff --git a/gcc/testsuite/jit.dg/test-vector-types.cc b/gcc/testsuite/jit.dg/test-vector-types.cc
index 1f49be6b59f..5661d1b9eb4 100644
--- a/gcc/testsuite/jit.dg/test-vector-types.cc
+++ b/gcc/testsuite/jit.dg/test-vector-types.cc
@@ -105,6 +105,19 @@ create_code (gcc_jit_context *ctxt, void *user_data)
v4f_type, GCC_JIT_BINARY_OP_MULT);
create_vec_fn (ctxt, "jit_v4f_div",
v4f_type, GCC_JIT_BINARY_OP_DIVIDE);
+
+ // Checking compatibility between types.
+ CHECK_VALUE(gcc_jit_compatible_types(v4si_type, v4ui_type), 0);
+ CHECK_VALUE(gcc_jit_compatible_types(v4si_type, v4f_type), 0);
+ CHECK_VALUE(gcc_jit_compatible_types(v4ui_type, v4f_type), 0);
+
+ gcc_jit_type *v4si_type2 = gcc_jit_type_get_vector (int_type, 4);
+ gcc_jit_type *v4ui_type2 = gcc_jit_type_get_vector (unsigned_type, 4);
+ gcc_jit_type *v4f_type2 = gcc_jit_type_get_vector (float_type, 4);
+
+ CHECK_VALUE(gcc_jit_compatible_types(v4si_type, v4si_type2), 1);
+ CHECK_VALUE(gcc_jit_compatible_types(v4ui_type, v4ui_type2), 1);
+ CHECK_VALUE(gcc_jit_compatible_types(v4f_type, v4f_type2), 1);
}
template
--
2.26.2.7.g19db9cfb68.dirty
Re: [PATCH] libgccjit: Fix float vector comparison
I'm posting the patch again so that you can double-check that I wrote
the DCO for the co-author correctly.
Does that look good?
Thanks.
On Thu, 2022-12-01 at 11:57 -0500, David Malcolm wrote:
> On Thu, 2022-12-01 at 10:33 -0500, Antoni Boucher wrote:
> > On Thu, 2022-12-01 at 10:25 -0500, David Malcolm wrote:
> > > On Thu, 2022-12-01 at 10:01 -0500, Antoni Boucher wrote:
> > > > Thanks, David.
> > > > Since we're not in phase 1 anymore, do we need an approval
> > > > before
> > > > I
> > > > merge like last year or can I merge immediately?
> > >
> > > I think it counts as a bug fix and thus you can go ahead and
> > > merge
> > > (assuming you've done the usual testing).
> > >
> > > > I also have many other patches (all in jit) that I need to
> > > > prepare
> > > > and
> > > > post to this mailing list.
> > > > What do you think?
> > >
> > > Given that you're one of the main users of libgccjit I think
> > > there's
> > > a
> > > case for stretching the deadlines a bit here.
> > >
> > > Do you have a repo I can look at?
> >
> > Yes! The commits are in my fork:
> > https://github.com/antoyo/gcc
> >
> > The only big one is the one adding support for target-dependent
> > builtins:
> > https://github.com/antoyo/gcc/commit/6d4313d4c02dd878f43917c978f299f5119330f0
> >
> > Regarding this one, there's the issue that since we record the
> > builtins
> > on the first context run, we only have access to the builtins from
> > the
> > second run.
> > Do you have any idea how to fix this?
> > Or do you consider this is acceptable?
>
> This is implemented behind the new
> gcc_jit_context_get_target_builtin_function entrypoint, right?
>
> If so, perhaps that recording::context::get_target_builtin_function
> could detect if it's the first time it's been called on this context,
> and if so make a playback::context to do the detection? That way it
> would be transparent to the user, and work first time.
>
>
> 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.
>
>
> >
> > I also have a WIP branch which adds support for try/catch:
> > https://github.com/antoyo/gcc/commit/6219339fcacb079431596a0bc6cf8d430a1bd5a1
> > I'm not sure if this one is going to be ready soon or not.
>
> I see that the new entrypoints have e.g.:
>
> /* Add a try/catch statement.
> This is equivalent to this C++ code:
> try {
> try_block
> }
> catch {
> catch_block
> }
> */
>
> void
> gcc_jit_block_add_try_catch (gcc_jit_block *block,
> gcc_jit_location *loc,
> gcc_jit_block *try_block,
> gcc_jit_block *catch_block);
>
> but I'm not sure how this is meant to interact with the CFG-like
> model
> used by the rest of the gcc_jit_block_* API. What happens at the end
> of the blocks? Does the generated code use the C++ ABI for
> exception-
> handling?
>
> Dave
>
> >
> > Thanks.
> >
> > >
> > > Dave
> > >
> > >
> > > >
> > > > On Thu, 2022-12-01 at 09:28 -0500, David Malcolm wrote:
> > > > > On Sun, 2022-11-20 at 14:03 -0500, Antoni Boucher via Jit
> > > > > wrote:
> > > > > > Hi.
> > > > > > This fixes bug 107770.
> > > > > > Thanks for the review.
> > > > >
> > > > > Thanks, the patch looks good to me.
> > > > >
> > > > > Dave
> > > > >
> > > >
> > >
> >
>
From c28749d9a4a7535f7f561127e0f02a0635fb4ae7 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sun, 20 Nov 2022 10:22:53 -0500
Subject: [PATCH] libgccjit: Fix float vector comparison
Fix float vector comparison and add comparison tests didn't include float and
vectors.
gcc/testsuite:
PR jit/107770
* jit.dg/harness.h: Add new macro to to perform vector
comparisons
* jit.dg/test-expressions.c: Extend comparison tests to add float
types and vectors
gcc/jit:
PR jit/107770
* jit-playback.cc: Fix vector float comparison
* jit-playback.h: Update comparison function signature
* jit-recording.cc: Update call for "new_comparison" function
* jit-recording.h: Fix vector float comparison
Co-authored-by: Guillaume Gomez
Signed-off-by: Guillaume Gomez
---
gcc/jit/jit-playback.cc | 27 ++-
gcc/jit/jit-playback.h | 2 +-
gcc/jit/jit-recording.cc| 3 +-
gcc/jit/jit-recording.h | 18 +-
gcc/testsuite/jit.dg/harness.h | 15 ++
Re: [PATCH] libgccjit: Fix float vector comparison
On Thu, 2022-12-01 at 11:57 -0500, David Malcolm wrote:
> On Thu, 2022-12-01 at 10:33 -0500, Antoni Boucher wrote:
> > On Thu, 2022-12-01 at 10:25 -0500, David Malcolm wrote:
> > > On Thu, 2022-12-01 at 10:01 -0500, Antoni Boucher wrote:
> > > > Thanks, David.
> > > > Since we're not in phase 1 anymore, do we need an approval
> > > > before
> > > > I
> > > > merge like last year or can I merge immediately?
> > >
> > > I think it counts as a bug fix and thus you can go ahead and
> > > merge
> > > (assuming you've done the usual testing).
> > >
> > > > I also have many other patches (all in jit) that I need to
> > > > prepare
> > > > and
> > > > post to this mailing list.
> > > > What do you think?
> > >
> > > Given that you're one of the main users of libgccjit I think
> > > there's
> > > a
> > > case for stretching the deadlines a bit here.
> > >
> > > Do you have a repo I can look at?
> >
> > Yes! The commits are in my fork:
> > https://github.com/antoyo/gcc
> >
> > The only big one is the one adding support for target-dependent
> > builtins:
> > https://github.com/antoyo/gcc/commit/6d4313d4c02dd878f43917c978f299f5119330f0
> >
> > Regarding this one, there's the issue that since we record the
> > builtins
> > on the first context run, we only have access to the builtins from
> > the
> > second run.
> > Do you have any idea how to fix this?
> > Or do you consider this is acceptable?
>
> This is implemented behind the new
> gcc_jit_context_get_target_builtin_function entrypoint, right?
Yes.
>
> If so, perhaps that recording::context::get_target_builtin_function
> could detect if it's the first time it's been called on this context,
> and if so make a playback::context to do the detection? That way it
> would be transparent to the user, and work first time.
Oh, the issue is actually with the type reflection API and also the
type checking of function calls, so it's in the recording phase.
While I could think of a workaround for the type checking (e.g. delayed
type checking at the playback phase), I could not think of any better
solution for the type reflection.
>
>
> 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.
Thanks for the suggestion; I'll look into that.
>
>
> >
> > I also have a WIP branch which adds support for try/catch:
> > https://github.com/antoyo/gcc/commit/6219339fcacb079431596a0bc6cf8d430a1bd5a1
> > I'm not sure if this one is going to be ready soon or not.
>
> I see that the new entrypoints have e.g.:
>
> /* Add a try/catch statement.
> This is equivalent to this C++ code:
> try {
> try_block
> }
> catch {
> catch_block
> }
> */
>
> void
> gcc_jit_block_add_try_catch (gcc_jit_block *block,
> gcc_jit_location *loc,
> gcc_jit_block *try_block,
> gcc_jit_block *catch_block);
>
> but I'm not sure how this is meant to interact with the CFG-like
> model
> used by the rest of the gcc_jit_block_* API. What happens at the end
> of the blocks? Does the generated code use the C++ ABI for
> exception-
> handling?
Currently, it requires the try and catch blocks to be terminated, but
also require the block containing the try/catch to be terminated.
That doesn't make sense.
Would it be OK if it doesn't require the try and catch blocks to be
terminated?
For the ABI, I'm not sure it's necessarily tied to C++, but I might be
wrong. From what I understand, GCC will use the dwarf-2 exception
handling model if it's available or the sjlj otherwise (perhaps that
can be configured).
And the user can change the personality function via the API I added.
Thanks for your feedback.
>
> Dave
>
> >
> > Thanks.
> >
> > >
> > > Dave
> > >
> > >
> > > >
> > > > On Thu, 2022-12-01 at 09:28 -0500, David Malcolm wrote:
> > > > > On Sun, 2022-11-20 at 14:03 -0500, Antoni Boucher via Jit
> > > > > wrote:
> > > > > > Hi.
> > > > > > This fixes bug 107770.
> > > > > > Thanks for the review.
> > > > >
> > > > > Thanks, the patch looks good to me.
> > > > >
> > > > > Dave
> > > > >
> > > >
> > >
> >
>
Re: [PATCH] libgccjit: Fix float vector comparison
On Thu, 2022-12-01 at 10:25 -0500, David Malcolm wrote: > On Thu, 2022-12-01 at 10:01 -0500, Antoni Boucher wrote: > > Thanks, David. > > Since we're not in phase 1 anymore, do we need an approval before I > > merge like last year or can I merge immediately? > > I think it counts as a bug fix and thus you can go ahead and merge > (assuming you've done the usual testing). > > > I also have many other patches (all in jit) that I need to prepare > > and > > post to this mailing list. > > What do you think? > > Given that you're one of the main users of libgccjit I think there's > a > case for stretching the deadlines a bit here. > > Do you have a repo I can look at? Yes! The commits are in my fork: https://github.com/antoyo/gcc The only big one is the one adding support for target-dependent builtins: https://github.com/antoyo/gcc/commit/6d4313d4c02dd878f43917c978f299f5119330f0 Regarding this one, there's the issue that since we record the builtins on the first context run, we only have access to the builtins from the second run. Do you have any idea how to fix this? Or do you consider this is acceptable? I also have a WIP branch which adds support for try/catch: https://github.com/antoyo/gcc/commit/6219339fcacb079431596a0bc6cf8d430a1bd5a1 I'm not sure if this one is going to be ready soon or not. Thanks. > > Dave > > > > > > On Thu, 2022-12-01 at 09:28 -0500, David Malcolm wrote: > > > On Sun, 2022-11-20 at 14:03 -0500, Antoni Boucher via Jit wrote: > > > > Hi. > > > > This fixes bug 107770. > > > > Thanks for the review. > > > > > > Thanks, the patch looks good to me. > > > > > > Dave > > > > > >
Re: [PATCH] libgccjit: Fix float vector comparison
Thanks, David. Since we're not in phase 1 anymore, do we need an approval before I merge like last year or can I merge immediately? I also have many other patches (all in jit) that I need to prepare and post to this mailing list. What do you think? On Thu, 2022-12-01 at 09:28 -0500, David Malcolm wrote: > On Sun, 2022-11-20 at 14:03 -0500, Antoni Boucher via Jit wrote: > > Hi. > > This fixes bug 107770. > > Thanks for the review. > > Thanks, the patch looks good to me. > > Dave >
Re: [PATCH] libgccjit: Fix float vector comparison
David: PING On Sun, 2022-11-20 at 14:03 -0500, Antoni Boucher wrote: > Hi. > This fixes bug 107770. > Thanks for the review.
[PATCH] libgccjit: Fix float vector comparison
Hi.
This fixes bug 107770.
Thanks for the review.
From 1112e92624d41ec96c366fdb60101e1040462522 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sun, 20 Nov 2022 10:22:53 -0500
Subject: [PATCH] libgccjit: Fix float vector comparison
Fix float vector comparison and add comparison tests didn't include float and
vectors.
gcc/testsuite:
PR jit/107770
* jit.dg/harness.h: Add new macro to to perform vector
comparisons
* jit.dg/test-expressions.c: Extend comparison tests to add float
types and vectors
gcc/jit:
PR jit/107770
* jit-playback.cc: Fix vector float comparison
* jit-playback.h: Update comparison function signature
* jit-recording.cc: Update call for "new_comparison" function
* jit-recording.h: Fix vector float comparison
Co-authored-by: Guillaume Gomez
---
gcc/jit/jit-playback.cc | 27 ++-
gcc/jit/jit-playback.h | 2 +-
gcc/jit/jit-recording.cc| 3 +-
gcc/jit/jit-recording.h | 18 +-
gcc/testsuite/jit.dg/harness.h | 15 ++
gcc/testsuite/jit.dg/test-expressions.c | 234 +++-
6 files changed, 246 insertions(+), 53 deletions(-)
diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
index d227d36283a..2888da16ebf 100644
--- a/gcc/jit/jit-playback.cc
+++ b/gcc/jit/jit-playback.cc
@@ -1213,7 +1213,7 @@ playback::rvalue *
playback::context::
new_comparison (location *loc,
enum gcc_jit_comparison op,
- rvalue *a, rvalue *b)
+ rvalue *a, rvalue *b, type *vec_result_type)
{
// FIXME: type-checking, or coercion?
enum tree_code inner_op;
@@ -1252,10 +1252,27 @@ new_comparison (location *loc,
tree node_b = b->as_tree ();
node_b = fold_const_var (node_b);
- tree inner_expr = build2 (inner_op,
- boolean_type_node,
- node_a,
- node_b);
+ tree inner_expr;
+ tree a_type = TREE_TYPE (node_a);
+ if (VECTOR_TYPE_P (a_type))
+ {
+/* Build a vector comparison. See build_vec_cmp in c-typeck.cc for
+ reference. */
+tree t_vec_result_type = vec_result_type->as_tree ();
+tree zero_vec = build_zero_cst (t_vec_result_type);
+tree minus_one_vec = build_minus_one_cst (t_vec_result_type);
+tree cmp_type = truth_type_for (a_type);
+tree cmp = build2 (inner_op, cmp_type, node_a, node_b);
+inner_expr = build3 (VEC_COND_EXPR, t_vec_result_type, cmp, minus_one_vec,
+ zero_vec);
+ }
+ else
+ {
+inner_expr = build2 (inner_op,
+ boolean_type_node,
+ node_a,
+ node_b);
+ }
/* Try to fold. */
inner_expr = fold (inner_expr);
diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
index 3ba02a0451a..056e5231514 100644
--- a/gcc/jit/jit-playback.h
+++ b/gcc/jit/jit-playback.h
@@ -162,7 +162,7 @@ public:
rvalue *
new_comparison (location *loc,
enum gcc_jit_comparison op,
- rvalue *a, rvalue *b);
+ rvalue *a, rvalue *b, type *vec_result_type);
rvalue *
new_call (location *loc,
diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc
index f78daed2d71..b5eb648ad24 100644
--- a/gcc/jit/jit-recording.cc
+++ b/gcc/jit/jit-recording.cc
@@ -5837,7 +5837,8 @@ recording::comparison::replay_into (replayer *r)
set_playback_obj (r->new_comparison (playback_location (r, m_loc),
m_op,
m_a->playback_rvalue (),
- m_b->playback_rvalue ()));
+ m_b->playback_rvalue (),
+ m_type->playback_type ()));
}
/* Implementation of pure virtual hook recording::rvalue::visit_children
diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
index 8610ea988bd..5d7c7177cc3 100644
--- a/gcc/jit/jit-recording.h
+++ b/gcc/jit/jit-recording.h
@@ -1683,7 +1683,23 @@ public:
m_op (op),
m_a (a),
m_b (b)
- {}
+ {
+type *a_type = a->get_type ();
+vector_type *vec_type = a_type->dyn_cast_vector_type ();
+if (vec_type != NULL)
+{
+ type *element_type = vec_type->get_element_type ();
+ type *inner_type;
+ /* Vectors of floating-point values return a vector of integers of the
+ same size. */
+ if (element_type->is_float ())
+ inner_type = ctxt->get_int_type (element_type->get_size (), false);
+ else
+ inner_type = element_type;
+ m_type = new vector_type (inner_type, vec_type->get_num_units ());
+ ctxt->record (m_type);
+}
+ }
void replay_into (replayer *r) final override;
diff --git a/gcc/testsuite/jit.dg/harness.h b/gcc/testsuite/jit.dg/harness.h
index 7b70ce73dd5..e423abe9ee1 100644
--- a/gcc/testsuite/jit.dg/harness.h
+++ b/gcc/testsuite/jit.dg/harness.h
@@ -68,6 +68,21 @@ static char test[1024];
}\
} while (0)
+#define CHECK_VECTOR_VALUE(LEN, ACTUAL, EXPECTED) \
+ do { \
+for (int __check_vector_it = 0; __check_vector_it < LEN; ++__check_vector_it) { \
+ if ((ACTUAL)[__check_vector_it] != (EXPECTED)[__check_vector_it]) { \
+ fail ("%s: %s: actual: %s !=
Re: [PATCH] libgccjit: Fix bug where unary_op will return an integer type instead of the correct type
It fails with the following error: gcc/gcc/testsuite/jit.dg/test-asm.cc: In function 'void verify_code_2(gcc_jit_context*, gcc_jit_result*)': gcc/gcc/testsuite/jit.dg/test-asm.cc:160:11: error: ISO C++ forbids declaration of 'uint32_t' with no type [-fpermissive] gcc/gcc/testsuite/jit.dg/test-asm.cc:160:11: error: typedef 'uint32_t' is initialized (use 'decltype' instead) Are you OK with me adding the stdint.h header? On Tue, 2022-06-28 at 18:40 -0400, David Malcolm wrote: > On Wed, 2022-06-01 at 22:45 -0400, Antoni Boucher via Gcc-patches > wrote: > > Also, the test gcc/testsuite/jit.dg/test-asm.cc fails and would > > need > > this line: > > > > #include > > I'm curious; how is it failing? > > > > > Is this okay if I add it in this patch? > > > > On Wed, 2022-06-01 at 22:13 -0400, Antoni Boucher wrote: > > > Hi. > > > The attached patch fix bug 105812: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105812 > > > > > > I'm having an issue where contrib/check_GNU_style.sh doesn't seem > > > to > > > work, i.e. it doesn't seem to do any checking. > > > Is there a new way to do that or am I missing something? > > > > > > Thanks for the review. > > > >
Re: [PATCH gcc 0/1] [PATCH] target: Fix asm generation for AVX builtins when using -masm=intel [PR106095]
Thanks for the review. Does this mean I can commit it, assuming the output of compare_tests is good? By the way, I wanted to mention that it was my first time playing with the assembly generation, so I was not sure about my changes (even though it makes the test case compile, I'm not sure it doesn't have any unintended side effects): It looked to me that the register qualifiers should be the same for both AT and Intel syntaxes, but I'm might be wrong about this. On Tue, 2022-06-28 at 14:22 +0800, Hongtao Liu wrote: > On Tue, Jun 28, 2022 at 9:26 AM ~antoyo via Gcc-patches > wrote: > > > > Hi. > > > > This fixes the following bug: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106095 > The patch LGTM, thanks for handling this. > > > > It's the first time I work outside of the jit component, so please > > tell > > me if I forgot anything. > > > > Here are the results of running the test: > > > > === gcc Summary === > > > > # of expected passes 182481 > > # of unexpected failures 91 > > # of unexpected successes 20 > > # of expected failures 1475 > > # of unsupported tests 2535 > > > > === g++ Summary === > > > > # of expected passes 231596 > > # of unexpected failures 1 > > # of expected failures 2083 > > # of unsupported tests 9948 > > > > === jit Summary === > > > > # of expected passes 14542 > > # of unexpected failures 1 > > > > === libstdc++ Summary === > > > > # of expected passes 15538 > > # of expected failures 95 > > # of unsupported tests 653 > > > > === libgomp Summary === > > > > # of expected passes 5012 > > # of expected failures 33 > > # of unsupported tests 323 > > > > === libitm Summary === > > > > # of expected passes 44 > > # of expected failures 3 > > # of unsupported tests 1 > > > > === libatomic Summary === > > > > # of expected passes 54 > > > > It's the first time I run the whole testsuite, so I'm not sure if > > those > > failures are normal. I got more unexpected failures for the gcc > > tests > > than what is shown in https://gcc.gnu.org/pipermail/gcc- > > testresults/2022-June/764154.html. In any case, I get the same > > failures > > when running the testsuite on master. Perhaps my configure command > > is > > wrong? I used the following: > You can use ./contrib/compare_tests to see if there's no failure or > new pass. > ./contrib/compara_tests is under gcc top directory. > > > > ../../gcc/configure --enable-host-shared --enable- > > languages=c,jit,c++,lto --enable-checking=release > > --prefix=(pwd)/../install > > > --enable-checking=release will give up some internal checks to > increase the compilation speed, for the development trunk, it is > better not to use release. > > Thanks for the review. > > > > Antoni Boucher (1): > > target: Fix asm generation for AVX builtins when using - > > masm=intel > > [PR106095] > > > > gcc/config/i386/sse.md | 10 ++--- > > gcc/testsuite/gcc.target/i386/pr106095.c | 47 > > > > 2 files changed, 52 insertions(+), 5 deletions(-) > > create mode 100644 gcc/testsuite/gcc.target/i386/pr106095.c > > > > -- > > 2.34.2 > > >
Re: [PATCH] libgccjit: Fix bug where unary_op will return an integer type instead of the correct type
David: PING On Wed, 2022-06-01 at 22:45 -0400, Antoni Boucher wrote: > Also, the test gcc/testsuite/jit.dg/test-asm.cc fails and would need > this line: > > #include > > Is this okay if I add it in this patch? > > On Wed, 2022-06-01 at 22:13 -0400, Antoni Boucher wrote: > > Hi. > > The attached patch fix bug 105812: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105812 > > > > I'm having an issue where contrib/check_GNU_style.sh doesn't seem > > to > > work, i.e. it doesn't seem to do any checking. > > Is there a new way to do that or am I missing something? > > > > Thanks for the review. >
[PATCH] libgccjit: Support getting the size of a float
Hi.
The attached patch fix bug 105829:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105829
Thanks for the review.
From 5d75fd342cdcea94a785312252be0c0046afdf43 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Wed, 4 May 2022 21:42:44 -0400
Subject: [PATCH] libgccjit: Support getting the size of a float
2022-06-02 Antoni Boucher
gcc/jit/
PR target/105829
* libgccjit.cc: Add support for floating-point types in
gcc_jit_type_get_size.
gcc/testsuite/
PR target/105829
* jit.dg/test-types.c: Add tests for gcc_jit_type_get_size.
---
gcc/jit/libgccjit.cc | 4 ++--
gcc/testsuite/jit.dg/test-types.c | 3 +++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
index cc6486c9cad..12e7679988b 100644
--- a/gcc/jit/libgccjit.cc
+++ b/gcc/jit/libgccjit.cc
@@ -545,8 +545,8 @@ gcc_jit_type_get_size (gcc_jit_type *type)
{
RETURN_VAL_IF_FAIL (type, -1, NULL, NULL, "NULL type");
RETURN_VAL_IF_FAIL
-(type->is_int (), -1, NULL, NULL,
- "only getting the size of an integer type is supported for now");
+(type->is_int () || type->is_float (), -1, NULL, NULL,
+ "only getting the size of an int or float type is supported for now");
return type->get_size ();
}
diff --git a/gcc/testsuite/jit.dg/test-types.c b/gcc/testsuite/jit.dg/test-types.c
index 6836597d14e..53bdeafed61 100644
--- a/gcc/testsuite/jit.dg/test-types.c
+++ b/gcc/testsuite/jit.dg/test-types.c
@@ -489,4 +489,7 @@ verify_code (gcc_jit_context *ctxt, gcc_jit_result *result)
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_VALUE (gcc_jit_type_get_size (gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_FLOAT)), 4);
+ CHECK_VALUE (gcc_jit_type_get_size (gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_DOUBLE)), 8);
}
--
2.26.2.7.g19db9cfb68.dirty
Re: [PATCH] libgccjit: Fix infinite recursion in gt_ggc_mx_lang_tree_node
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.
>
> Thanks for the review.
From 609153a39921b8e9aa1934da131575bb64881d67 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Thu, 2 Jun 2022 21:14:06 -0400
Subject: [PATCH] libgccjit: Fix infinite recursion in gt_ggc_mx_lang_tree_node
2022-06-02 Antoni Boucher
gcc/jit/
PR target/105827
* dummy-frontend.cc: Fix lang_tree_node.
* jit-common.h: New function (jit_tree_chain_next) used by
lang_tree_node.
---
gcc/jit/dummy-frontend.cc | 13 +++--
gcc/jit/jit-common.h | 15 +++
2 files changed, 22 insertions(+), 6 deletions(-)
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;
};
/* We don't use language_function. */
diff --git a/gcc/jit/jit-common.h b/gcc/jit/jit-common.h
index 3ff7447fbf3..50580358a1f 100644
--- a/gcc/jit/jit-common.h
+++ b/gcc/jit/jit-common.h
@@ -93,6 +93,21 @@ const int NUM_GCC_JIT_TYPES = GCC_JIT_TYPE_INT128_T + 1;
End of comment for inclusion in the docs. */
+/* See c_tree_chain_next in gcc/c-family/c-common.h. */
+static inline tree
+jit_tree_chain_next (tree t)
+{
+ /* TREE_CHAIN of a type is TYPE_STUB_DECL, which is different
+ kind of object, never a long chain of nodes. Prefer
+ TYPE_NEXT_VARIANT for types. */
+ if (CODE_CONTAINS_STRUCT (TREE_CODE (t), TS_TYPE_COMMON))
+return TYPE_NEXT_VARIANT (t);
+ /* Otherwise, if there is TREE_CHAIN, return it. */
+ if (CODE_CONTAINS_STRUCT (TREE_CODE (t), TS_COMMON))
+return TREE_CHAIN (t);
+ return NULL;
+}
+
namespace gcc {
namespace jit {
--
2.26.2.7.g19db9cfb68.dirty
[PATCH] libgccjit: Fix infinite recursion in gt_ggc_mx_lang_tree_node
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. Thanks for the review.
Re: [PATCH] libgccjit: Fix bug where unary_op will return an integer type instead of the correct type
Also, the test gcc/testsuite/jit.dg/test-asm.cc fails and would need this line: #include Is this okay if I add it in this patch? On Wed, 2022-06-01 at 22:13 -0400, Antoni Boucher wrote: > Hi. > The attached patch fix bug 105812: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105812 > > I'm having an issue where contrib/check_GNU_style.sh doesn't seem to > work, i.e. it doesn't seem to do any checking. > Is there a new way to do that or am I missing something? > > Thanks for the review.
[PATCH] libgccjit: Fix bug where unary_op will return an integer type instead of the correct type
Hi.
The attached patch fix bug 105812:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105812
I'm having an issue where contrib/check_GNU_style.sh doesn't seem to
work, i.e. it doesn't seem to do any checking.
Is there a new way to do that or am I missing something?
Thanks for the review.
From ef20b0a18e4978aac9eb77b91898356c67f6a0e4 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Wed, 1 Jun 2022 22:07:07 -0400
Subject: [PATCH] libgccjit: Fix bug where unary_op will return an integer type
instead of the correct type
2022-06-01 Antoni Boucher
gcc/jit/
PR target/105812
* jit-playback.cc: Use the correct return when folding in
as_truth_value.
gcc/testsuite/
PR target/105812
* jit.dg/test-pr105812-bool-operations.c: New test.
---
gcc/jit/jit-playback.cc | 3 +-
.../jit.dg/test-pr105812-bool-operations.c| 89 +++
2 files changed, 91 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/jit.dg/test-pr105812-bool-operations.c
diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
index 6be6bdf8dea..c08cba58743 100644
--- a/gcc/jit/jit-playback.cc
+++ b/gcc/jit/jit-playback.cc
@@ -1025,8 +1025,9 @@ as_truth_value (tree expr, location *loc)
if (loc)
set_tree_location (typed_zero, loc);
+ tree type = TREE_TYPE (expr);
expr = fold_build2_loc (UNKNOWN_LOCATION,
-NE_EXPR, integer_type_node, expr, typed_zero);
+NE_EXPR, type, expr, typed_zero);
if (loc)
set_tree_location (expr, loc);
diff --git a/gcc/testsuite/jit.dg/test-pr105812-bool-operations.c b/gcc/testsuite/jit.dg/test-pr105812-bool-operations.c
new file mode 100644
index 000..1daa1c3c35a
--- /dev/null
+++ b/gcc/testsuite/jit.dg/test-pr105812-bool-operations.c
@@ -0,0 +1,89 @@
+#include "libgccjit.h"
+
+#include "harness.h"
+
+void
+create_code (gcc_jit_context *ctxt, void *user_data)
+{
+ gcc_jit_type* bool_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_BOOL);
+ gcc_jit_type* bool_ptr_type =
+gcc_jit_type_get_pointer (gcc_jit_type_get_aligned (bool_type, 1));
+
+ /* Function 1 */
+
+ gcc_jit_param* param1 = gcc_jit_context_new_param (ctxt, NULL, bool_type,
+ "param1");
+ gcc_jit_function* function1 =
+gcc_jit_context_new_function (ctxt, NULL,
+ GCC_JIT_FUNCTION_EXPORTED, bool_type,
+ "function1", 1, , 0);
+ gcc_jit_block* block1 = gcc_jit_function_new_block (function1, "start1");
+
+ gcc_jit_lvalue* var1 =
+gcc_jit_function_new_local (function1, NULL, bool_type, "var1");
+ gcc_jit_rvalue* addr1 =
+gcc_jit_lvalue_get_address (var1, NULL);
+ gcc_jit_rvalue* ptr1 =
+gcc_jit_context_new_cast (ctxt, NULL, addr1, bool_ptr_type);
+ gcc_jit_lvalue* deref1 =
+gcc_jit_rvalue_dereference (ptr1, NULL);
+ gcc_jit_rvalue* param1_rvalue =
+gcc_jit_param_as_rvalue (param1);
+ gcc_jit_block_add_assignment (block1, NULL, deref1, param1_rvalue);
+
+ gcc_jit_rvalue* one = gcc_jit_context_one (ctxt, bool_type);
+ gcc_jit_block_end_with_return (block1, NULL, one);
+
+ /* Function 2 */
+
+ gcc_jit_param* param2 = gcc_jit_context_new_param (ctxt, NULL, bool_type,
+ "param2");
+ gcc_jit_function* function2 =
+gcc_jit_context_new_function (ctxt, NULL,
+ GCC_JIT_FUNCTION_EXPORTED, bool_type,
+ "function2", 1, , 0);
+ gcc_jit_block* block2 = gcc_jit_function_new_block (function2, "start2");
+
+ gcc_jit_lvalue* var2 =
+gcc_jit_function_new_local (function2, NULL, bool_type, "var2");
+ gcc_jit_rvalue* addr2 =
+gcc_jit_lvalue_get_address (var2, NULL);
+ gcc_jit_rvalue* ptr2 =
+gcc_jit_context_new_cast (ctxt, NULL, addr2, bool_ptr_type);
+ gcc_jit_lvalue* deref2 =
+gcc_jit_rvalue_dereference (ptr2, NULL);
+ gcc_jit_rvalue* param2_rvalue =
+gcc_jit_param_as_rvalue (param2);
+ gcc_jit_block_add_assignment (block2, NULL, deref2, param2_rvalue);
+
+ gcc_jit_lvalue* return_value =
+gcc_jit_function_new_local (function2, NULL, bool_type, "return_value");
+ gcc_jit_rvalue* call =
+gcc_jit_context_new_call (ctxt, NULL, function1, 1, _rvalue);
+ gcc_jit_block_add_assignment (block2, NULL, return_value, call);
+
+ gcc_jit_block* block2_1 =
+gcc_jit_function_new_block (function2, "end2");
+ gcc_jit_block_end_with_jump (block2, NULL, block2_1);
+
+ gcc_jit_rvalue* value =
+gcc_jit_context_new_unary_op (ctxt, NULL,
+ GCC_JIT_UNARY_OP_LOGICAL_NEGATE, bool_type,
+ param2_rvalue);
+ gcc_jit_rvalue* return_rvalue =
+gcc_jit_lvalue_as_rvalue (return_value);
+ gcc_jit_rvalue* and =
+gcc_jit_context_new_binary_op (ctxt, NULL,
+ GCC_JIT_BINARY_OP_BITWISE_AND, bool_type,
+ return_rvalue, value);
+
+ gcc_jit_block_end_with_return (block2_1, NULL, and);
+}
+
+extern void
+verify_code (gcc_jit_context *ctxt, gcc_jit_result *result)
+{
+ /* Verify that no errors were emitted. */
+ CHECK_NON_NULL (result);
+}
--
2.26.2.7.g19db9cfb68.dirty
Re: [PATCH] libgccjit: Add support for bitcasts [PR104071]
Here's the updated patch.
On Fri, 2022-04-08 at 15:22 -0400, David Malcolm wrote:
> On Fri, 2022-01-21 at 18:41 -0500, Antoni Boucher wrote:
> > Hi.
> > Here's the updated patch.
> >
>
> Thanks. Review below:
>
> [...snip...]
>
> > diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
> > index 4c352e8c93d..6bf1e1ceee0 100644
> > --- a/gcc/jit/libgccjit.cc
> > +++ b/gcc/jit/libgccjit.cc
> > @@ -2405,6 +2405,34 @@ gcc_jit_context_new_cast (gcc_jit_context
> > *ctxt,
> > return static_cast (ctxt->new_cast (loc,
> > rvalue, type));
> > }
> >
> > +/* Public entrypoint. See description in libgccjit.h.
> > +
> > + After error-checking, the real work is done by the
> > + gcc::jit::recording::context::new_bitcast method in jit-
> > recording.c. */
> > +
> > +gcc_jit_rvalue *
> > +gcc_jit_context_new_bitcast (gcc_jit_context *ctxt,
> > + gcc_jit_location *loc,
> > + gcc_jit_rvalue *rvalue,
> > + gcc_jit_type *type)
> > +{
> > + RETURN_NULL_IF_FAIL (ctxt, NULL, loc, "NULL context");
> > + JIT_LOG_FUNC (ctxt->get_logger ());
> > + /* LOC can be NULL. */
> > + RETURN_NULL_IF_FAIL (rvalue, ctxt, loc, "NULL rvalue");
> > + RETURN_NULL_IF_FAIL (type, ctxt, loc, "NULL type");
> > + // TODO: check the sizes.
> > + /*RETURN_NULL_IF_FAIL_PRINTF3 (
> > + is_valid_cast (rvalue->get_type (), type),
> > + ctxt, loc,
> > + "cannot cast %s from type: %s to type: %s",
> > + rvalue->get_debug_string (),
> > + rvalue->get_type ()->get_debug_string (),
> > + type->get_debug_string ());*/
>
> I think we agreed that we can't check the sizes at this point, so
> this
> commented-out check would be better replaced with a comment
> explaining
> that we have to defer the check to playback time, when we have the
> trees.
>
> > +
> > + return static_cast (ctxt->new_bitcast (loc,
> > rvalue, type));
> > +}
> > +
> > /* Public entrypoint. See description in libgccjit.h.
> >
> > After error-checking, the real work is done by the
>
> [...snip...]
>
> > diff --git a/gcc/testsuite/jit.dg/test-bitcast.c
> > b/gcc/testsuite/jit.dg/test-bitcast.c
> > new file mode 100644
> > index 000..a092fa117e6
> > --- /dev/null
> > +++ b/gcc/testsuite/jit.dg/test-bitcast.c
> > @@ -0,0 +1,60 @@
> > +#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
> > +my_bitcast (double x)
> > +{
> > + return bitcast(x, int);
> > +}
> > + */
> > + gcc_jit_type *int_type =
> > + gcc_jit_context_get_int_type (ctxt, 4, 1);
> > + gcc_jit_type *float_type =
> > + gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_FLOAT);
>
> This uses GCC_JIT_TYPE_FLOAT for the param...
>
> > +
> > + gcc_jit_param *x =
> > + gcc_jit_context_new_param (
> > + ctxt,
> > + NULL,
> > + float_type, "x");
> > + gcc_jit_param *params[1] = {x};
> > + gcc_jit_function *func =
> > + gcc_jit_context_new_function (ctxt,
> > + NULL,
> > + GCC_JIT_FUNCTION_EXPORTED,
> > + int_type,
> > + "my_bitcast",
> > + 1, params, 0);
>
> [..snip...]
>
> > +
> > +void
> > +verify_code (gcc_jit_context *ctxt, gcc_jit_result *result)
> > +{
> > + typedef int (*my_bitcast_fn_type) (double);
>
> ...but this uses "double". Presumably these should agree, and have
> the
> same sizeof as the integer type.
>
> > + CHECK_NON_NULL (result);
> > + my_bitcast_fn_type my_bitcast =
> > + (my_bitcast_fn_type)gcc_jit_result_get_code (result,
> > "my_bitcast");
> > + CHECK_NON_NULL (my_bitcast);
> > + int val = my_bitcast (-5.1298714);
> > + note ("my_bitcast returned: %d", val);
> > + CHECK_VALUE (val, 35569201);
>
> Out of curiosity, is there any particular significance for these
> values? FWIW I rather like:
> http://evanw.github.io/float-toy/
> for directly manipulating the bits of floating point numbers.
The given float values, when bitcast to an int, gives the given int
value.
>
>
> [...snip...]
>
> > diff --git a/gcc/toplev.cc b/gcc/toplev.cc
> > index 534da1462e8..bc4921974eb 100644
> > --- a/gcc/toplev.cc
> > +++ b/gcc/toplev.cc
> > @@ -2368,6 +2368,7 @@ toplev::finalize (void)
> > gcse_c_finalize ();
> > ipa_cp_c_finalize ();
> > ira_costs_c_finalize ();
> > + tree_cc_finalize ();
> >
> > /* save_decoded_options uses opts_obstack, so these must
> > be cleaned up together. */
> > diff --git a/gcc/tree.cc b/gcc/tree.cc
> > index ae159ee20ce..fe9d9083026 100644
> > --- a/gcc/tree.cc
> > +++ b/gcc/tree.cc
> > @@ -6963,6 +6963,15 @@ build_reference_type (tree to_type)
> > (HOST_BITS_PER_WIDE_INT > 64 ? HOST_BITS_PER_WIDE_INT : 64)
> > static GTY(()) tree
Re: [PATCH] libgccjit: Add support for setting the alignment [PR104293]
Here's the updated patch.
On Fri, 2022-04-08 at 15:01 -0400, David Malcolm wrote:
> On Sun, 2022-01-30 at 20:38 -0500, Antoni Boucher via Gcc-patches
> wrote:
> > Hi.
> > This patch adds support for setting the alignment of variables in
> > libgccjit.
>
> Thanks. Sorry about the delay in reviewing it.
>
> >
> > I was wondering if I should change it so that it takes/returns
> > bytes
> > instead of bits.
> > What do you think?
>
> I'm not sure, but given that C refers to bytes for this:
> https://en.cppreference.com/w/c/language/object#Alignment
> https://en.cppreference.com/w/c/language/_Alignof
> ...I think bytes is the better choice, to maximize similarity with C.
Ok, I updated it to use bytes.
>
> Does anything support/need a fraction-of-a-byte alignment? If so,
> then
> bits would be the way to go.
>
>
> > diff --git a/gcc/jit/docs/topics/compatibility.rst
> > b/gcc/jit/docs/topics/compatibility.rst
> > index 16cebe31a10..1957399dceb 100644
> > --- a/gcc/jit/docs/topics/compatibility.rst
> > +++ b/gcc/jit/docs/topics/compatibility.rst
> > @@ -302,3 +302,13 @@ thread-local storage model of a variable:
> > section of a variable:
> >
> > * :func:`gcc_jit_lvalue_set_link_section`
> > +
> > +.. _LIBGCCJIT_ABI_24:
> > +
> > +``LIBGCCJIT_ABI_24``
> > +---
> > +``LIBGCCJIT_ABI_24`` covers the addition of functions to get and
> > set the
> > +alignement of a variable:
> > +
> > + * :func:`gcc_jit_lvalue_set_alignment`
> > + * :func:`gcc_jit_lvalue_get_alignment`
> > diff --git a/gcc/jit/docs/topics/expressions.rst
> > b/gcc/jit/docs/topics/expressions.rst
> > index 791a20398ca..0f5f5376d8c 100644
> > --- a/gcc/jit/docs/topics/expressions.rst
> > +++ b/gcc/jit/docs/topics/expressions.rst
> > @@ -738,6 +738,45 @@ where the rvalue is computed by reading from
> > the storage area.
> >
> > #ifdef LIBGCCJIT_HAVE_gcc_jit_lvalue_set_link_section
> >
> > +.. function:: void
> > + gcc_jit_lvalue_set_alignment (gcc_jit_lvalue
> > *lvalue,
> > + int alignment)
> > +
> > + Set the alignment of a variable.
> > + The parameter ``alignment`` is in bits. Analogous to:
> > +
> > + .. code-block:: c
> > +
> > + int variable __attribute__((aligned (16)));
> > +
> > + in C, but in bits instead of bytes.
>
> If we're doing it in bytes, this will need updating, of course.
>
> Maybe rename the int param from "alignment" to "bytes" to make this
> clearer.
>
> Probably should be unsigned as well.
>
> > +
> > + This entrypoint was added in :ref:`LIBGCCJIT_ABI_24`; you can
> > test for
> > + its presence using
> > +
> > + .. code-block:: c
> > +
> > + #ifdef LIBGCCJIT_HAVE_ALIGNMENT
> > +
> > +.. function:: int
> > + gcc_jit_lvalue_get_alignment (gcc_jit_lvalue
> > *lvalue)
> > +
> > + Return the alignment of a variable set by
> > ``gcc_jit_lvalue_set_alignment``, in bits.
> > + Return 0 if the alignment was not set. Analogous to:
> > +
> > + .. code-block:: c
> > +
> > + _Alignof (variable)
> > +
> > + in C, but in bits instead of bytes.
>
> Likewise this will need updating.
>
> > +
> > + This entrypoint was added in :ref:`LIBGCCJIT_ABI_24`; you can
> > test for
> > + its presence using
> > +
> > + .. code-block:: c
> > +
> > + #ifdef LIBGCCJIT_HAVE_ALIGNMENT
> > +
> > Global variables
> >
> >
>
> [...snip...]
>
> > diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
> > index 4c352e8c93d..e03f15ec9c8 100644
> > --- a/gcc/jit/libgccjit.cc
> > +++ b/gcc/jit/libgccjit.cc
> > @@ -2649,6 +2649,31 @@ gcc_jit_lvalue_set_link_section
> > (gcc_jit_lvalue *lvalue,
> > lvalue->set_link_section (section_name);
> > }
> >
> > +/* Public entrypoint. See description in libgccjit.h.
> > +
> > + After error-checking, the real work is done by the
> > + gcc::jit::recording::lvalue::get_link_section method in jit-
> > recording.cc. */
>
> Comment refers to wrong function.
>
> > +
> > +int
> > +gcc_jit_lvalue_get_alignment (gcc_jit_lvalue *lvalue)
> > +{
> > + RETURN_VAL_IF_FAIL (lvalue, 0, NULL, NULL, "NULL lvalue");
> > + return lvalue->get_alignment ();
> > +}
>
> Shou
Re: rustc_codegen_gcc and libgccjit for GCC 12 ?
On Fri, 2022-04-08 at 15:36 -0400, David Malcolm wrote: > I'm excited to read that rustc_codegen_gcc, the libgccjit-based > backend > for rustc can now bootstrap rustc: > https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-10 > > I've been focusing on the analyzer, and so haven't been as on top of > libgccjit patch review as I should have been. Sorry about that. > > rustc_codegen_gcc currently recommends that people build their own > libgccjit, as it contains a number of patches that aren't in gcc > trunk > yet. > > We're deep in "stage 4" of gcc 12, but libgccjit is a relatively > self- > contained part of the project, so I'm wondering if it makes sense to > try to get all/some of these patches into gcc 12. > > Antoyo: your email of: > https://gcc.gnu.org/pipermail/jit/2022q1/001475.html > said: > > [..snip...] > > > Ok, if the 4 patches currently being reviewed (and listed here: > > https://github.com/antoyo/libgccjit-patches) were included in gcc > > 12, > > I'd be able to build rustc_codegen_gcc with an unpatched gcc. > > > > It is to be noted however, that I'll need more patches for future > > work. > > Off the top of my head, I'll at least need a patch for the inline > > attribute, try/catch and target-specific builtins. > > The last 2 features will probably take some time to implement, so > > I'll > > let you judge if you think it's worth merging the 4 patches > > currently > > being reviewed for gcc 12. > > > > Are users of rustc_codegen_gcc still likely to need to build their > own > libgccjit even if we got all of the following into gcc 12? If so, > then > it's probably best to wait. > I was talking to Josh Triplett (co-load of the Rust language team) about this and the idea was that if we could have a feature-gated rustc_codegen_gcc that works with gcc 12, we could start doing the infrastructure work in rustup to start distributing rustc + libgccjit.so to users, as an early preview. So, yes if users want to experiment with the latest changes of rustc_codegen_gcc, they will have to build libgccjit from source. The benefit of having those patches in gcc 12 would mostly be to start this infrastructure work. > > Jakub/Richi (as release managers): how would you feel about me > pushing > some of these libgccjit-specific patches into trunk deep in stage 4? > I > believe the risk is low, though I should note that I'm going on > vacation on 18th through 22nd April and won't have access to my > computer that week. > > > Looking at https://github.com/antoyo/libgccjit-patches I see 5 > patches. > That said, all but the last one refer to .c source files and so > predate > the big .c to .cc migration of the gcc source tree. So it looks like > the patches in that repo may need refreshing. I updated them just now. > > More detailed status: > > [PATCH] Add support for sized integer types, including 128-bit > integers > [PR95325] > Most recent discussion is here: > https://gcc.gnu.org/pipermail/jit/2021q2/001303.html > My notes say that I'm waiting on an updated version of patch > addressing the issues in that review. Was there one? Yes, there was one and I just sent it again on the mailing list. > > > [PATCH] libgccjit: Add support for bitcasts [PR104071] > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104071 > Most recent discussion seems to be > https://gcc.gnu.org/pipermail/jit/2022q1/001475.html > I've just now posted a review of that version; LGTM with some nits, > though it adds a trivial tree_cc_finalize which I'm strictly speaking > not a maintainer of. > > > [PATCH] libgccjit: Add support for register variables [PR104072] > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104072 > Review thread: https://gcc.gnu.org/pipermail/jit/2022q1/001466.html > Latest patch seems to be: > https://gcc.gnu.org/pipermail/jit/2022q1/001510.html > My recollection is that the jit parts of the patch look OK, but > this > adds a (trivial) new reginfo_cc_finalize which would thus need > approval > from an RTL maintainer. > > > [PATCH] libgccjit: Add option to hide stderr logs [PR104073] > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104073 > Review thread: https://gcc.gnu.org/pipermail/jit/2022q1/001469.html > Latest patch: https://gcc.gnu.org/pipermail/jit/2022q1/001480.html > I approved https://gcc.gnu.org/pipermail/jit/2022q1/001483.html > This looks ready to go, assuming release managers are happy. > > > [PATCH] libgccjit: Add support for setting the alignment [PR104293] > https://gcc.gnu.org/pipermail/jit/2022q1/001494.html > I've just now posted a review of that patch; some minor changes > needed. > > So I think I'm waiting on an updated version of the sized-integer- > types > patch, and some nit-fixes for the other patches (but am disappearing > on > vacation on 18th - 22nd). I'll update the patches to address your review over the weekend. Thanks! > > > Hope the above makes sense; sorry again for not getting to these > patches
Re: [PATCH] libgccjit: Add support for sized integer types, including 128-bit integers [PR95325]
David, it seems you missed this email that contains the updated patch and a few questions. Attaching the patch again. Thanks for the reviews! On Fri, 2022-01-21 at 11:22 -0500, Antoni Boucher via Jit wrote: > David: this is the email I was talking about in my other email. > Here's the updated patch. > > By the way, I find the usage of NUM_GCC_JIT_TYPES brittle. Would it > be > better to switch to a new enum value for that instead? > > See comments below. > > Le jeudi 20 mai 2021 à 15:25 -0400, David Malcolm a écrit : > > On Tue, 2021-05-18 at 14:53 +0200, Jakub Jelinek via Jit wrote: > > > On Tue, May 18, 2021 at 08:23:56AM -0400, Antoni Boucher via Gcc- > > > patches wrote: > > > > Hello. > > > > This patch add support for sized integer types. > > > > Maybe it should check whether the size of a byte for the > > > > current > > > > platform is 8 bits and do other checks so that they're only > > > > available > > > > when it makes sense. > > > > What do you think? > > > > > > Not a review, just a comment. The 128-bit integral types are > > > available > > > only on some targets, the test e.g. the C/C++ FE do for those is > > > targetm.scalar_mode_supported_p (TImode) > > > and so even libgccjit shouldn't provide those types > > > unconditionally. > > > Similarly for the tests (though it could be guarded with e.g > > > #ifdef __SIZEOF_INT128__ > > > in that case). > > > Also, while currently all in tree targets have BITS_PER_UNIT 8 > > > and > > > therefore QImode is 8-bit, HImode 16-bit, SImode 32-bit and > > > DImode > > > 64- > > > bit, > > > in the past and maybe in he future there can be targets that > > > could > > > have > > > e.g. 16-bit or 32-bit QImode and then there wouldn't be any > > > uint8_t/int8_t > > > and int16_t would be intQImode_type_node etc. > > > uint16_type_node = make_or_reuse_type (16, 1); > > > uint32_type_node = make_or_reuse_type (32, 1); > > > uint64_type_node = make_or_reuse_type (64, 1); > > > if (targetm.scalar_mode_supported_p (TImode)) > > > uint128_type_node = make_or_reuse_type (128, 1); > > > are always with the given precisions, perhaps jit should use > > > signed_type_for (uint16_type_node) etc.? > > > > I seem to have mislaid Antoni's original email (sorry), so I'll > > reply > > to Jakub's. > > > > > 2021-05-18 Antoni Boucher > > > > > > gcc/jit/ > > > PR target/95325 > > > * jit-playback.c: Add support for the sized integer > > > types. > > > * jit-recording.c: Add support for the sized integer > > > types. > > > * libgccjit.h (GCC_JIT_TYPE_UINT8_T, > > > GCC_JIT_TYPE_UINT16_T, > > > GCC_JIT_TYPE_UINT32_T, GCC_JIT_TYPE_UINT64_T, > > > GCC_JIT_TYPE_UINT128_T, GCC_JIT_TYPE_INT8_T, > > > GCC_JIT_TYPE_INT16_T, > > > GCC_JIT_TYPE_INT32_T, GCC_JIT_TYPE_INT64_T, > > > GCC_JIT_TYPE_INT128_T): > > > New enum variants for gcc_jit_types. > > > gcc/testsuite/ > > > PR target/95325 > > > * jit.dg/test-types.c: Add tests for sized integer > > > types. > > > > First a high-level question, why not use (or extend) > > gcc_jit_context_get_int_type instead? > > If I remember correctly, I believe I had some issues with this > function, like having it return sometimes long long, and other times > long for the same size. Maybe that was an issue with a global > variable > not cleaned up. > > > > > Do we really need to extend enum gcc_jit_types? Is this a quality- > > of- > > life thing for users of the library? > > > > That said, recording::context::get_int_type is currently a bit of a > > hack, and maybe could probably be improved by using the new enum > > values > > the patch adds. > > > > IIRC, libgccjit.c does type-checking by comparing recording::type > > pointer values; does this patch gives us multiple equivalent types > > that > > ought to compare as equal? > > > > If a user gets a type via GCC_JIT_TYPE_INT and gets "another" type > > via > > GCC_JIT_TYPE_INT32_T and they happen to be the same on the current > > target, should libgccjit complain if you use "int" when you meant > > "int32_t", or accept it? >
Re: [PATCH] libgccjit: Add support for register variables [PR104072]
Here's the updated patch.
Le mardi 25 janvier 2022 à 12:13 -0500, Antoni Boucher via Jit a
écrit :
> See answers below.
>
> Le lundi 24 janvier 2022 à 18:20 -0500, David Malcolm a écrit :
> > On Sat, 2022-01-22 at 19:29 -0500, Antoni Boucher wrote:
> > > Hi.
> > >
> > > Le mardi 18 janvier 2022 à 18:49 -0500, David Malcolm a écrit :
> > > > On Mon, 2022-01-17 at 19:46 -0500, Antoni Boucher via Gcc-
> > > > patches
> > > > wrote:
> > > > > I missed the comment about the new define, so here's the
> > > > > updated
> > > > > patch.
> > > >
> > > > Thanks for the patch.
> > > > >
> > > > > Le lundi 17 janvier 2022 à 19:24 -0500, Antoni Boucher via
> > > > > Jit
> > > > > a
> > > > > écrit :
> > > > > > Hi.
> > > > > > This patch add supports for register variables in
> > > > > > libgccjit.
> > > > > >
> > > > > > It passes the JIT tests, but since I added a function in
> > > > > > reginfo.c,
> > > > > > I
> > > > > > wonder if I should run the whole testsuite.
> > > >
> > > > We're in stage 4 for gcc 12, so we should be especially careful
> > > > about
> > > > changes right now, and we're not meant to be adding new GCC 12
> > > > features.
> > > >
> > > > How close is gcc 12's libgccjit to being usable with your rustc
> > > > backend? If we're almost there, I'm willing to make our case
> > > > for
> > > > late-
> > > > breaking libgccjit changes to the release managers, but if you
> > > > think
> > > > rustc users are going to need to build a patched libgccjit,
> > > > then
> > > > let's
> > > > queue this up for gcc 13.
> > >
> > > As I mentioned in my other email, if the 4 patches currently
> > > being
> > > reviewed (and listed here:
> > > https://github.com/antoyo/libgccjit-patches) were included in gcc
> > > 12,
> > > I'd be able to build rustc_codegen_gcc with an unpatched gcc.
> >
> > Thanks. Once the relevant patches look good to me, I'll approach
> > the
> > release managers with the proposal.
> >
> > >
> > > It is to be noted however, that I'll need more patches for future
> > > work.
> > > Off the top of my head, I'll at least need a patch for the inline
> > > attribute, try/catch and target-specific builtins.
> > > The last 2 features will probably take some time to implement, so
> > > I'll
> > > let you judge if you think it's worth merging the 4 patches
> > > currently
> > > being reviewed for gcc 12.
> >
> > Thanks, though I don't know enough about your project's features to
> > make the judgement call. Does rustc_codegen_gcc have releases yet,
> > or
> > are you just pointing people at the trunk of your repo? I guess
> > the
> > question is - are you hoping to be able to point people at distro
> > installs of gcc 12's libgccjit and have some version of
> > rustc_codegen_gcc "just work" with that, or are they going to have
> > to
> > rebuild their own libgccjit to meaningfully use it?
>
> rustc_codegen_gcc does not have releases. It is merged from time to
> time into rustc, so we can as well say that I point them to trunk.
>
> I can feature gate the future features/patches I will need so that
> people can still use the project with an unpatched gcc.
>
> There's some interest in having it work with an unpatched gcc because
> that would allow people to start working on the infra to get the
> project distributed via rustup so that it could be distributed as a
> preview component.
>
> >
> > [...snip various corrections...]
> >
> > >
> > > > > diff --git a/gcc/testsuite/jit.dg/test-register-variable.c
> > > > > b/gcc/testsuite/jit.dg/test-register-variable.c
> > > > > new file mode 100644
> > > > > index 000..3cea3f1668f
> > > > > --- /dev/null
> > > > > +++ b/gcc/testsuite/jit.dg/test-register-variable.c
> > > > > +
> >
> > [...snip...]
> >
> > > > > +/* { dg-final { jit-verify-output-file-was-created "" } } */
> > > > > +/* { dg-final { jit-verify-assembler-output
> > > > > "movl \\\$1,
> > > > > %r12d
[PATCH] libgccjit: Add support for setting the alignment [PR104293]
Hi.
This patch adds support for setting the alignment of variables in
libgccjit.
I was wondering if I should change it so that it takes/returns bytes
instead of bits.
What do you think?
Thanks for the review.
From ebdb6905f23ddef28292a1d71081eebb7a2a9bb9 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Tue, 25 Jan 2022 21:12:32 -0500
Subject: [PATCH] libgccjit: Add support for setting the alignment [PR104293]
2022-01-30 Antoni Boucher
gcc/jit/
PR jit/104293
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_24): New ABI tag.
* docs/topics/expressions.rst: Add documentation for the
functions gcc_jit_lvalue_set_alignment and
gcc_jit_lvalue_get_alignment.
* jit-playback.h: New function (set_alignment).
* jit-recording.cc: New function (set_alignment).
* jit-recording.h: New functions (set_alignment, get_alignment)
and new field (m_alignment).
* libgccjit.cc: New functions (gcc_jit_lvalue_get_alignment,
gcc_jit_lvalue_set_alignment)
* libgccjit.h: New functions (gcc_jit_lvalue_get_alignment,
gcc_jit_lvalue_set_alignment)
* libgccjit.map (LIBGCCJIT_ABI_24): New ABI tag.
gcc/testsuite/
PR jit/104293
* jit.dg/all-non-failing-tests.h: Mention
test-setting-alignment.
* jit.dg/test-setting-alignment.c: New test.
---
gcc/jit/docs/topics/compatibility.rst | 10 +++
gcc/jit/docs/topics/expressions.rst | 39 +++
gcc/jit/jit-playback.h| 7 ++
gcc/jit/jit-recording.cc | 17 -
gcc/jit/jit-recording.h | 6 +-
gcc/jit/libgccjit.cc | 25
gcc/jit/libgccjit.h | 19 ++
gcc/jit/libgccjit.map | 18 ++
gcc/testsuite/jit.dg/all-non-failing-tests.h | 3 +
gcc/testsuite/jit.dg/test-setting-alignment.c | 64 +++
10 files changed, 205 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-setting-alignment.c
diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst
index 16cebe31a10..1957399dceb 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -302,3 +302,13 @@ thread-local storage model of a variable:
section of a variable:
* :func:`gcc_jit_lvalue_set_link_section`
+
+.. _LIBGCCJIT_ABI_24:
+
+``LIBGCCJIT_ABI_24``
+---
+``LIBGCCJIT_ABI_24`` covers the addition of functions to get and set the
+alignement of a variable:
+
+ * :func:`gcc_jit_lvalue_set_alignment`
+ * :func:`gcc_jit_lvalue_get_alignment`
diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst
index 791a20398ca..0f5f5376d8c 100644
--- a/gcc/jit/docs/topics/expressions.rst
+++ b/gcc/jit/docs/topics/expressions.rst
@@ -738,6 +738,45 @@ where the rvalue is computed by reading from the storage area.
#ifdef LIBGCCJIT_HAVE_gcc_jit_lvalue_set_link_section
+.. function:: void
+ gcc_jit_lvalue_set_alignment (gcc_jit_lvalue *lvalue,
+int alignment)
+
+ Set the alignment of a variable.
+ The parameter ``alignment`` is in bits. Analogous to:
+
+ .. code-block:: c
+
+ int variable __attribute__((aligned (16)));
+
+ in C, but in bits instead of bytes.
+
+ This entrypoint was added in :ref:`LIBGCCJIT_ABI_24`; you can test for
+ its presence using
+
+ .. code-block:: c
+
+ #ifdef LIBGCCJIT_HAVE_ALIGNMENT
+
+.. function:: int
+ gcc_jit_lvalue_get_alignment (gcc_jit_lvalue *lvalue)
+
+ Return the alignment of a variable set by ``gcc_jit_lvalue_set_alignment``, in bits.
+ Return 0 if the alignment was not set. Analogous to:
+
+ .. code-block:: c
+
+ _Alignof (variable)
+
+ in C, but in bits instead of bytes.
+
+ This entrypoint was added in :ref:`LIBGCCJIT_ABI_24`; you can test for
+ its presence using
+
+ .. code-block:: c
+
+ #ifdef LIBGCCJIT_HAVE_ALIGNMENT
+
Global variables
diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
index c93d7055d43..4a3c4a6a09b 100644
--- a/gcc/jit/jit-playback.h
+++ b/gcc/jit/jit-playback.h
@@ -701,6 +701,13 @@ public:
set_decl_section_name (as_tree (), name);
}
+ void
+ set_alignment (int alignment)
+ {
+ SET_DECL_ALIGN (as_tree (), alignment);
+ DECL_USER_ALIGN (as_tree ()) = 1;
+ }
+
private:
bool mark_addressable (location *loc);
};
diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc
index 1e3fadfacd7..7176fb34734 100644
--- a/gcc/jit/jit-recording.cc
+++ b/gcc/jit/jit-recording.cc
@@ -3807,6 +3807,11 @@ void recording::lvalue::set_link_section (const char *name)
m_link_section = new_string (name);
}
+void recording::lvalue::set_alignment (int alignment)
+{
+ m_alignment = alignment;
+}
+
/* The implementation of class gcc::jit::recording::param. */
/* Implementation of pure virtual hook recording::memento::replay_into
@@ -4673,6 +4678,9 @@
Re: [PATCH] libgccjit: Add support for register variables [PR104072]
See answers below.
Le lundi 24 janvier 2022 à 18:20 -0500, David Malcolm a écrit :
> On Sat, 2022-01-22 at 19:29 -0500, Antoni Boucher wrote:
> > Hi.
> >
> > Le mardi 18 janvier 2022 à 18:49 -0500, David Malcolm a écrit :
> > > On Mon, 2022-01-17 at 19:46 -0500, Antoni Boucher via Gcc-patches
> > > wrote:
> > > > I missed the comment about the new define, so here's the
> > > > updated
> > > > patch.
> > >
> > > Thanks for the patch.
> > > >
> > > > Le lundi 17 janvier 2022 à 19:24 -0500, Antoni Boucher via Jit
> > > > a
> > > > écrit :
> > > > > Hi.
> > > > > This patch add supports for register variables in libgccjit.
> > > > >
> > > > > It passes the JIT tests, but since I added a function in
> > > > > reginfo.c,
> > > > > I
> > > > > wonder if I should run the whole testsuite.
> > >
> > > We're in stage 4 for gcc 12, so we should be especially careful
> > > about
> > > changes right now, and we're not meant to be adding new GCC 12
> > > features.
> > >
> > > How close is gcc 12's libgccjit to being usable with your rustc
> > > backend? If we're almost there, I'm willing to make our case for
> > > late-
> > > breaking libgccjit changes to the release managers, but if you
> > > think
> > > rustc users are going to need to build a patched libgccjit, then
> > > let's
> > > queue this up for gcc 13.
> >
> > As I mentioned in my other email, if the 4 patches currently being
> > reviewed (and listed here:
> > https://github.com/antoyo/libgccjit-patches) were included in gcc
> > 12,
> > I'd be able to build rustc_codegen_gcc with an unpatched gcc.
>
> Thanks. Once the relevant patches look good to me, I'll approach the
> release managers with the proposal.
>
> >
> > It is to be noted however, that I'll need more patches for future
> > work.
> > Off the top of my head, I'll at least need a patch for the inline
> > attribute, try/catch and target-specific builtins.
> > The last 2 features will probably take some time to implement, so
> > I'll
> > let you judge if you think it's worth merging the 4 patches
> > currently
> > being reviewed for gcc 12.
>
> Thanks, though I don't know enough about your project's features to
> make the judgement call. Does rustc_codegen_gcc have releases yet,
> or
> are you just pointing people at the trunk of your repo? I guess the
> question is - are you hoping to be able to point people at distro
> installs of gcc 12's libgccjit and have some version of
> rustc_codegen_gcc "just work" with that, or are they going to have to
> rebuild their own libgccjit to meaningfully use it?
rustc_codegen_gcc does not have releases. It is merged from time to
time into rustc, so we can as well say that I point them to trunk.
I can feature gate the future features/patches I will need so that
people can still use the project with an unpatched gcc.
There's some interest in having it work with an unpatched gcc because
that would allow people to start working on the infra to get the
project distributed via rustup so that it could be distributed as a
preview component.
>
> [...snip various corrections...]
>
> >
> > > > diff --git a/gcc/testsuite/jit.dg/test-register-variable.c
> > > > b/gcc/testsuite/jit.dg/test-register-variable.c
> > > > new file mode 100644
> > > > index 000..3cea3f1668f
> > > > --- /dev/null
> > > > +++ b/gcc/testsuite/jit.dg/test-register-variable.c
> > > > +
>
> [...snip...]
>
> > > > +/* { dg-final { jit-verify-output-file-was-created "" } } */
> > > > +/* { dg-final { jit-verify-assembler-output "movl \\\$1,
> > > > %r12d" } } */
> > > > +/* { dg-final { jit-verify-assembler-output "movl \\\$2,
> > > > %r13d" } } */
> > >
> > > How target-specific is this test?
> >
> > It will only work on x86-64. Should I feature-gate the test
> > somehow?
>
>
> Yes; I think you can do this by adding this to the top of the test:
>
> /* { dg-do compile { target x86_64-*-* } } */
>
> like test-asm.c does.
Thanks. I'll update the patch to do this.
>
> > >
> > > We should have test coverage for at least these two errors:
> > >
> > > - gcc_jit_lvalue_set_register_name(global_variable,
> > > "this_is_not_a_register");
> > > - attempting to set the name for a var that doesn't fit in the
> > > given
> > > register (e.g. trying to use a register for an array that's way
> > > too
> > > big)
> >
> > Done.
>
> Thanks.
>
> Is the updated patch available for review? It looks like you didn't
> attach it.
>
> Dave
>
Re: [PATCH] libgccjit: Add support for register variables [PR104072]
Indeed, I forgot to attach the patch.
Le lundi 24 janvier 2022 à 18:20 -0500, David Malcolm a écrit :
> On Sat, 2022-01-22 at 19:29 -0500, Antoni Boucher wrote:
> > Hi.
> >
> > Le mardi 18 janvier 2022 à 18:49 -0500, David Malcolm a écrit :
> > > On Mon, 2022-01-17 at 19:46 -0500, Antoni Boucher via Gcc-patches
> > > wrote:
> > > > I missed the comment about the new define, so here's the
> > > > updated
> > > > patch.
> > >
> > > Thanks for the patch.
> > > >
> > > > Le lundi 17 janvier 2022 à 19:24 -0500, Antoni Boucher via Jit
> > > > a
> > > > écrit :
> > > > > Hi.
> > > > > This patch add supports for register variables in libgccjit.
> > > > >
> > > > > It passes the JIT tests, but since I added a function in
> > > > > reginfo.c,
> > > > > I
> > > > > wonder if I should run the whole testsuite.
> > >
> > > We're in stage 4 for gcc 12, so we should be especially careful
> > > about
> > > changes right now, and we're not meant to be adding new GCC 12
> > > features.
> > >
> > > How close is gcc 12's libgccjit to being usable with your rustc
> > > backend? If we're almost there, I'm willing to make our case for
> > > late-
> > > breaking libgccjit changes to the release managers, but if you
> > > think
> > > rustc users are going to need to build a patched libgccjit, then
> > > let's
> > > queue this up for gcc 13.
> >
> > As I mentioned in my other email, if the 4 patches currently being
> > reviewed (and listed here:
> > https://github.com/antoyo/libgccjit-patches) were included in gcc
> > 12,
> > I'd be able to build rustc_codegen_gcc with an unpatched gcc.
>
> Thanks. Once the relevant patches look good to me, I'll approach the
> release managers with the proposal.
>
> >
> > It is to be noted however, that I'll need more patches for future
> > work.
> > Off the top of my head, I'll at least need a patch for the inline
> > attribute, try/catch and target-specific builtins.
> > The last 2 features will probably take some time to implement, so
> > I'll
> > let you judge if you think it's worth merging the 4 patches
> > currently
> > being reviewed for gcc 12.
>
> Thanks, though I don't know enough about your project's features to
> make the judgement call. Does rustc_codegen_gcc have releases yet,
> or
> are you just pointing people at the trunk of your repo? I guess the
> question is - are you hoping to be able to point people at distro
> installs of gcc 12's libgccjit and have some version of
> rustc_codegen_gcc "just work" with that, or are they going to have to
> rebuild their own libgccjit to meaningfully use it?
>
> [...snip various corrections...]
>
> >
> > > > diff --git a/gcc/testsuite/jit.dg/test-register-variable.c
> > > > b/gcc/testsuite/jit.dg/test-register-variable.c
> > > > new file mode 100644
> > > > index 000..3cea3f1668f
> > > > --- /dev/null
> > > > +++ b/gcc/testsuite/jit.dg/test-register-variable.c
> > > > +
>
> [...snip...]
>
> > > > +/* { dg-final { jit-verify-output-file-was-created "" } } */
> > > > +/* { dg-final { jit-verify-assembler-output "movl \\\$1,
> > > > %r12d" } } */
> > > > +/* { dg-final { jit-verify-assembler-output "movl \\\$2,
> > > > %r13d" } } */
> > >
> > > How target-specific is this test?
> >
> > It will only work on x86-64. Should I feature-gate the test
> > somehow?
>
>
> Yes; I think you can do this by adding this to the top of the test:
>
> /* { dg-do compile { target x86_64-*-* } } */
>
> like test-asm.c does.
>
> > >
> > > We should have test coverage for at least these two errors:
> > >
> > > - gcc_jit_lvalue_set_register_name(global_variable,
> > > "this_is_not_a_register");
> > > - attempting to set the name for a var that doesn't fit in the
> > > given
> > > register (e.g. trying to use a register for an array that's way
> > > too
> > > big)
> >
> > Done.
>
> Thanks.
>
> Is the updated patch available for review? It looks like you didn't
> attach it.
>
> Dave
>
From cd76593905a43ceb53cb2325f2b742ba331da2f8 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sun, 29 Aug 2021 10:54:55 -0400
Sub
Re: [PATCH] libgccjit: Add option to hide stderr logs [PR104073]
Thanks for the review.
Here's the updated patch.
Le mardi 18 janvier 2022 à 18:22 -0500, David Malcolm a écrit :
> On Mon, 2022-01-17 at 21:02 -0500, Antoni Boucher via Gcc-patches
> wrote:
> > Hi.
> > This option will be useful for rustc_codegen_gcc to hide the error
> > about unsupported 128-bit integer types.
> >
> > David, if you know of a better way to check if these types are
> > supported than creating such a type and checking if it causes an
> > error,
> > I will not need this patch.
>
> Off the top of my head I don't know of such a way.
>
> That said, this seems to be vaguely analogous to a test in a
> "configure" script, attempting a compile and seeing if it succeeds.
>
> This seems like a useful pattern for libgccjit to support, so that
> client code can query the capabilities of the host, so I think the
> idea
> of this patch is sound.
>
> As for the details of the patch, I don't like adding new members to
> the
> enums in libgccjit.h; I prefer adding new entrypoints, as the latter
> gives a way to tell if client code uses the new entrypoint as part of
> the ELF metadata, so that we can tell directly that client code is
> incompatible with an older libgccjit.so from the symbol metadata in
> the
> built binary.
>
> So I'd prefer something like:
>
> extern void
> gcc_jit_context_set_bool_print_errors_to_stderr (gcc_jit_context
> *ctxt,
> int enabled);
>
> where gcc_jit_context_set_bool_print_errors_to_stderr defaults to
> true,
> but client code can use:
>
> gcc_jit_context_set_bool_print_errors_to_stderr (ctxt, false);
>
> Or maybe have a way to specify the FILE * for errors to be printed
> to,
> defaulting to stderr, but settable to NULL if you want to suppress
> the
> printing? That might be more flexible.
>
> Thoughts?
> Dave
>
From 1f1b7d2298956268e2678a157a34c8f9ac370f3a Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sun, 23 Jan 2022 11:37:07 -0500
Subject: [PATCH] libgccjit: Add function to hide stderr logs [PR104073]
2022-01-23 Antoni Boucher get_debug_string (),
- errmsg);
- else
-fprintf (stderr, "%s: error: %s\n",
- ctxt_progname,
- errmsg);
+ bool print_errors_to_stderr =
+ get_inner_bool_option (INNER_BOOL_OPTION_PRINT_ERRORS_TO_STDERR);
+ if (print_errors_to_stderr)
+ {
+if (loc)
+ fprintf (stderr, "%s: %s: error: %s\n",
+ ctxt_progname,
+ loc->get_debug_string (),
+ errmsg);
+else
+ fprintf (stderr, "%s: error: %s\n",
+ ctxt_progname,
+ errmsg);
+ }
if (!m_error_count)
{
@@ -1687,7 +1693,8 @@ static const char * const
static const char * const
inner_bool_option_reproducer_strings[NUM_INNER_BOOL_OPTIONS] = {
"gcc_jit_context_set_bool_allow_unreachable_blocks",
- "gcc_jit_context_set_bool_use_external_driver"
+ "gcc_jit_context_set_bool_use_external_driver",
+ "gcc_jit_context_set_bool_print_errors_to_stderr",
};
/* Write the current value of all options to the log file (if any). */
diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
index 4c352e8c93d..778f8e926a2 100644
--- a/gcc/jit/libgccjit.cc
+++ b/gcc/jit/libgccjit.cc
@@ -3431,6 +3431,23 @@ gcc_jit_context_set_bool_allow_unreachable_blocks (gcc_jit_context *ctxt,
bool_value);
}
+/* Public entrypoint. See description in libgccjit.h.
+
+ After error-checking, the real work is done by the
+ gcc::jit::recording::context::set_inner_bool_option method in
+ jit-recording.cc. */
+
+void
+gcc_jit_context_set_bool_print_errors_to_stderr (gcc_jit_context *ctxt,
+ int enabled)
+{
+ RETURN_IF_FAIL (ctxt, NULL, NULL, "NULL context");
+ JIT_LOG_FUNC (ctxt->get_logger ());
+ ctxt->set_inner_bool_option (
+gcc::jit::INNER_BOOL_OPTION_PRINT_ERRORS_TO_STDERR,
+enabled);
+}
+
/* Public entrypoint. See description in libgccjit.h.
After error-checking, the real work is done by the
diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
index 2a5ffacb1fe..16b8637dd0a 100644
--- a/gcc/jit/libgccjit.h
+++ b/gcc/jit/libgccjit.h
@@ -293,6 +293,24 @@ gcc_jit_context_set_bool_allow_unreachable_blocks (gcc_jit_context *ctxt,
tested for with #ifdef. */
#define LIBGCCJIT_HAVE_gcc_jit_context_set_bool_allow_unreachable_blocks
+/* By default, libgccjit will print errors to stderr.
+
+ This option can be used to disable the printing.
+
+ This entrypoint was added in LIBGCCJIT_ABI_23; you can test for
+ its presence using
+ #ifdef LIBGCCJIT_HAVE_gcc_jit_context_set_bool_print_errors_to_stderr
+*/
+
+extern void
+gcc_jit_context_set_bool_print_errors_to_stderr (gcc_jit_context *ctxt,
+ int enabled);
+
+/* Pre-canned feature macro to i
Re: [PATCH] libgccjit: Add support for register variables [PR104072]
Hi.
Le mardi 18 janvier 2022 à 18:49 -0500, David Malcolm a écrit :
> On Mon, 2022-01-17 at 19:46 -0500, Antoni Boucher via Gcc-patches
> wrote:
> > I missed the comment about the new define, so here's the updated
> > patch.
>
> Thanks for the patch.
> >
> > Le lundi 17 janvier 2022 à 19:24 -0500, Antoni Boucher via Jit a
> > écrit :
> > > Hi.
> > > This patch add supports for register variables in libgccjit.
> > >
> > > It passes the JIT tests, but since I added a function in
> > > reginfo.c,
> > > I
> > > wonder if I should run the whole testsuite.
>
> We're in stage 4 for gcc 12, so we should be especially careful about
> changes right now, and we're not meant to be adding new GCC 12
> features.
>
> How close is gcc 12's libgccjit to being usable with your rustc
> backend? If we're almost there, I'm willing to make our case for
> late-
> breaking libgccjit changes to the release managers, but if you think
> rustc users are going to need to build a patched libgccjit, then
> let's
> queue this up for gcc 13.
As I mentioned in my other email, if the 4 patches currently being
reviewed (and listed here:
https://github.com/antoyo/libgccjit-patches) were included in gcc 12,
I'd be able to build rustc_codegen_gcc with an unpatched gcc.
It is to be noted however, that I'll need more patches for future work.
Off the top of my head, I'll at least need a patch for the inline
attribute, try/catch and target-specific builtins.
The last 2 features will probably take some time to implement, so I'll
let you judge if you think it's worth merging the 4 patches currently
being reviewed for gcc 12.
>
> > 2022-01-17 Antoni Boucher
> >
> > gcc/jit/
> > PR target/104072
>
> This should be "jit", rather than "target".
>
> This will need updaing for the various .c to .cc renamings on trunk
> yesterday.
Done.
>
> [...snip...]
>
> > diff --git a/gcc/jit/dummy-frontend.c b/gcc/jit/dummy-frontend.c
> > index 84ff359bfe3..04d8fc6ab48 100644
> > --- a/gcc/jit/dummy-frontend.c
> > +++ b/gcc/jit/dummy-frontend.c
> > @@ -599,6 +599,8 @@ jit_langhook_init (void)
> >
> > build_common_builtin_nodes ();
> >
> > + clear_global_regs_cache ();
> > +
>
> Similarly to my comments on the bitcasts patch, call this from a
> reginfo_cc_finalize function called from toplev::finalize instead.
Done.
>
> > diff --git a/gcc/jit/libgccjit.c b/gcc/jit/libgccjit.c
> > index 03704ef10b8..1757ad583fe 100644
> > --- a/gcc/jit/libgccjit.c
> > +++ b/gcc/jit/libgccjit.c
> > @@ -2649,6 +2649,18 @@ gcc_jit_lvalue_set_link_section
> > (gcc_jit_lvalue *lvalue,
> > lvalue->set_link_section (section_name);
> > }
> >
> > +/* Public entrypoint. See description in libgccjit.h.
> > +
> > + After error-checking, the real work is done by the
> > + gcc::jit::recording::lvalue::set_register_name method in jit-
> > recording.c. */
> > +
> > +void
> > +gcc_jit_lvalue_set_register_name (gcc_jit_lvalue *lvalue,
> > + const char *reg_name)
> > +{
>
> Need error checking here, to gracefully reject NULL value, and NULL
> reg_name.
Done.
>
> > + lvalue->set_register_name (reg_name);
> > +}
> > +
>
> > diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
> > index c93d7055d43..af4427c4503 100644
> > --- a/gcc/jit/jit-playback.h
> > +++ b/gcc/jit/jit-playback.h
> > @@ -24,6 +24,7 @@ along with GCC; see the file COPYING3. If not
> > see
> > #include // for std::pair
> >
> > #include "timevar.h"
> > +#include "varasm.h"
> >
> > #include "jit-recording.h"
> >
> > @@ -701,6 +702,14 @@ public:
> > set_decl_section_name (as_tree (), name);
> > }
> >
> > + void
> > + set_register_name (const char* reg_name)
> > + {
> > + set_user_assembler_name (as_tree (), reg_name);
> > + DECL_REGISTER (as_tree ()) = 1;
> > + DECL_HARD_REGISTER (as_tree ()) = 1;
> > + }
>
> I'm not familiar enough with the backend to know if this is correct,
> sorry.
>
> Is there an analogous thing in the C frontend that this corresponds
> to?
Not really as this is doing multiple things in one shot, while in the C
frontend, the register keyword will do one thing, specifying the
register name is another, …
>
> [...snip...]
>
> > diff --git a/gcc/reginfo.c b/gcc/reginfo.c
> > index 234f72eceeb..4fe375c4463 100644
> > --- a/gcc/reginfo.c
&g
Re: [PATCH] libgccjit: Add support for bitcasts [PR104071]
Hi. Here's the updated patch. See comments below. Le mardi 18 janvier 2022 à 18:06 -0500, David Malcolm a écrit : > On Mon, 2022-01-17 at 19:30 -0500, Antoni Boucher via Gcc-patches > wrote: > > I was missing the define, so I added it. > > Here's the new patch with it. > > Thanks for the patch. > > > Le lundi 17 janvier 2022 à 17:18 -0500, Antoni Boucher via Jit a > > écrit : > > > Hi. > > > This patch add support for bitcasts in libgccjit. > > > > > > It passes the JIT tests, but since I added a function in tree.c, > > > I > > > wonder if I should run the whole testsuite. > > We're in stage 4 for GCC 12 now, so we need to be especially careful > and conservative about every change. A strict reading on the rules > is > that we shouldn't be adding new features - but if they're confined to > libgccjit we may be able to get release manager approval. Ok, if the 4 patches currently being reviewed (and listed here: https://github.com/antoyo/libgccjit-patches) were included in gcc 12, I'd be able to build rustc_codegen_gcc with an unpatched gcc. It is to be noted however, that I'll need more patches for future work. Off the top of my head, I'll at least need a patch for the inline attribute, try/catch and target-specific builtins. The last 2 features will probably take some time to implement, so I'll let you judge if you think it's worth merging the 4 patches currently being reviewed for gcc 12. > > > > > > > David, you can now disregard my question in my email about 128- > > > bit > > > integers regarding my issue with initialize_sizetypes being > > > called > > > multiple times because this patch fix this issue. > > > I turns out there was a cache of types that needed to be cleared > > > when > > > you initialize the JIT. > > > > > > The check for sizes is pending, because it requires the updates > > > to > > > get_size I made in my patch for 128-bit integers. > > Sorry, I seem to have mislaid that patch; do you have the "Subject" > line handy? I recently sent an email with that patch updated, but here's the subject line: [PATCH] libgccjit: Add support for sized integer types, including 128- bit integers [PR95325] > > Do you have a list of the patches I need to review? Yes, on this repo: https://github.com/antoyo/libgccjit-patches They are outdated but I can update them if you want. > > As for this patch, overall I like it, but there are various nits... > > > > > > > Thanks for the review! > > > 2022-01-17 Antoni Boucher > > > > gcc/jit/ > > PR target/104071 > > Should be "jit" rather than "target". > > Various source files are now .cc rather than .c after yesterday's big > renaming. > > > * docs/topics/compatibility.rst (LIBGCCJIT_ABI_20): New ABI > > tag. > > * docs/topics/expressions.rst: Add documentation for the > > function gcc_jit_context_new_bitcast. > > * dummy-frontend.c: clear the cache of non-standard integer > > types to avoid having issues with some optimizations of > > bitcast where the SSA_NAME will have a size of a cached > > integer type that should have been invalidated, causing a > > comparison of integer constant to fail. > > * jit-playback.c: New function (new_bitcast). > > * jit-playback.h: New function (new_bitcast). > > * jit-recording.c: New functions (new_bitcast, > > bitcast::replay_into, bitcast::visit_children, > > bitcast::make_debug_string, bitcast::write_reproducer). > > * jit-recording.h: New calss (bitcast) and new function > > (new_bitcast, bitcast::replay_into, > > bitcast::visit_children, > > bitcast::make_debug_string, bitcast::write_reproducer, > > bitcast::get_precedence). > > * libgccjit.c: New function (gcc_jit_context_new_bitcast) > > * libgccjit.h: New function (gcc_jit_context_new_bitcast) > > * libgccjit.map (LIBGCCJIT_ABI_20): New ABI tag. > > > > gcc/testsuite/ > > PR target/104071 > > * jit.dg/all-non-failing-tests.h: Add new test-bitcast. > > * jit.dg/test-bitcast.c: New test. > > > > gcc/ > > PR target/104071 > > * tree.c: New function > > (clear_nonstandard_integer_type_cache). > > * tree.h: New function > > (clear_nonstandard_integer_type_cache). > > --- > > gcc/jit/docs/topics/compatibility.rst | 9 +++ > > gcc/jit/docs/topics/expressions.
Re: [PATCH] libgccjit: Add support for sized integer types, including 128-bit integers [PR95325]
David: this is the email I was talking about in my other email. Here's the updated patch. By the way, I find the usage of NUM_GCC_JIT_TYPES brittle. Would it be better to switch to a new enum value for that instead? See comments below. Le jeudi 20 mai 2021 à 15:25 -0400, David Malcolm a écrit : > On Tue, 2021-05-18 at 14:53 +0200, Jakub Jelinek via Jit wrote: > > On Tue, May 18, 2021 at 08:23:56AM -0400, Antoni Boucher via Gcc- > > patches wrote: > > > Hello. > > > This patch add support for sized integer types. > > > Maybe it should check whether the size of a byte for the current > > > platform is 8 bits and do other checks so that they're only > > > available > > > when it makes sense. > > > What do you think? > > > > Not a review, just a comment. The 128-bit integral types are > > available > > only on some targets, the test e.g. the C/C++ FE do for those is > > targetm.scalar_mode_supported_p (TImode) > > and so even libgccjit shouldn't provide those types > > unconditionally. > > Similarly for the tests (though it could be guarded with e.g > > #ifdef __SIZEOF_INT128__ > > in that case). > > Also, while currently all in tree targets have BITS_PER_UNIT 8 and > > therefore QImode is 8-bit, HImode 16-bit, SImode 32-bit and DImode > > 64- > > bit, > > in the past and maybe in he future there can be targets that could > > have > > e.g. 16-bit or 32-bit QImode and then there wouldn't be any > > uint8_t/int8_t > > and int16_t would be intQImode_type_node etc. > > uint16_type_node = make_or_reuse_type (16, 1); > > uint32_type_node = make_or_reuse_type (32, 1); > > uint64_type_node = make_or_reuse_type (64, 1); > > if (targetm.scalar_mode_supported_p (TImode)) > > uint128_type_node = make_or_reuse_type (128, 1); > > are always with the given precisions, perhaps jit should use > > signed_type_for (uint16_type_node) etc.? > > I seem to have mislaid Antoni's original email (sorry), so I'll reply > to Jakub's. > > > 2021-05-18 Antoni Boucher > > > > gcc/jit/ > > PR target/95325 > > * jit-playback.c: Add support for the sized integer > > types. > > * jit-recording.c: Add support for the sized integer > > types. > > * libgccjit.h (GCC_JIT_TYPE_UINT8_T, > > GCC_JIT_TYPE_UINT16_T, > > GCC_JIT_TYPE_UINT32_T, GCC_JIT_TYPE_UINT64_T, > > GCC_JIT_TYPE_UINT128_T, GCC_JIT_TYPE_INT8_T, > > GCC_JIT_TYPE_INT16_T, > > GCC_JIT_TYPE_INT32_T, GCC_JIT_TYPE_INT64_T, > > GCC_JIT_TYPE_INT128_T): > > New enum variants for gcc_jit_types. > > gcc/testsuite/ > > PR target/95325 > > * jit.dg/test-types.c: Add tests for sized integer > > types. > > First a high-level question, why not use (or extend) > gcc_jit_context_get_int_type instead? If I remember correctly, I believe I had some issues with this function, like having it return sometimes long long, and other times long for the same size. Maybe that was an issue with a global variable not cleaned up. > > Do we really need to extend enum gcc_jit_types? Is this a quality- > of- > life thing for users of the library? > > That said, recording::context::get_int_type is currently a bit of a > hack, and maybe could probably be improved by using the new enum > values > the patch adds. > > IIRC, libgccjit.c does type-checking by comparing recording::type > pointer values; does this patch gives us multiple equivalent types > that > ought to compare as equal? > > If a user gets a type via GCC_JIT_TYPE_INT and gets "another" type > via > GCC_JIT_TYPE_INT32_T and they happen to be the same on the current > target, should libgccjit complain if you use "int" when you meant > "int32_t", or accept it? I updated the function compatible_types to make them compare as equal. I believe that it's not used everywhere though, so a cast will be necessary in some cases. > > Various comments inline below... > > > diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c > > index c6136301243..40630aa1ab8 100644 > > --- a/gcc/jit/jit-playback.c > > +++ b/gcc/jit/jit-playback.c > > @@ -193,6 +193,27 @@ get_tree_node_for_type (enum gcc_jit_types > > type_) > > case GCC_JIT_TYPE_UNSIGNED_INT: > > return unsigned_type_node; > > > > + case GCC_JIT_TYPE_UINT8_T: > > + return unsigned_intQI_type_node; > > + case GCC_JIT_TYPE_UINT16_T: > > + return uint16_type_node; > > + case GC
Re: [PATCH] libgccjit: Add support for register variables [PR104072]
Also, I put the extern in gcc/system.h, but I'm not sure it's the right place. Where should I put it? Le lundi 17 janvier 2022 à 19:46 -0500, Antoni Boucher via Jit a écrit : > I missed the comment about the new define, so here's the updated > patch. > > Le lundi 17 janvier 2022 à 19:24 -0500, Antoni Boucher via Jit a > écrit : > > Hi. > > This patch add supports for register variables in libgccjit. > > > > It passes the JIT tests, but since I added a function in reginfo.c, > > I > > wonder if I should run the whole testsuite. > > > > Thanks for the review. >
[PATCH] libgccjit: Add option to hide stderr logs [PR104073]
Hi.
This option will be useful for rustc_codegen_gcc to hide the error
about unsupported 128-bit integer types.
David, if you know of a better way to check if these types are
supported than creating such a type and checking if it causes an error,
I will not need this patch.
Thanks for the reviews!
From 002c6803ac7069bf18eabd6729e31de8e2be6128 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sun, 9 Jan 2022 13:46:35 -0500
Subject: [PATCH] libgccjit: Add option to hide stderr logs [PR104073]
2022-01-17 Antoni Boucher get_debug_string (),
- errmsg);
- else
-fprintf (stderr, "%s: error: %s\n",
- ctxt_progname,
- errmsg);
+ bool hide_log_stderr =
+get_bool_option (GCC_JIT_BOOL_OPTION_HIDE_LOG_STDERR);
+
+ if (!hide_log_stderr)
+ {
+if (loc)
+ fprintf (stderr, "%s: %s: error: %s\n",
+ ctxt_progname,
+ loc->get_debug_string (),
+ errmsg);
+else
+ fprintf (stderr, "%s: error: %s\n",
+ ctxt_progname,
+ errmsg);
+ }
if (!m_error_count)
{
@@ -1682,6 +1688,7 @@ static const char * const
"GCC_JIT_BOOL_OPTION_DUMP_EVERYTHING",
"GCC_JIT_BOOL_OPTION_SELFCHECK_GC",
"GCC_JIT_BOOL_OPTION_KEEP_INTERMEDIATES"
+ "GCC_JIT_BOOL_OPTION_HIDE_LOG_STDERR"
};
static const char * const
diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
index 2a5ffacb1fe..272b862c164 100644
--- a/gcc/jit/libgccjit.h
+++ b/gcc/jit/libgccjit.h
@@ -241,6 +241,9 @@ enum gcc_jit_bool_option
their location on stderr. */
GCC_JIT_BOOL_OPTION_KEEP_INTERMEDIATES,
+ /* If true, gcc_jit_context_release will not print the errors to stderr. */
+ GCC_JIT_BOOL_OPTION_HIDE_LOG_STDERR,
+
GCC_JIT_NUM_BOOL_OPTIONS
};
--
2.26.2.7.g19db9cfb68.dirty
Re: [PATCH] libgccjit: Add support for register variables [PR104072]
I missed the comment about the new define, so here's the updated patch.
Le lundi 17 janvier 2022 à 19:24 -0500, Antoni Boucher via Jit a
écrit :
> Hi.
> This patch add supports for register variables in libgccjit.
>
> It passes the JIT tests, but since I added a function in reginfo.c, I
> wonder if I should run the whole testsuite.
>
> Thanks for the review.
From 2d372a741e9ef29eb377f9edfc6c539d1b2722e5 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sun, 29 Aug 2021 10:54:55 -0400
Subject: [PATCH] libgccjit: Add support for register variables [PR104072]
2022-01-17 Antoni Boucher
gcc/jit/
PR target/104072
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_21): New ABI tag.
* docs/topics/expressions.rst: Add documentation for the
function gcc_jit_lvalue_set_register_name.
* dummy-frontend.c: Clear the global_regs cache to avoid an
issue where compiling multiple times the same code gives an
error about assigning the same register to 2 global variables.
* jit-playback.h: New function (set_register_name).
* jit-recording.c: New function (set_register_name) and add
support for register variables.
* jit-recording.h: New field (m_reg_name) and new function
(set_register_name).
* libgccjit.c: New function (gcc_jit_lvalue_set_register_name).
* libgccjit.h: New function (gcc_jit_lvalue_set_register_name).
* libgccjit.map (LIBGCCJIT_ABI_21): New ABI tag.
gcc/
* reginfo.c: New function (clear_global_regs_cache).
* system.h: New function (clear_global_regs_cache).
gcc/testsuite/
* jit.dg/all-non-failing-tests.h: Add new
test-register-variable.
* jit.dg/test-register-variable.c: New test.
---
gcc/jit/docs/topics/compatibility.rst | 9
gcc/jit/docs/topics/expressions.rst | 20 +++
gcc/jit/dummy-frontend.c | 2 +
gcc/jit/jit-playback.h| 9
gcc/jit/jit-recording.c | 18 +--
gcc/jit/jit-recording.h | 9 ++--
gcc/jit/libgccjit.c | 12 +
gcc/jit/libgccjit.h | 12 +
gcc/jit/libgccjit.map | 9
gcc/reginfo.c | 8 +++
gcc/system.h | 2 +
gcc/testsuite/jit.dg/all-non-failing-tests.h | 3 ++
gcc/testsuite/jit.dg/test-register-variable.c | 54 +++
13 files changed, 161 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-register-variable.c
diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst
index 16cebe31a10..cd0ae4838a2 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -302,3 +302,12 @@ thread-local storage model of a variable:
section of a variable:
* :func:`gcc_jit_lvalue_set_link_section`
+
+.. _LIBGCCJIT_ABI_21:
+
+``LIBGCCJIT_ABI_21``
+---
+``LIBGCCJIT_ABI_21`` covers the addition of an API entrypoint to set the
+register name of a variable:
+
+ * :func:`gcc_jit_lvalue_set_register_name`
diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst
index 791a20398ca..afe333a520f 100644
--- a/gcc/jit/docs/topics/expressions.rst
+++ b/gcc/jit/docs/topics/expressions.rst
@@ -738,6 +738,26 @@ where the rvalue is computed by reading from the storage area.
#ifdef LIBGCCJIT_HAVE_gcc_jit_lvalue_set_link_section
+.. function:: void
+ gcc_jit_lvalue_set_register_name (gcc_jit_lvalue *lvalue,
+const char *reg_name);
+
+ Set the register name of a variable.
+ The parameter ``reg_name`` must be non-NULL. Analogous to:
+
+ .. code-block:: c
+
+ register int variable asm ("r12");
+
+ in C.
+
+ This entrypoint was added in :ref:`LIBGCCJIT_ABI_21`; you can test for
+ its presence using
+
+ .. code-block:: c
+
+ #ifdef LIBGCCJIT_HAVE_gcc_jit_lvalue_set_register_name
+
Global variables
diff --git a/gcc/jit/dummy-frontend.c b/gcc/jit/dummy-frontend.c
index 84ff359bfe3..04d8fc6ab48 100644
--- a/gcc/jit/dummy-frontend.c
+++ b/gcc/jit/dummy-frontend.c
@@ -599,6 +599,8 @@ jit_langhook_init (void)
build_common_builtin_nodes ();
+ clear_global_regs_cache ();
+
/* The default precision for floating point numbers. This is used
for floating point constants with abstract type. This may
eventually be controllable by a command line option. */
diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
index c93d7055d43..af4427c4503 100644
--- a/gcc/jit/jit-playback.h
+++ b/gcc/jit/jit-playback.h
@@ -24,6 +24,7 @@ along with GCC; see the file COPYING3. If not see
#include // for std::pair
#include "timevar.h"
+#include "varasm.h"
#include "jit-recording.h"
@@ -701,6 +702,14 @@ public:
set_decl_section_name (as_tree (), name);
}
+ void
+ set_register_name (const char* reg_name)
+ {
+
Re: [PATCH] libgccjit: Add support for bitcasts [PR104071]
I was missing the define, so I added it. Here's the new patch with it. Le lundi 17 janvier 2022 à 17:18 -0500, Antoni Boucher via Jit a écrit : > Hi. > This patch add support for bitcasts in libgccjit. > > It passes the JIT tests, but since I added a function in tree.c, I > wonder if I should run the whole testsuite. > > David, you can now disregard my question in my email about 128-bit > integers regarding my issue with initialize_sizetypes being called > multiple times because this patch fix this issue. > I turns out there was a cache of types that needed to be cleared when > you initialize the JIT. > > The check for sizes is pending, because it requires the updates to > get_size I made in my patch for 128-bit integers. > > Thanks for the review! From 8457f791b08feb0372a76d6a076cc976b59e8e24 Mon Sep 17 00:00:00 2001 From: Antoni Boucher Date: Wed, 9 Jun 2021 18:29:14 -0400 Subject: [PATCH] libgccjit: Add support for bitcasts [PR104071] 2022-01-17 Antoni Boucher gcc/jit/ PR target/104071 * docs/topics/compatibility.rst (LIBGCCJIT_ABI_20): New ABI tag. * docs/topics/expressions.rst: Add documentation for the function gcc_jit_context_new_bitcast. * dummy-frontend.c: clear the cache of non-standard integer types to avoid having issues with some optimizations of bitcast where the SSA_NAME will have a size of a cached integer type that should have been invalidated, causing a comparison of integer constant to fail. * jit-playback.c: New function (new_bitcast). * jit-playback.h: New function (new_bitcast). * jit-recording.c: New functions (new_bitcast, bitcast::replay_into, bitcast::visit_children, bitcast::make_debug_string, bitcast::write_reproducer). * jit-recording.h: New calss (bitcast) and new function (new_bitcast, bitcast::replay_into, bitcast::visit_children, bitcast::make_debug_string, bitcast::write_reproducer, bitcast::get_precedence). * libgccjit.c: New function (gcc_jit_context_new_bitcast) * libgccjit.h: New function (gcc_jit_context_new_bitcast) * libgccjit.map (LIBGCCJIT_ABI_20): New ABI tag. gcc/testsuite/ PR target/104071 * jit.dg/all-non-failing-tests.h: Add new test-bitcast. * jit.dg/test-bitcast.c: New test. gcc/ PR target/104071 * tree.c: New function (clear_nonstandard_integer_type_cache). * tree.h: New function (clear_nonstandard_integer_type_cache). --- gcc/jit/docs/topics/compatibility.rst| 9 +++ gcc/jit/docs/topics/expressions.rst | 17 + gcc/jit/dummy-frontend.c | 2 + gcc/jit/jit-playback.c | 13 gcc/jit/jit-playback.h | 5 ++ gcc/jit/jit-recording.c | 66 gcc/jit/jit-recording.h | 32 ++ gcc/jit/libgccjit.c | 28 + gcc/jit/libgccjit.h | 15 + gcc/jit/libgccjit.map| 6 ++ gcc/testsuite/jit.dg/all-non-failing-tests.h | 10 +++ gcc/testsuite/jit.dg/test-bitcast.c | 60 ++ gcc/tree.c | 8 +++ gcc/tree.h | 1 + 14 files changed, 272 insertions(+) create mode 100644 gcc/testsuite/jit.dg/test-bitcast.c diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst index 16cebe31a10..b5a6b704dda 100644 --- a/gcc/jit/docs/topics/compatibility.rst +++ b/gcc/jit/docs/topics/compatibility.rst @@ -302,3 +302,12 @@ thread-local storage model of a variable: section of a variable: * :func:`gcc_jit_lvalue_set_link_section` + +.. _LIBGCCJIT_ABI_20: + +``LIBGCCJIT_ABI_20`` +--- +``LIBGCCJIT_ABI_20`` covers the addition of an API entrypoint to bitcast a +value from one type to another: + + * :func:`gcc_jit_context_new_bitcast` diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst index 791a20398ca..1328a53f70f 100644 --- a/gcc/jit/docs/topics/expressions.rst +++ b/gcc/jit/docs/topics/expressions.rst @@ -649,6 +649,23 @@ Type-coercion * int <-> bool * P* <-> Q*, for pointer types P and Q +.. function:: gcc_jit_rvalue *\ + gcc_jit_context_new_bitcast (gcc_jit_context *ctxt,\ + gcc_jit_location *loc,\ + gcc_jit_rvalue *rvalue,\ + gcc_jit_type *type) + + Given an rvalue of T, bitcast it to another type. + + The type of rvalue must be the same size as the size of ``type``. + + This entrypoint was added in :ref:`LIBGCCJIT_ABI_20`; you can test for + its presence using + + .. code-block:: c + + #ifdef LIBGCCJIT_HAVE_gcc_jit_context_new_bitcast + Lvalues --- diff --git a/gcc/jit/dummy-frontend.c b/gcc/jit/dummy-frontend.c index 84ff359bfe3..c3da97642e3 100644 --- a/gcc/jit/dummy-frontend.c +++ b/gcc/jit/dummy-frontend.c @@ -592,6 +592,8 @@ jit_langhook_init (void)
[PATCH] libgccjit: Add support for register variables [PR104072]
Hi.
This patch add supports for register variables in libgccjit.
It passes the JIT tests, but since I added a function in reginfo.c, I
wonder if I should run the whole testsuite.
Thanks for the review.
From 328eca2be438c4a05c21942b4b2c3650ff7de0eb Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sun, 29 Aug 2021 10:54:55 -0400
Subject: [PATCH] libgccjit: Add support for register variables [PR104072]
2022-01-17 Antoni Boucher
gcc/jit/
PR target/104072
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_21): New ABI tag.
* docs/topics/expressions.rst: Add documentation for the
function gcc_jit_lvalue_set_register_name.
* dummy-frontend.c: Clear the global_regs cache to avoid an
issue where compiling multiple times the same code gives an
error about assigning the same register to 2 global variables.
* jit-playback.h: New function (set_register_name).
* jit-recording.c: New function (set_register_name) and add
support for register variables.
* jit-recording.h: New field (m_reg_name) and new function
(set_register_name).
* libgccjit.c: New function (gcc_jit_lvalue_set_register_name).
* libgccjit.h: New function (gcc_jit_lvalue_set_register_name).
* libgccjit.map (LIBGCCJIT_ABI_21): New ABI tag.
gcc/
* reginfo.c: New function (clear_global_regs_cache).
* system.h: New function (clear_global_regs_cache).
gcc/testsuite/
* jit.dg/all-non-failing-tests.h: Add new
test-register-variable.
* jit.dg/test-register-variable.c: New test.
---
gcc/jit/docs/topics/compatibility.rst | 9
gcc/jit/docs/topics/expressions.rst | 20 +++
gcc/jit/dummy-frontend.c | 2 +
gcc/jit/jit-playback.h| 9
gcc/jit/jit-recording.c | 18 +--
gcc/jit/jit-recording.h | 9 ++--
gcc/jit/libgccjit.c | 12 +
gcc/jit/libgccjit.h | 7 +++
gcc/jit/libgccjit.map | 9
gcc/reginfo.c | 8 +++
gcc/system.h | 2 +
gcc/testsuite/jit.dg/all-non-failing-tests.h | 3 ++
gcc/testsuite/jit.dg/test-register-variable.c | 54 +++
13 files changed, 156 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-register-variable.c
diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst
index 16cebe31a10..cd0ae4838a2 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -302,3 +302,12 @@ thread-local storage model of a variable:
section of a variable:
* :func:`gcc_jit_lvalue_set_link_section`
+
+.. _LIBGCCJIT_ABI_21:
+
+``LIBGCCJIT_ABI_21``
+---
+``LIBGCCJIT_ABI_21`` covers the addition of an API entrypoint to set the
+register name of a variable:
+
+ * :func:`gcc_jit_lvalue_set_register_name`
diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst
index 791a20398ca..afe333a520f 100644
--- a/gcc/jit/docs/topics/expressions.rst
+++ b/gcc/jit/docs/topics/expressions.rst
@@ -738,6 +738,26 @@ where the rvalue is computed by reading from the storage area.
#ifdef LIBGCCJIT_HAVE_gcc_jit_lvalue_set_link_section
+.. function:: void
+ gcc_jit_lvalue_set_register_name (gcc_jit_lvalue *lvalue,
+const char *reg_name);
+
+ Set the register name of a variable.
+ The parameter ``reg_name`` must be non-NULL. Analogous to:
+
+ .. code-block:: c
+
+ register int variable asm ("r12");
+
+ in C.
+
+ This entrypoint was added in :ref:`LIBGCCJIT_ABI_21`; you can test for
+ its presence using
+
+ .. code-block:: c
+
+ #ifdef LIBGCCJIT_HAVE_gcc_jit_lvalue_set_register_name
+
Global variables
diff --git a/gcc/jit/dummy-frontend.c b/gcc/jit/dummy-frontend.c
index 84ff359bfe3..04d8fc6ab48 100644
--- a/gcc/jit/dummy-frontend.c
+++ b/gcc/jit/dummy-frontend.c
@@ -599,6 +599,8 @@ jit_langhook_init (void)
build_common_builtin_nodes ();
+ clear_global_regs_cache ();
+
/* The default precision for floating point numbers. This is used
for floating point constants with abstract type. This may
eventually be controllable by a command line option. */
diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
index c93d7055d43..af4427c4503 100644
--- a/gcc/jit/jit-playback.h
+++ b/gcc/jit/jit-playback.h
@@ -24,6 +24,7 @@ along with GCC; see the file COPYING3. If not see
#include // for std::pair
#include "timevar.h"
+#include "varasm.h"
#include "jit-recording.h"
@@ -701,6 +702,14 @@ public:
set_decl_section_name (as_tree (), name);
}
+ void
+ set_register_name (const char* reg_name)
+ {
+set_user_assembler_name (as_tree (), reg_name);
+DECL_REGISTER (as_tree ()) = 1;
+DECL_HARD_REGISTER (as_tree ()) = 1;
+ }
+
private:
bool mark_addressable (location
[PATCH] libgccjit: Add support for bitcasts [PR104071]
Hi. This patch add support for bitcasts in libgccjit. It passes the JIT tests, but since I added a function in tree.c, I wonder if I should run the whole testsuite. David, you can now disregard my question in my email about 128-bit integers regarding my issue with initialize_sizetypes being called multiple times because this patch fix this issue. I turns out there was a cache of types that needed to be cleared when you initialize the JIT. The check for sizes is pending, because it requires the updates to get_size I made in my patch for 128-bit integers. Thanks for the review! From 35e113b51c416af0c13bc7eb160ff6c0cbcff813 Mon Sep 17 00:00:00 2001 From: Antoni Boucher Date: Wed, 9 Jun 2021 18:29:14 -0400 Subject: [PATCH] libgccjit: Add support for bitcasts [PR104071] 2022-01-17 Antoni Boucher gcc/jit/ PR target/104071 * docs/topics/compatibility.rst (LIBGCCJIT_ABI_20): New ABI tag. * docs/topics/expressions.rst: Add documentation for the function gcc_jit_context_new_bitcast. * dummy-frontend.c: clear the cache of non-standard integer types to avoid having issues with some optimizations of bitcast where the SSA_NAME will have a size of a cached integer type that should have been invalidated, causing a comparison of integer constant to fail. * jit-playback.c: New function (new_bitcast). * jit-playback.h: New function (new_bitcast). * jit-recording.c: New functions (new_bitcast, bitcast::replay_into, bitcast::visit_children, bitcast::make_debug_string, bitcast::write_reproducer). * jit-recording.h: New calss (bitcast) and new function (new_bitcast, bitcast::replay_into, bitcast::visit_children, bitcast::make_debug_string, bitcast::write_reproducer, bitcast::get_precedence). * libgccjit.c: New function (gcc_jit_context_new_bitcast) * libgccjit.h: New function (gcc_jit_context_new_bitcast) * libgccjit.map (LIBGCCJIT_ABI_20): New ABI tag. gcc/testsuite/ PR target/104071 * jit.dg/all-non-failing-tests.h: Add new test-bitcast. * jit.dg/test-bitcast.c: New test. gcc/ PR target/104071 * tree.c: New function (clear_nonstandard_integer_type_cache). * tree.h: New function (clear_nonstandard_integer_type_cache). --- gcc/jit/docs/topics/compatibility.rst| 9 +++ gcc/jit/docs/topics/expressions.rst | 10 +++ gcc/jit/dummy-frontend.c | 2 + gcc/jit/jit-playback.c | 13 gcc/jit/jit-playback.h | 5 ++ gcc/jit/jit-recording.c | 66 gcc/jit/jit-recording.h | 32 ++ gcc/jit/libgccjit.c | 28 + gcc/jit/libgccjit.h | 9 +++ gcc/jit/libgccjit.map| 6 ++ gcc/testsuite/jit.dg/all-non-failing-tests.h | 10 +++ gcc/testsuite/jit.dg/test-bitcast.c | 60 ++ gcc/tree.c | 8 +++ gcc/tree.h | 1 + 14 files changed, 259 insertions(+) create mode 100644 gcc/testsuite/jit.dg/test-bitcast.c diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst index 16cebe31a10..b5a6b704dda 100644 --- a/gcc/jit/docs/topics/compatibility.rst +++ b/gcc/jit/docs/topics/compatibility.rst @@ -302,3 +302,12 @@ thread-local storage model of a variable: section of a variable: * :func:`gcc_jit_lvalue_set_link_section` + +.. _LIBGCCJIT_ABI_20: + +``LIBGCCJIT_ABI_20`` +--- +``LIBGCCJIT_ABI_20`` covers the addition of an API entrypoint to bitcast a +value from one type to another: + + * :func:`gcc_jit_context_new_bitcast` diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst index 791a20398ca..6e0b5db777b 100644 --- a/gcc/jit/docs/topics/expressions.rst +++ b/gcc/jit/docs/topics/expressions.rst @@ -649,6 +649,16 @@ Type-coercion * int <-> bool * P* <-> Q*, for pointer types P and Q +.. function:: gcc_jit_rvalue *\ + gcc_jit_context_new_bitcast (gcc_jit_context *ctxt,\ + gcc_jit_location *loc,\ + gcc_jit_rvalue *rvalue,\ + gcc_jit_type *type) + + Given an rvalue of T, bitcast it to another type. + + The type of rvalue must be the same size as the size of ``type``. + Lvalues --- diff --git a/gcc/jit/dummy-frontend.c b/gcc/jit/dummy-frontend.c index 84ff359bfe3..c3da97642e3 100644 --- a/gcc/jit/dummy-frontend.c +++ b/gcc/jit/dummy-frontend.c @@ -592,6 +592,8 @@ jit_langhook_init (void) global_dc->begin_diagnostic = jit_begin_diagnostic; global_dc->end_diagnostic = jit_end_diagnostic; + clear_nonstandard_integer_type_cache (); + build_common_tree_nodes (false); /* I don't know why this has to be done explicitly. */ diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c index 1d64caf4e20..4ad2f6ce41d 100644 ---
Re: [PATCH] libgccjit: Add support for sized integer types, including 128-bit integers [PR95325]
Hi, David! One question below as I'm still not done with using this patch in rustc_codegen_gcc. Le jeudi 20 mai 2021 à 15:25 -0400, David Malcolm a écrit : > On Tue, 2021-05-18 at 14:53 +0200, Jakub Jelinek via Jit wrote: > > On Tue, May 18, 2021 at 08:23:56AM -0400, Antoni Boucher via Gcc- > > patches wrote: > > > Hello. > > > This patch add support for sized integer types. > > > Maybe it should check whether the size of a byte for the current > > > platform is 8 bits and do other checks so that they're only > > > available > > > when it makes sense. > > > What do you think? > > > > Not a review, just a comment. The 128-bit integral types are > > available > > only on some targets, the test e.g. the C/C++ FE do for those is > > targetm.scalar_mode_supported_p (TImode) > > and so even libgccjit shouldn't provide those types > > unconditionally. > > Similarly for the tests (though it could be guarded with e.g > > #ifdef __SIZEOF_INT128__ > > in that case). > > Also, while currently all in tree targets have BITS_PER_UNIT 8 and > > therefore QImode is 8-bit, HImode 16-bit, SImode 32-bit and DImode > > 64- > > bit, > > in the past and maybe in he future there can be targets that could > > have > > e.g. 16-bit or 32-bit QImode and then there wouldn't be any > > uint8_t/int8_t > > and int16_t would be intQImode_type_node etc. > > uint16_type_node = make_or_reuse_type (16, 1); > > uint32_type_node = make_or_reuse_type (32, 1); > > uint64_type_node = make_or_reuse_type (64, 1); > > if (targetm.scalar_mode_supported_p (TImode)) > > uint128_type_node = make_or_reuse_type (128, 1); > > are always with the given precisions, perhaps jit should use > > signed_type_for (uint16_type_node) etc.? > > I seem to have mislaid Antoni's original email (sorry), so I'll reply > to Jakub's. > > > 2021-05-18 Antoni Boucher > > > > gcc/jit/ > > PR target/95325 > > * jit-playback.c: Add support for the sized integer > > types. > > * jit-recording.c: Add support for the sized integer > > types. > > * libgccjit.h (GCC_JIT_TYPE_UINT8_T, > > GCC_JIT_TYPE_UINT16_T, > > GCC_JIT_TYPE_UINT32_T, GCC_JIT_TYPE_UINT64_T, > > GCC_JIT_TYPE_UINT128_T, GCC_JIT_TYPE_INT8_T, > > GCC_JIT_TYPE_INT16_T, > > GCC_JIT_TYPE_INT32_T, GCC_JIT_TYPE_INT64_T, > > GCC_JIT_TYPE_INT128_T): > > New enum variants for gcc_jit_types. > > gcc/testsuite/ > > PR target/95325 > > * jit.dg/test-types.c: Add tests for sized integer > > types. > > First a high-level question, why not use (or extend) > gcc_jit_context_get_int_type instead? > > Do we really need to extend enum gcc_jit_types? Is this a quality- > of- > life thing for users of the library? > > That said, recording::context::get_int_type is currently a bit of a > hack, and maybe could probably be improved by using the new enum > values > the patch adds. > > IIRC, libgccjit.c does type-checking by comparing recording::type > pointer values; does this patch gives us multiple equivalent types > that > ought to compare as equal? > > If a user gets a type via GCC_JIT_TYPE_INT and gets "another" type > via > GCC_JIT_TYPE_INT32_T and they happen to be the same on the current > target, should libgccjit complain if you use "int" when you meant > "int32_t", or accept it? > > Various comments inline below... > > > diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c > > index c6136301243..40630aa1ab8 100644 > > --- a/gcc/jit/jit-playback.c > > +++ b/gcc/jit/jit-playback.c > > @@ -193,6 +193,27 @@ get_tree_node_for_type (enum gcc_jit_types > > type_) > > case GCC_JIT_TYPE_UNSIGNED_INT: > > return unsigned_type_node; > > > > + case GCC_JIT_TYPE_UINT8_T: > > + return unsigned_intQI_type_node; > > + case GCC_JIT_TYPE_UINT16_T: > > + return uint16_type_node; > > + case GCC_JIT_TYPE_UINT32_T: > > + return uint32_type_node; > > + case GCC_JIT_TYPE_UINT64_T: > > + return uint64_type_node; > > + case GCC_JIT_TYPE_UINT128_T: > > + return uint128_type_node; > > + case GCC_JIT_TYPE_INT8_T: > > + return intQI_type_node; > > + case GCC_JIT_TYPE_INT16_T: > > + return intHI_type_node; > > + case GCC_JIT_TYPE_INT32_T: > > + return intSI_type_node; > > + case GCC_JIT_TYPE_INT64_T: &g
Re: SV: [commited] jit: Support for global rvalue initialization and constructors
Oh, sorry, I meant when you have an array not in a local variable, and
you try to assign to an index of this array.
Something like:
gcc_jit_rvalue *ctor = gcc_jit_context_new_array_constructor
(ctxt,0,int50arr_type,6,values);
gcc_jit_block_add_assignment (block, 0,
gcc_jit_context_new_array_access(NULL, ctor,
gcc_jit_context_zero(int_type)), some_value);
Le jeudi 30 décembre 2021 à 01:16 +, Petter Tomner a écrit :
> Could you be more specific? I tried the equivalent of:
>
> /* int [50] foobar = {1,2,3,4};
> int [50] foo() { int arr[50];
> arr = (int [50]){-1,-2,-3,-4,-5,-6};
> arr = foobar;
> arr = (int [50]){1,2,3,4,5,6};
> arr[6] = 1234;
> return arr;}
>
> N.B: Not a typo, returning an array.
> */
>
> in test-local-init-rvalue.c with a global and local "arr" and it ran
> fine. (See attachment).
>
> Regards, Petter
>
>
> Från: Antoni Boucher
> Skickat: den 29 december 2021 23:45
> Till: Petter Tomner; David Malcolm; j...@gcc.gnu.org;
> gcc-patches@gcc.gnu.org
> Ämne: Re: [commited] jit: Support for global rvalue initialization
> and constructors
>
> I realized that trying to do an assignment to an array created by the
> new array constructor API will result in a "gimplification failed"
> error:
>
> libgccjit.so: error: gimplification failed
> 0x7fa3a441e5d3 gimplify_expr(tree_node**, gimple**, gimple**, bool
> (*)(tree_node*), int)
> ../../../gcc/gcc/gimplify.c:15964
> 0x7fa3a442b1ab gimplify_modify_expr
> ../../../gcc/gcc/gimplify.c:5975
> 0x7fa3a441ac4c gimplify_expr(tree_node**, gimple**, gimple**, bool
> (*)(tree_node*), int)
> ../../../gcc/gcc/gimplify.c:14951
> 0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**)
> ../../../gcc/gcc/gimplify.c:7026
> 0x7fa3a441bca3 gimplify_statement_list
> ../../../gcc/gcc/gimplify.c:2014
> 0x7fa3a441bca3 gimplify_expr(tree_node**, gimple**, gimple**, bool
> (*)(tree_node*), int)
> ../../../gcc/gcc/gimplify.c:15396
> 0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**)
> ../../../gcc/gcc/gimplify.c:7026
> 0x7fa3a441f000 gimplify_bind_expr
> ../../../gcc/gcc/gimplify.c:1427
> 0x7fa3a441adc6 gimplify_expr(tree_node**, gimple**, gimple**, bool
> (*)(tree_node*), int)
> ../../../gcc/gcc/gimplify.c:15152
> 0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**)
> ../../../gcc/gcc/gimplify.c:7026
> 0x7fa3a4420671 gimplify_body(tree_node*, bool)
> ../../../gcc/gcc/gimplify.c:16197
> 0x7fa3a4420b3c gimplify_function_tree(tree_node*)
> ../../../gcc/gcc/gimplify.c:16351
> 0x7fa3a419fe5e gcc::jit::playback::function::postprocess()
> ../../../gcc/gcc/jit/jit-playback.c:1909
> 0x7fa3a41a13dc gcc::jit::playback::context::replay()
> ../../../gcc/gcc/jit/jit-playback.c:3250
>
>
> Should an assignment to such a value be supported?
>
> Le mercredi 15 décembre 2021 à 19:19 +, Petter Tomner a écrit :
> > Oh ye I accidentally dropped that in the merge thank you.
> >
> > I believe there is an implicit "global:" in the top of each version
> > scope, so it shouldn't
> > matter other than looking a bit deviant.
> >
> > Regards,
> > Petter
> >
> > Från: Antoni Boucher
> > Skickat: den 15 december 2021 15:19
> > Till: Petter Tomner; David Malcolm; j...@gcc.gnu.org;
> > gcc-patches@gcc.gnu.org
> > Ämne: Re: [commited] jit: Support for global rvalue initialization
> > and constructors
> >
> > Hi Petter.
> > I believe you have forgotten the line `global:` in the file
> > `gcc/jit/libgccjit.map`.
> > I'm not sure what this line does, but it is there for all other
> > ABI.
> > David: What do you think?
> > Regards.
> >
> > Le mardi 14 décembre 2021 à 17:22 +, Petter Tomner via Jit a
> > écrit :
> > > Hi!
> > >
> > > I have pushed the patch for rvalue initialization and ctors for
> > > libgccjit, for ABI 19.
> > >
> > > Please see attached patch.
> > >
> > > Regards,
> > > Petter
> > >
> >
> >
>
>
Re: [commited] jit: Support for global rvalue initialization and constructors
I realized that trying to do an assignment to an array created by the new array constructor API will result in a "gimplification failed" error: libgccjit.so: error: gimplification failed 0x7fa3a441e5d3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../../gcc/gcc/gimplify.c:15964 0x7fa3a442b1ab gimplify_modify_expr ../../../gcc/gcc/gimplify.c:5975 0x7fa3a441ac4c gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../../gcc/gcc/gimplify.c:14951 0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**) ../../../gcc/gcc/gimplify.c:7026 0x7fa3a441bca3 gimplify_statement_list ../../../gcc/gcc/gimplify.c:2014 0x7fa3a441bca3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../../gcc/gcc/gimplify.c:15396 0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**) ../../../gcc/gcc/gimplify.c:7026 0x7fa3a441f000 gimplify_bind_expr ../../../gcc/gcc/gimplify.c:1427 0x7fa3a441adc6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../../gcc/gcc/gimplify.c:15152 0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**) ../../../gcc/gcc/gimplify.c:7026 0x7fa3a4420671 gimplify_body(tree_node*, bool) ../../../gcc/gcc/gimplify.c:16197 0x7fa3a4420b3c gimplify_function_tree(tree_node*) ../../../gcc/gcc/gimplify.c:16351 0x7fa3a419fe5e gcc::jit::playback::function::postprocess() ../../../gcc/gcc/jit/jit-playback.c:1909 0x7fa3a41a13dc gcc::jit::playback::context::replay() ../../../gcc/gcc/jit/jit-playback.c:3250 Should an assignment to such a value be supported? Le mercredi 15 décembre 2021 à 19:19 +, Petter Tomner a écrit : > Oh ye I accidentally dropped that in the merge thank you. > > I believe there is an implicit "global:" in the top of each version > scope, so it shouldn't > matter other than looking a bit deviant. > > Regards, > Petter > > Från: Antoni Boucher > Skickat: den 15 december 2021 15:19 > Till: Petter Tomner; David Malcolm; j...@gcc.gnu.org; > gcc-patches@gcc.gnu.org > Ämne: Re: [commited] jit: Support for global rvalue initialization > and constructors > > Hi Petter. > I believe you have forgotten the line `global:` in the file > `gcc/jit/libgccjit.map`. > I'm not sure what this line does, but it is there for all other ABI. > David: What do you think? > Regards. > > Le mardi 14 décembre 2021 à 17:22 +, Petter Tomner via Jit a > écrit : > > Hi! > > > > I have pushed the patch for rvalue initialization and ctors for > > libgccjit, for ABI 19. > > > > Please see attached patch. > > > > Regards, > > Petter > > > >
Re: [commited] jit: Support for global rvalue initialization and constructors
Hi Petter. I believe you have forgotten the line `global:` in the file `gcc/jit/libgccjit.map`. I'm not sure what this line does, but it is there for all other ABI. David: What do you think? Regards. Le mardi 14 décembre 2021 à 17:22 +, Petter Tomner via Jit a écrit : > Hi! > > I have pushed the patch for rvalue initialization and ctors for > libgccjit, for ABI 19. > > Please see attached patch. > > Regards, > Petter >
Re: SV: [PATCH v2] jit: Add support for global rvalue initialization and ctors
Also, the LIBGCCJIT_ABI_17 will need to be updated as I merged some of my patches. Le samedi 11 décembre 2021 à 15:35 +, Petter Tomner a écrit : > Hi! > > > s/an union/a union/ > > s/a rvalue/an rvalue/ > > Heh no way ... and I though I knew English grammar :) > > Had to look that up to see what the deal was but it makes sense. > > yunion, arevalue. > > > s/wrong-field-name/wrong-field-obj/ > > > > to match the struct example (given that the issue being tested for > > is > > that it's the wrong object, rather than the wrong name). > > Initially, before submitting to the list, I made the code such that > the field > objects did not have to be the ones that were used when creating the > struct or union, and forgot changing the test names. > > I figured it required too much string compares for the field names > and > pointer compares for the field object were more appropriate. To > create > dummy field objects were also kinda heavy. > > I'll address the points. > > Regards, Petter > > > Från: David Malcolm > Skickat: den 9 december 2021 20:39 > Till: Petter Tomner; gcc-patches@gcc.gnu.org; j...@gcc.gnu.org; Antoni > Boucher > Ämne: Re: [PATCH v2] jit: Add support for global rvalue > initialization and ctors > > On Mon, 2021-12-06 at 10:47 +, Petter Tomner via Gcc-patches > wrote: > > Hi! > > > > Attached is a patch with changes in line with the review of the > > prior > > patch. > > The patch adds support for initialization of global variables with > > rvalues as well > > as rvalue constructors for structs, arrays and unions. > > Thanks for the updated patch. > > Antoni: does this patch work for you for your rustc plugin? > > > > > Review: https://gcc.gnu.org/pipermail/jit/2021q4/001400.html > > > > The points have been addressed, except: > > > > > Can the type be made const? > > > > I started to make types_kinda_same_internal () taking const args, > > but I > > felt the > > patch was ballooning because some spread out methods needed a const > > signature too. I could submit that in a separate patch. > > Fair enough; fixing that isn't a blocker; it's already a big patch. > > > > > I also addressed a problem Antoni found: > > https://gcc.gnu.org/pipermail/jit/2021q4/001399.html > > > > , where you could not initialize global pointer variables to point > > to > > uninitialized variables. I did that by > > removing a redundant check with validate_var_has_init (), since > > that > > walking function would > > have to be quite complex to allow pointers to uninitialized > > variables. > > > > Any: > > const int foo; > > int bar = foo; > > > > will instead be reported as "not compile time constant" instead of > > a > > nice error message with names. > > > > make check-jit runs fine on gnu-linux-x64 Debian. > > Various review comments inline below, which are mostly just nits: > > > From a4fef1308eaa72ce4ec51dbe5efcfbbf032e9870 Mon Sep 17 00:00:00 > > 2001 > > From: Petter Tomner > > Date: Mon, 29 Nov 2021 20:44:07 +0100 > > Subject: [PATCH] Add support for global rvalue initialization and > > constructors > > > > This patch adds support for initialization of global variables > > with rvalues and creating constructors for array, struct and > > union types which can be used as rvalues. > > > > Signed-off-by: > > 2021-12-06 Petter Tomner > > [...snip...] > > > diff --git a/gcc/jit/docs/topics/expressions.rst > > b/gcc/jit/docs/topics/expressions.rst > > index 396259ef07e..5f64ca68595 100644 > > --- a/gcc/jit/docs/topics/expressions.rst > > +++ b/gcc/jit/docs/topics/expressions.rst > > @@ -126,6 +126,147 @@ Simple expressions > > underlying string, so it is valid to pass in a pointer to an > > on-stack > > buffer. > > > > +Constructor expressions > > +*** > > + > > + The following functions make constructors for array, struct and > > union > > + types. > > + > > + The constructor rvalue can be used for assignment to locals. > > + It can be used to initialize global variables with > > + :func:`gcc_jit_global_set_initializer_rvalue`. It can also be > > used as a > > + temporary value for function calls and return values, but its > > address > > + can't be taken. > > + > > + Note that arrays in libgccjit does not collapse to pointers > > like in > > s/does not/do not/ > > > + C. I.e. if an array constructor is used as e.g. a return value, > > the whole > > + array would be returned by value - array constructors can be > > assigned to > > + array variables. > > + > > + The constructor can contain nested constructors. > > + > > + Note that a string literal rvalue can't be used to construct a > > char array. > > + It need one rvalue for each char. > > s/char array. It need one rvalue/char array; the latter needs one > rvalue/ > > > + > > + These entrypoints were added in :ref:`LIBGCCJIT_ABI_16`; you > > can test for its > > s/16/17/ I believe. > > s/its/their/ > > > > + presense using: > >
Re: SV: [PATCH v2] jit: Add support for global rvalue initialization and ctors
One thing I'm not sure if it is a code style issue, but worth mentionning: > @@ -1405,8 +1436,10 @@ private: > > private: >enum gcc_jit_global_kind m_kind; > + enum global_var_flags flags = GLOBAL_VAR_FLAGS_NONE; ^ Should it be named m_flags instead of flags? >string *m_name; >void *m_initializer; > + rvalue *m_rvalue_init = nullptr; /* Only needed for write_dump. */ >size_t m_initializer_num_bytes; > }; Le samedi 11 décembre 2021 à 15:35 +, Petter Tomner a écrit : > Hi! > > > s/an union/a union/ > > s/a rvalue/an rvalue/ > > Heh no way ... and I though I knew English grammar :) > > Had to look that up to see what the deal was but it makes sense. > > yunion, arevalue. > > > s/wrong-field-name/wrong-field-obj/ > > > > to match the struct example (given that the issue being tested for > > is > > that it's the wrong object, rather than the wrong name). > > Initially, before submitting to the list, I made the code such that > the field > objects did not have to be the ones that were used when creating the > struct or union, and forgot changing the test names. > > I figured it required too much string compares for the field names > and > pointer compares for the field object were more appropriate. To > create > dummy field objects were also kinda heavy. > > I'll address the points. > > Regards, Petter > > > Från: David Malcolm > Skickat: den 9 december 2021 20:39 > Till: Petter Tomner; gcc-patches@gcc.gnu.org; j...@gcc.gnu.org; Antoni > Boucher > Ämne: Re: [PATCH v2] jit: Add support for global rvalue > initialization and ctors > > On Mon, 2021-12-06 at 10:47 +, Petter Tomner via Gcc-patches > wrote: > > Hi! > > > > Attached is a patch with changes in line with the review of the > > prior > > patch. > > The patch adds support for initialization of global variables with > > rvalues as well > > as rvalue constructors for structs, arrays and unions. > > Thanks for the updated patch. > > Antoni: does this patch work for you for your rustc plugin? > > > > > Review: https://gcc.gnu.org/pipermail/jit/2021q4/001400.html > > > > The points have been addressed, except: > > > > > Can the type be made const? > > > > I started to make types_kinda_same_internal () taking const args, > > but I > > felt the > > patch was ballooning because some spread out methods needed a const > > signature too. I could submit that in a separate patch. > > Fair enough; fixing that isn't a blocker; it's already a big patch. > > > > > I also addressed a problem Antoni found: > > https://gcc.gnu.org/pipermail/jit/2021q4/001399.html > > > > , where you could not initialize global pointer variables to point > > to > > uninitialized variables. I did that by > > removing a redundant check with validate_var_has_init (), since > > that > > walking function would > > have to be quite complex to allow pointers to uninitialized > > variables. > > > > Any: > > const int foo; > > int bar = foo; > > > > will instead be reported as "not compile time constant" instead of > > a > > nice error message with names. > > > > make check-jit runs fine on gnu-linux-x64 Debian. > > Various review comments inline below, which are mostly just nits: > > > From a4fef1308eaa72ce4ec51dbe5efcfbbf032e9870 Mon Sep 17 00:00:00 > > 2001 > > From: Petter Tomner > > Date: Mon, 29 Nov 2021 20:44:07 +0100 > > Subject: [PATCH] Add support for global rvalue initialization and > > constructors > > > > This patch adds support for initialization of global variables > > with rvalues and creating constructors for array, struct and > > union types which can be used as rvalues. > > > > Signed-off-by: > > 2021-12-06 Petter Tomner > > [...snip...] > > > diff --git a/gcc/jit/docs/topics/expressions.rst > > b/gcc/jit/docs/topics/expressions.rst > > index 396259ef07e..5f64ca68595 100644 > > --- a/gcc/jit/docs/topics/expressions.rst > > +++ b/gcc/jit/docs/topics/expressions.rst > > @@ -126,6 +126,147 @@ Simple expressions > > underlying string, so it is valid to pass in a pointer to an > > on-stack > > buffer. > > > > +Constructor expressions > > +*** > > + > > + The following functions make constructors for array, struct and > > union > > + types. > > + > > + The constructor rvalue can be used for assignment to locals. > > + It can be used to initialize global variables with > > + :func:`gcc_jit_global_set_initializer_rvalue`. It can also be > > used as a > > + temporary value for function calls and return values, but its > > address > > + can't be taken. > > + > > + Note that arrays in libgccjit does not collapse to pointers > > like in > > s/does not/do not/ > > > + C. I.e. if an array constructor is used as e.g. a return value, > > the whole > > + array would be returned by value - array constructors can be > > assigned to > > + array variables. > > + > > + The constructor can contain nested constructors. > > + > > +
Re: SV: [PATCH v2] jit: Add support for global rvalue initialization and ctors
Yes, this patch works for rustc_codegen_gcc perfectly. It even fixes one issue that was in my patch, so that's nice! Le samedi 11 décembre 2021 à 15:35 +, Petter Tomner a écrit : > Hi! > > > s/an union/a union/ > > s/a rvalue/an rvalue/ > > Heh no way ... and I though I knew English grammar :) > > Had to look that up to see what the deal was but it makes sense. > > yunion, arevalue. > > > s/wrong-field-name/wrong-field-obj/ > > > > to match the struct example (given that the issue being tested for > > is > > that it's the wrong object, rather than the wrong name). > > Initially, before submitting to the list, I made the code such that > the field > objects did not have to be the ones that were used when creating the > struct or union, and forgot changing the test names. > > I figured it required too much string compares for the field names > and > pointer compares for the field object were more appropriate. To > create > dummy field objects were also kinda heavy. > > I'll address the points. > > Regards, Petter > > > Från: David Malcolm > Skickat: den 9 december 2021 20:39 > Till: Petter Tomner; gcc-patches@gcc.gnu.org; j...@gcc.gnu.org; Antoni > Boucher > Ämne: Re: [PATCH v2] jit: Add support for global rvalue > initialization and ctors > > On Mon, 2021-12-06 at 10:47 +, Petter Tomner via Gcc-patches > wrote: > > Hi! > > > > Attached is a patch with changes in line with the review of the > > prior > > patch. > > The patch adds support for initialization of global variables with > > rvalues as well > > as rvalue constructors for structs, arrays and unions. > > Thanks for the updated patch. > > Antoni: does this patch work for you for your rustc plugin? > > > > > Review: https://gcc.gnu.org/pipermail/jit/2021q4/001400.html > > > > The points have been addressed, except: > > > > > Can the type be made const? > > > > I started to make types_kinda_same_internal () taking const args, > > but I > > felt the > > patch was ballooning because some spread out methods needed a const > > signature too. I could submit that in a separate patch. > > Fair enough; fixing that isn't a blocker; it's already a big patch. > > > > > I also addressed a problem Antoni found: > > https://gcc.gnu.org/pipermail/jit/2021q4/001399.html > > > > , where you could not initialize global pointer variables to point > > to > > uninitialized variables. I did that by > > removing a redundant check with validate_var_has_init (), since > > that > > walking function would > > have to be quite complex to allow pointers to uninitialized > > variables. > > > > Any: > > const int foo; > > int bar = foo; > > > > will instead be reported as "not compile time constant" instead of > > a > > nice error message with names. > > > > make check-jit runs fine on gnu-linux-x64 Debian. > > Various review comments inline below, which are mostly just nits: > > > From a4fef1308eaa72ce4ec51dbe5efcfbbf032e9870 Mon Sep 17 00:00:00 > > 2001 > > From: Petter Tomner > > Date: Mon, 29 Nov 2021 20:44:07 +0100 > > Subject: [PATCH] Add support for global rvalue initialization and > > constructors > > > > This patch adds support for initialization of global variables > > with rvalues and creating constructors for array, struct and > > union types which can be used as rvalues. > > > > Signed-off-by: > > 2021-12-06 Petter Tomner > > [...snip...] > > > diff --git a/gcc/jit/docs/topics/expressions.rst > > b/gcc/jit/docs/topics/expressions.rst > > index 396259ef07e..5f64ca68595 100644 > > --- a/gcc/jit/docs/topics/expressions.rst > > +++ b/gcc/jit/docs/topics/expressions.rst > > @@ -126,6 +126,147 @@ Simple expressions > > underlying string, so it is valid to pass in a pointer to an > > on-stack > > buffer. > > > > +Constructor expressions > > +*** > > + > > + The following functions make constructors for array, struct and > > union > > + types. > > + > > + The constructor rvalue can be used for assignment to locals. > > + It can be used to initialize global variables with > > + :func:`gcc_jit_global_set_initializer_rvalue`. It can also be > > used as a > > + temporary value for function calls and return values, but its > > address > > + can't be taken. > > + > > + Note that arrays in libgccjit does not collapse to pointers > > like in > > s/does not/do not/ > > > + C. I.e. if an array constructor is used as e.g. a return value, > > the whole > > + array would be returned by value - array constructors can be > > assigned to > > + array variables. > > + > > + The constructor can contain nested constructors. > > + > > + Note that a string literal rvalue can't be used to construct a > > char array. > > + It need one rvalue for each char. > > s/char array. It need one rvalue/char array; the latter needs one > rvalue/ > > > + > > + These entrypoints were added in :ref:`LIBGCCJIT_ABI_16`; you > > can test for its > > s/16/17/ I believe. > > s/its/their/ >
Re: [PATCH] libgccjit: Add support for types used by atomic builtins [PR96066] [PR96067]
David: PING
In case you missed it, that's the last patch left to review for now.
Le dimanche 21 novembre 2021 à 16:44 -0500, Antoni Boucher a écrit :
> Thanks for the review!
> I updated the patch.
>
> See notes below.
>
> Le samedi 20 novembre 2021 à 13:50 -0500, David Malcolm a écrit :
> > On Sat, 2021-11-20 at 11:27 -0500, Antoni Boucher wrote:
> > > Hi.
> > > Here's the updated patch.
> > > Thanks for the review!
> >
> > Thanks for the updated patch...
> >
> > >
> > > Le jeudi 20 mai 2021 à 16:24 -0400, David Malcolm a écrit :
> > > > On Mon, 2021-05-17 at 21:02 -0400, Antoni Boucher via Jit
> > > > wrote:
> > > > > Hello.
> > > > > This patch fixes the issue with using atomic builtins in
> > > > > libgccjit.
> > > > > Thanks to review it.
> > > >
> > > > [...snip...]
> > > >
> > > > > diff --git a/gcc/jit/jit-recording.c b/gcc/jit/jit-
> > > > > recording.c
> > > > > index 117ff70114c..de876ff9fa6 100644
> > > > > --- a/gcc/jit/jit-recording.c
> > > > > +++ b/gcc/jit/jit-recording.c
> > > > > @@ -2598,8 +2598,18 @@
> > > > > recording::memento_of_get_pointer::accepts_writes_from (type
> > > > > *rtype)
> > > > > return false;
> > > > >
> > > > > /* It's OK to assign to a (const T *) from a (T *). */
> > > > > - return m_other_type->unqualified ()
> > > > > - ->accepts_writes_from (rtype_points_to);
> > > > > + if (m_other_type->unqualified ()
> > > > > + ->accepts_writes_from (rtype_points_to)) {
> > > > > + return true;
> > > > > + }
> > > > > +
> > > > > + /* It's OK to assign to a (volatile const T *) from a
> > > > > (volatile
> > > > > const T *). */
> > > > > + if (m_other_type->unqualified ()->unqualified ()
> > > > > + ->accepts_writes_from (rtype_points_to->unqualified ()))
> > > > > {
> > > > > + return true;
> > > > > + }
> > > >
> > > > Presumably you need this to get the atomic builtins working?
> > > >
> > > > If I'm reading the above correctly, the new test doesn't
> > > > distinguish
> > > > between the 3 different kinds of qualifiers (aligned, volatile,
> > > > and
> > > > const), it merely tries to strip some of them off.
> > > >
> > > > It's not valid to e.g. assign to a (aligned T *) from a (const
> > > > T
> > > > *).
> > > >
> > > > Maybe we need an internal enum to discriminate between
> > > > different
> > > > subclasses of decorated_type?
> >
> > I'm still concerned about this case, my reading of the updated
> > patch
> > is
> > that this case is still not quite correctly handled (see notes
> > below).
> > I don't think we currently have test coverage for assignment to
> > e.g.
> > (aligned T *) from a (const T*); I feel that it should be an error,
> > without an explicit cast.
> >
> > Please can you add a testcase for this?
>
> Done.
>
> >
> > If you want to go the extra mile, given that this is code created
> > through an API, you could have a testcase that iterates through all
> > possible combinations of qualifiers (for both source and
> > destination
> > pointer), and verifies that libgccjit at least doesn't crash on
> > them
> > (and hopefully does the right thing on each one) :/
> >
> > (perhaps doing each one in a different gcc_jit_context)
> >
> > Might be nice to update test-fuzzer.c for the new qualifiers; I
> > don't
> > think I've touched it in a long time.
>
> Done.
>
> >
> > [...snip...]
> >
> > > diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
> > > index 4a994fe7094..60aaba2a246 100644
> > > --- a/gcc/jit/jit-recording.h
> > > +++ b/gcc/jit/jit-recording.h
> > > @@ -545,6 +545,8 @@ public:
> > > virtual bool is_float () const = 0;
> > > virtual bool is_bool () const = 0;
> > > virtual type *is_pointer () = 0;
> > > + virtual type *is_volatile () { return NULL; }
> > > + virtual type *is_const () { return NULL; }
> > > virtual type *is_array () = 0;
> > > virtual struct_ *is_struct () { return NULL; }
> > > virtual bool is_void () const { return false; }
> > > @@ -687,6 +689,13 @@ public:
> > > /* Strip off the "const", giving the underlying type. */
> > > type *unqualified () FINAL OVERRIDE { return m_other_type; }
> > >
> > > + virtual bool is_same_type_as (type *other)
> > > + {
> > > + return m_other_type->is_same_type_as (other->is_const ());
> > > + }
> >
> > What happens if other_is_const () returns NULL, and
> > m_other_type->is_same_type_as ()
> > tries to call a vfunc on it...
>
> Fixed.
>
> >
> > > +
> > > + virtual type *is_const () { return m_other_type; }
> > > +
> > > void replay_into (replayer *) FINAL OVERRIDE;
> > >
> > > private:
> > > @@ -701,9 +710,16 @@ public:
> > > memento_of_get_volatile (type *other_type)
> > > : decorated_type (other_type) {}
> > >
> > > + virtual bool is_same_type_as (type *other)
> > > + {
> > > + return m_other_type->is_same_type_as (other->is_volatile
> > > ());
> > > + }
> >
> > ...with similar considerations here.
> >
> > i.e. is it possible for the user to create
Re: [PATCH] libgccjit: Add function to set the initial value of a global variable [PR96089]
Hi David! I updated the patch to allow initializing global variables with values of type array or struct. I also fixed the bug I was talking in my previous message by using the following workaround: I create a new memento for the action of setting the global variable initial value and as such, both the global variable and the initial value are bound to exist when setting the global variable initializer. Is that workaround good enough? (I guess that workaround could be used to fix the same issue that we have for inline assembly.) Thanks for the review! Le vendredi 11 juin 2021 à 16:44 -0400, Antoni Boucher a écrit : > David: this one wasn't reviewed yet by you, so you can review it. > > Le jeudi 20 mai 2021 à 21:27 -0400, Antoni Boucher a écrit : > > Hi. > > > > I made this patch to set an arbitrary value to a global variable. > > > > This patch suffers from the same issue as inline assembly > > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380), i.e. it > > segfaults if the `rvalue` is created after the global variable. > > It seems to be a design issue so I'm not sure what would be the fix > > for > > it and having it fixed would allow me to test this new function > > much > > more and see if things are missing (i.e. it might require a way to > > create a constant struct). > > See the link above for an explanation of this issue. > > > > Thanks for the review. > From a095291f43ca8348b6c84f94a598895969d94d1b Mon Sep 17 00:00:00 2001 From: Antoni Boucher Date: Sat, 25 Sep 2021 16:37:47 -0400 Subject: [PATCH] libgccjit: Add function to set the initial value of a global variable [PR96089] 2021-11-22 Antoni Boucher gcc/jit/ PR target/96089 * docs/topics/compatibility.rst (LIBGCCJIT_ABI_21): New ABI tag. * docs/topics/expressions.rst: Add documentation for the function gcc_jit_global_set_initializer_value, gcc_jit_context_new_rvalue_from_array, and gcc_jit_context_new_rvalue_from_struct. * jit-common.h: Add missing reference to array_type in class hierarchy. * jit-playback.c: New functions (new_global_with_value, set_global_initial_value, new_rvalue_from_struct, new_rvalue_from_array). * jit-playback.h: New functions (new_global_with_value, set_global_initial_value, new_rvalue_from_struct, new_rvalue_from_array). * jit-recording.c: Add support for setting a value to a global variable and new methods (global_initializer::write_reproducer, global_initializer::make_debug_string, global_initializer::write_to_dump, global_initializer::replay_into, context::new_global_value_initializer, memento_of_new_rvalue_from_struct::write_reproducer, memento_of_new_rvalue_from_struct::make_debug_string, memento_of_new_rvalue_from_struct::visit_children, memento_of_new_rvalue_from_struct::replay_into, memento_of_new_rvalue_from_struct:: memento_of_new_rvalue_from_struct, context::new_rvalue_from_struct, memento_of_new_rvalue_from_array::write_reproducer, memento_of_new_rvalue_from_array::make_debug_string, memento_of_new_rvalue_from_array::visit_children, memento_of_new_rvalue_from_array::replay_into, memento_of_new_rvalue_from_array:: memento_of_new_rvalue_from_array, new_rvalue_from_array). * jit-recording.h: New functions (set_initializer_value, new_global_value_initializer, new_rvalue_from_struct, new_rvalue_from_array, get_kind), new field m_initializer_value and new classes (global_initializer, memento_of_new_rvalue_from_struct, memento_of_new_rvalue_from_array). * libgccjit.c: New macro RETURN_IF_FAIL_PRINTF5 and new functions (gcc_jit_global_set_initializer_value, gcc_jit_context_new_rvalue_from_struct, gcc_jit_context_new_rvalue_from_array). * libgccjit.h: New functions (gcc_jit_global_set_initializer_value, gcc_jit_context_new_rvalue_from_struct, gcc_jit_context_new_rvalue_from_array). * libgccjit.map (LIBGCCJIT_ABI_21): New ABI tag. gcc/testsuite/ PR target/96089 * jit.dg/test-global-set-initializer.c: Add test for the new function (gcc_jit_global_set_initializer_value). * jit.dg/test-error-imported-global-initializer.c: Add test for error checking in setting a value to a global variable. --- gcc/jit/docs/topics/compatibility.rst | 13 + gcc/jit/docs/topics/expressions.rst | 62 gcc/jit/jit-common.h | 1 + gcc/jit/jit-playback.c| 72 + gcc/jit/jit-playback.h| 21 ++
Re: [PATCH] libgccjit: Add support for types used by atomic builtins [PR96066] [PR96067]
Thanks for the review!
I updated the patch.
See notes below.
Le samedi 20 novembre 2021 à 13:50 -0500, David Malcolm a écrit :
> On Sat, 2021-11-20 at 11:27 -0500, Antoni Boucher wrote:
> > Hi.
> > Here's the updated patch.
> > Thanks for the review!
>
> Thanks for the updated patch...
>
> >
> > Le jeudi 20 mai 2021 à 16:24 -0400, David Malcolm a écrit :
> > > On Mon, 2021-05-17 at 21:02 -0400, Antoni Boucher via Jit wrote:
> > > > Hello.
> > > > This patch fixes the issue with using atomic builtins in
> > > > libgccjit.
> > > > Thanks to review it.
> > >
> > > [...snip...]
> > >
> > > > diff --git a/gcc/jit/jit-recording.c b/gcc/jit/jit-recording.c
> > > > index 117ff70114c..de876ff9fa6 100644
> > > > --- a/gcc/jit/jit-recording.c
> > > > +++ b/gcc/jit/jit-recording.c
> > > > @@ -2598,8 +2598,18 @@
> > > > recording::memento_of_get_pointer::accepts_writes_from (type
> > > > *rtype)
> > > > return false;
> > > >
> > > > /* It's OK to assign to a (const T *) from a (T *). */
> > > > - return m_other_type->unqualified ()
> > > > - ->accepts_writes_from (rtype_points_to);
> > > > + if (m_other_type->unqualified ()
> > > > + ->accepts_writes_from (rtype_points_to)) {
> > > > + return true;
> > > > + }
> > > > +
> > > > + /* It's OK to assign to a (volatile const T *) from a
> > > > (volatile
> > > > const T *). */
> > > > + if (m_other_type->unqualified ()->unqualified ()
> > > > + ->accepts_writes_from (rtype_points_to->unqualified ())) {
> > > > + return true;
> > > > + }
> > >
> > > Presumably you need this to get the atomic builtins working?
> > >
> > > If I'm reading the above correctly, the new test doesn't
> > > distinguish
> > > between the 3 different kinds of qualifiers (aligned, volatile,
> > > and
> > > const), it merely tries to strip some of them off.
> > >
> > > It's not valid to e.g. assign to a (aligned T *) from a (const T
> > > *).
> > >
> > > Maybe we need an internal enum to discriminate between different
> > > subclasses of decorated_type?
>
> I'm still concerned about this case, my reading of the updated patch
> is
> that this case is still not quite correctly handled (see notes
> below).
> I don't think we currently have test coverage for assignment to e.g.
> (aligned T *) from a (const T*); I feel that it should be an error,
> without an explicit cast.
>
> Please can you add a testcase for this?
Done.
>
> If you want to go the extra mile, given that this is code created
> through an API, you could have a testcase that iterates through all
> possible combinations of qualifiers (for both source and destination
> pointer), and verifies that libgccjit at least doesn't crash on them
> (and hopefully does the right thing on each one) :/
>
> (perhaps doing each one in a different gcc_jit_context)
>
> Might be nice to update test-fuzzer.c for the new qualifiers; I don't
> think I've touched it in a long time.
Done.
>
> [...snip...]
>
> > diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
> > index 4a994fe7094..60aaba2a246 100644
> > --- a/gcc/jit/jit-recording.h
> > +++ b/gcc/jit/jit-recording.h
> > @@ -545,6 +545,8 @@ public:
> > virtual bool is_float () const = 0;
> > virtual bool is_bool () const = 0;
> > virtual type *is_pointer () = 0;
> > + virtual type *is_volatile () { return NULL; }
> > + virtual type *is_const () { return NULL; }
> > virtual type *is_array () = 0;
> > virtual struct_ *is_struct () { return NULL; }
> > virtual bool is_void () const { return false; }
> > @@ -687,6 +689,13 @@ public:
> > /* Strip off the "const", giving the underlying type. */
> > type *unqualified () FINAL OVERRIDE { return m_other_type; }
> >
> > + virtual bool is_same_type_as (type *other)
> > + {
> > + return m_other_type->is_same_type_as (other->is_const ());
> > + }
>
> What happens if other_is_const () returns NULL, and
> m_other_type->is_same_type_as ()
> tries to call a vfunc on it...
Fixed.
>
> > +
> > + virtual type *is_const () { return m_other_type; }
> > +
> > void replay_into (replayer *) FINAL OVERRIDE;
> >
> > private:
> > @@ -701,9 +710,16 @@ public:
> > memento_of_get_volatile (type *other_type)
> > : decorated_type (other_type) {}
> >
> > + virtual bool is_same_type_as (type *other)
> > + {
> > + return m_other_type->is_same_type_as (other->is_volatile ());
> > + }
>
> ...with similar considerations here.
>
> i.e. is it possible for the user to create combinations of qualifiers
> that lead to a vfunc call with NULL "this" (and thus a segfault?)
>
> > +
> > /* Strip off the "volatile", giving the underlying type. */
> > type *unqualified () FINAL OVERRIDE { return m_other_type; }
> >
> > + virtual type *is_volatile () { return m_other_type; }
> > +
> > void replay_into (replayer *) FINAL OVERRIDE;
> >
>
> Hope this is constructive
> Dave
>
From b2d78a2edc1cd8b24ff88f0da608a69f1dff8229 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Re: [PATCH] libgccjit: Add support for TLS variable [PR95415]
Hi. Here's the updated patch. See comments below. Thanks for your reviews! Le jeudi 20 mai 2021 à 16:11 -0400, David Malcolm a écrit : > On Tue, 2021-05-18 at 20:43 -0400, Antoni Boucher via Gcc-patches > wrote: > > Hello. > > This patch adds support for TLS variables. > > One thing to fix before we merge it is the libgccjit.map file which > > contains LIBGCCJIT_ABI_16 instead of LIBGCCJIT_ABI_17. > > LIBGCCJIT_ABI_16 was added in one of my other patches. > > Thanks for the review. > > > diff --git a/gcc/jit/docs/topics/compatibility.rst > > b/gcc/jit/docs/topics/compatibility.rst > > index 239b6aa1a92..d10bc1df080 100644 > > --- a/gcc/jit/docs/topics/compatibility.rst > > +++ b/gcc/jit/docs/topics/compatibility.rst > > @@ -243,3 +243,12 @@ embedding assembler instructions: > > * :func:`gcc_jit_extended_asm_add_input_operand` > > * :func:`gcc_jit_extended_asm_add_clobber` > > * :func:`gcc_jit_context_add_top_level_asm` > > + > > +.. _LIBGCCJIT_ABI_17: > > + > > +``LIBGCCJIT_ABI_17`` > > +--- > > +``LIBGCCJIT_ABI_17`` covers the addition of an API entrypoint to set > > the > > +thread-local storage model of a variable: > > + > > + * :func:`gcc_jit_lvalue_set_tls_model` > > Sorry about the delay in reviewing patches. > > Is there a summary somewhere of the various outstanding patches and > their associated ABI versions? Are there dependencies between the > patches? The list of patches is there: https://github.com/antoyo/libgccjit-patches but I don't keep them up- to-date. If that would help you, I could add a README to tell what is the new ABI version for each patch. I believe there might be some patches that depend on a previous one. > > > diff --git a/gcc/jit/docs/topics/expressions.rst > b/gcc/jit/docs/topics/expressions.rst > > index 396259ef07e..68defd6a311 100644 > > --- a/gcc/jit/docs/topics/expressions.rst > > +++ b/gcc/jit/docs/topics/expressions.rst > > @@ -539,6 +539,34 @@ where the rvalue is computed by reading from > > the storage area. > > > > in C. > > > > +.. function:: void\ > > + gcc_jit_lvalue_set_tls_model (gcc_jit_lvalue > > *lvalue,\ > > + enum gcc_jit_tls_model > > model) > > + > > + Make a variable a thread-local variable. > > + > > + The "model" parameter determines the thread-local storage model > > of the "lvalue": > > + > > + .. type:: enum gcc_jit_tls_model > > + > > + .. c:macro:: GCC_JIT_TLS_MODEL_GLOBAL_DYNAMIC > > + > > + .. c:macro:: GCC_JIT_TLS_MODEL_LOCAL_DYNAMIC > > + > > + .. c:macro:: GCC_JIT_TLS_MODEL_INITIAL_EXEC > > + > > + .. c:macro:: GCC_JIT_TLS_MODEL_LOCAL_EXEC > > + > > + .. c:macro:: GCC_JIT_TLS_MODEL_DEFAULT > > + > > + This is analogous to: > > + > > + .. code-block:: c > > + > > + _Thread_local int foo; > > + > > + in C. > > This comment needs the usual "This entrypoint was added in" text to > state which API version it was added in. > > I confess to being a bit hazy on the different TLS models, and it's > unclear to me what all the different enum values do. Is this > equivalent to the various values for > __attribute__((tls_model(VALUE))) > ? This attribute is documented in > https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html, > though sadly that document doesn't seem to have a good anchor for > that > attribute. Yes, it is the equivalent of this attribute. > > https://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html currently links > to > https://www.akkadia.org/drepper/tls.pdf "for a detailed explanation > of > the four thread-local storage addressing models, and how the runtime > is > expected to function." > > One thing that should be clarified: does GCC_JIT_TLS_MODEL_DEFAULT > mean > (a) thread-local storage, using a default model, or > (b) non-thread-local storage i.e. normal storage. > > ? > > Reading the docs I thought it meant (a), but when I looked in more > detail at the implementation it looks like it means (b); is it meant > to? This needs clarifying. > > Are you using all of these enum values in your code? Is this > something > you need to expose for the rustc backend? Yes, I use all of these enum values in the rustc gcc codegen. > > > > Global variables > > > > > > diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h > > index 825a3e172e9..654a9c472d4 100644 > &
Re: [PATCH] libgccjit: Add support for setting the link section of global variables [PR100688]
Hi.
Here's the updated patch.
See comments below.
Thanks for the review!
Le samedi 20 novembre 2021 à 11:20 -0500, David Malcolm a écrit :
> On Sat, 2021-11-20 at 00:58 -0500, Antoni Boucher wrote:
> > Thanks for your reviews!
> >
> > Here's the updated patch, ready for another review.
> > See comments/questions below.
>
> Thanks for the updated patch...
>
> >
> > I'll update the other patches over the weekend.
> >
> > Le jeudi 20 mai 2021 à 15:29 -0400, David Malcolm a écrit :
> > > On Wed, 2021-05-19 at 20:32 -0400, Antoni Boucher via Jit wrote:
> > > > Hello.
> > > > This patch adds support to set the link section of global
> > > > variables.
> > > > I used the ABI 18 because I submitted other patches up to 17.
> > > > Thanks for the review.
> > >
> > > I didn't see this email until now, and put the review in bugzilla
> > > instead; sorry.
> > >
> > > Here's a copy-and-paste of what I put in bugzilla:
> > >
> > >
> > > Thanks for the patch; I like the idea; various nits below:
> > >
>
> [...snip...]
>
> > >
> > > > Global variables
> > > >
> > > >
> > > > diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
> > > > index 825a3e172e9..8b0f65e87e8 100644
> > > > --- a/gcc/jit/jit-playback.h
> > > > +++ b/gcc/jit/jit-playback.h
> > > > @@ -650,6 +650,8 @@ public:
> > > >
> > > > private:
> > > > context *m_ctxt;
> > > > +
> > > > +protected:
> > > > tree m_inner;
> > > > };
> > >
> > > I think you only use this...
> > >
> > > >
> > > > @@ -670,6 +672,12 @@ public:
> > > > rvalue *
> > > > get_address (location *loc);
> > > >
> > > > + void
> > > > + set_link_section (const char* name)
> > > > + {
> > > > + set_decl_section_name (m_inner, name);
> > > > + }
> > >
> > > ...here, and you can get at rvalue::m_inner using as_tree (), so
> > > I
> > > don't think we need to make m_inner protected.
>
> Thanks for dropping the "protected" in the updated patch; you need to
> update the ChangeLog entry.
>
> > >
> > >
> > > > + set_playback_obj (global);
> > > > }
> > > >
> > >
> > > [...snip]
> > >
> > > > diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
> > > > index 03fa1160cf0..0691fac579d 100644
> > > > --- a/gcc/jit/jit-recording.h
> > > > +++ b/gcc/jit/jit-recording.h
> > > > @@ -1105,7 +1105,8 @@ public:
> > > > lvalue (context *ctxt,
> > > > location *loc,
> > > > type *type_)
> > > > - : rvalue (ctxt, loc, type_)
> > > > + : rvalue (ctxt, loc, type_),
> > > > + m_link_section(NULL)
> > > > {}
> > > >
> > > > playback::lvalue *
> > > > @@ -1127,6 +1128,10 @@ public:
> > > > const char *access_as_rvalue (reproducer ) OVERRIDE;
> > > > virtual const char *access_as_lvalue (reproducer );
> > > > virtual bool is_global () const { return false; }
> > > > + void set_link_section (const char *name);
> > > > +
> > > > +protected:
> > > > + string *m_link_section;
> > > > };
> > >
> > > Can it be private, rather than protected?
> >
> > m_link_section can't be private because it's used in
> > recording::global::replay_into.
>
> Fair enough; thanks.
>
> > >
> > > > diff --git a/gcc/jit/libgccjit.c b/gcc/jit/libgccjit.c
> > > > index 7fa948007ad..8cfa48aae24 100644
> > > > --- a/gcc/jit/libgccjit.c
> > > > +++ b/gcc/jit/libgccjit.c
> > > > @@ -1953,6 +1953,18 @@ gcc_jit_lvalue_get_address
> > > > (gcc_jit_lvalue
> > > *lvalue,
> > > > return (gcc_jit_rvalue *)lvalue->get_address (loc);
> > > > }
> > > >
> > > > +/* Public entrypoint. See description in libgccjit.h.
> > > > +
> > > > + After error-checking, the real work is done by the
> > > > + gcc::jit::recording::lvalue::set_section method in jit-
> > > recording.c. */
> > > ^^^
> > > set_link_section
> > >
> > > Also, a newline here please for consistency with the other
> > > entrypoints.
> >
> > Where should I add a newline?
>
> Between the closing of the comment and the "void" of the fndecl (all
> the other entrypoints have a blank line separating them). Thanks for
> fixing my other nitpicks.
>
>
> [...snip...]
>
> > > > diff --git a/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > > b/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > > > index 4202eb7798b..7e3b59dee0d 100644
> > > > --- a/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > > > +++ b/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > > > @@ -181,6 +181,13 @@
> > > > #undef create_code
> > > > #undef verify_code
> > > >
> > > > +/* test-link-section.c */
> > > > +#define create_code create_code_link_section
> > > > +#define verify_code verify_code_link_section
> > > > +#include "test-link-section.c"
> > > > +#undef create_code
> > > > +#undef verify_code
>
> The updated version of the testcase doesn't have a verify_code, so it
> can't be in the "testcases" array.
> Please replace this with something like:
>
>
> /* test-link-section.c: This
Re: [PATCH] libgccjit: Add support for types used by atomic builtins [PR96066] [PR96067]
Hi.
Here's the updated patch.
Thanks for the review!
Le jeudi 20 mai 2021 à 16:24 -0400, David Malcolm a écrit :
> On Mon, 2021-05-17 at 21:02 -0400, Antoni Boucher via Jit wrote:
> > Hello.
> > This patch fixes the issue with using atomic builtins in libgccjit.
> > Thanks to review it.
>
> [...snip...]
>
> > diff --git a/gcc/jit/jit-recording.c b/gcc/jit/jit-recording.c
> > index 117ff70114c..de876ff9fa6 100644
> > --- a/gcc/jit/jit-recording.c
> > +++ b/gcc/jit/jit-recording.c
> > @@ -2598,8 +2598,18 @@
> > recording::memento_of_get_pointer::accepts_writes_from (type
> > *rtype)
> > return false;
> >
> > /* It's OK to assign to a (const T *) from a (T *). */
> > - return m_other_type->unqualified ()
> > - ->accepts_writes_from (rtype_points_to);
> > + if (m_other_type->unqualified ()
> > + ->accepts_writes_from (rtype_points_to)) {
> > + return true;
> > + }
> > +
> > + /* It's OK to assign to a (volatile const T *) from a (volatile
> > const T *). */
> > + if (m_other_type->unqualified ()->unqualified ()
> > + ->accepts_writes_from (rtype_points_to->unqualified ())) {
> > + return true;
> > + }
>
> Presumably you need this to get the atomic builtins working?
>
> If I'm reading the above correctly, the new test doesn't distinguish
> between the 3 different kinds of qualifiers (aligned, volatile, and
> const), it merely tries to strip some of them off.
>
> It's not valid to e.g. assign to a (aligned T *) from a (const T *).
>
> Maybe we need an internal enum to discriminate between different
> subclasses of decorated_type?
>
>
> > +
> > + return false;
> > }
> >
> > /* Implementation of pure virtual hook
> > recording::memento::replay_into
> > diff --git a/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > b/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > index 4202eb7798b..dfc6596358c 100644
> > --- a/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > +++ b/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > @@ -181,6 +181,13 @@
> > #undef create_code
> > #undef verify_code
> >
> > +/* test-builtin-types.c */
> > +#define create_code create_code_builtin_types
> > +#define verify_code verify_code_builtin_types
> > +#include "test-builtin-types.c"
> > +#undef create_code
> > +#undef verify_code
> > +
> > /* test-hello-world.c */
> > #define create_code create_code_hello_world
> > #define verify_code verify_code_hello_world
>
> As with various other patches, this needs to also add a new entry to
> the "testcases" array making use of the new
> {create|verify}_code_builtin_types functions.
>
> [...snip...]
>
> Hope this is constructive
> Dave
>
From 74230be2c324876b255fc1cc96fae4eece8ff2a2 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sun, 9 May 2021 20:14:37 -0400
Subject: [PATCH] libgccjit: Add support for types used by atomic builtins
[PR96066] [PR96067]
2021-11-20 Antoni Boucher
gcc/jit/
PR target/PR96066
PR target/PR96067
* jit-builtins.c: Implement missing types for builtins.
* jit-recording.c:: Allow sending a volatile const void * as
argument.
* jit-recording.h: New functions (is_volatile, is_const) and
allow comparing qualified types.
gcc/testsuite/
PR target/PR96066
PR target/PR96067
* jit.dg/all-non-failing-tests.h: Add test-builtin-types.c.
* jit.dg/test-builtin-types.c
Signed-off-by: Antoni Boucher
---
gcc/jit/jit-builtins.c | 10 ++---
gcc/jit/jit-recording.c | 9 +++-
gcc/jit/jit-recording.h | 16
gcc/testsuite/jit.dg/all-non-failing-tests.h | 10 +
gcc/testsuite/jit.dg/test-builtin-types.c| 43
5 files changed, 81 insertions(+), 7 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-builtin-types.c
diff --git a/gcc/jit/jit-builtins.c b/gcc/jit/jit-builtins.c
index 1ea96f4e025..c279dd858f9 100644
--- a/gcc/jit/jit-builtins.c
+++ b/gcc/jit/jit-builtins.c
@@ -541,11 +541,11 @@ builtins_manager::make_primitive_type (enum jit_builtin_type type_id)
// case BT_DFLOAT128:
// case BT_VALIST_REF:
// case BT_VALIST_ARG:
-// case BT_I1:
-// case BT_I2:
-// case BT_I4:
-// case BT_I8:
-// case BT_I16:
+case BT_I1: return m_ctxt->get_int_type (1, true);
+case BT_I2: return m_ctxt->get_int_type (2, true);
+case BT_I4: return m_ctxt->get_int_type (4, true);
+case BT_I8: return m_ctxt->get_int_type (8, true);
+case BT_I16: return m_ctxt->get_int_type (16, true);
// case BT_PTR_CONST_STRING:
}
}
diff --git a/gcc/jit/jit-recording.c b/gcc/jit/jit-recording.c
index 117ff70114c..2eecf44c8db 100644
--- a/gcc/jit/jit-recording.c
+++ b/gcc/jit/jit-recording.c
@@ -2598,8 +2598,13 @@ recording::memento_of_get_pointer::accepts_writes_from (type *rtype)
return false;
/* It's OK to assign to a (const T *) from a (T *). */
-
Re: [PATCH] libgccjit: Add support for setting the link section of global variables [PR100688]
Thanks for your reviews!
Here's the updated patch, ready for another review.
See comments/questions below.
I'll update the other patches over the weekend.
Le jeudi 20 mai 2021 à 15:29 -0400, David Malcolm a écrit :
> On Wed, 2021-05-19 at 20:32 -0400, Antoni Boucher via Jit wrote:
> > Hello.
> > This patch adds support to set the link section of global
> > variables.
> > I used the ABI 18 because I submitted other patches up to 17.
> > Thanks for the review.
>
> I didn't see this email until now, and put the review in bugzilla
> instead; sorry.
>
> Here's a copy-and-paste of what I put in bugzilla:
>
>
> Thanks for the patch; I like the idea; various nits below:
>
> > diff --git a/gcc/jit/docs/topics/expressions.rst
> b/gcc/jit/docs/topics/expressions.rst
> > index 396259ef07e..b39f6c02527 100644
> > --- a/gcc/jit/docs/topics/expressions.rst
> > +++ b/gcc/jit/docs/topics/expressions.rst
> > @@ -539,6 +539,18 @@ where the rvalue is computed by reading from
> > the
> storage area.
> >
> > in C.
> >
> > +.. function:: void
> > + gcc_jit_lvalue_set_link_section (gcc_jit_lvalue
> *lvalue,
> > + const char *name)
> > +
> > + Set the link section of a variable; analogous to:
> > +
> > + .. code-block:: c
> > +
> > + int variable __attribute__((section(".section")));
> > +
> > + in C.
>
> Please rename param "name" to "section_name". Your implementation
> requires that it be non-NULL (rather than having NULL unset the
> section), so please specify that it must be non-NULL in the docs.
>
> Please add the usual "This entrypoint was added in" text to state
> which
> API version it was added in.
>
> > +
> > Global variables
> >
> >
> > diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
> > index 825a3e172e9..8b0f65e87e8 100644
> > --- a/gcc/jit/jit-playback.h
> > +++ b/gcc/jit/jit-playback.h
> > @@ -650,6 +650,8 @@ public:
> >
> > private:
> > context *m_ctxt;
> > +
> > +protected:
> > tree m_inner;
> > };
>
> I think you only use this...
>
> >
> > @@ -670,6 +672,12 @@ public:
> > rvalue *
> > get_address (location *loc);
> >
> > + void
> > + set_link_section (const char* name)
> > + {
> > + set_decl_section_name (m_inner, name);
> > + }
>
> ...here, and you can get at rvalue::m_inner using as_tree (), so I
> don't think we need to make m_inner protected.
>
> > diff --git a/gcc/jit/jit-recording.c b/gcc/jit/jit-recording.c
> > index 117ff70114c..d54f878cc6b 100644
> > --- a/gcc/jit/jit-recording.c
> > +++ b/gcc/jit/jit-recording.c
> > @@ -3713,6 +3713,11 @@ recording::lvalue::get_address
> (recording::location *loc)
> > return result;
> > }
> >
> > +void recording::lvalue::set_link_section (const char *name)
> > +{
> > + m_link_section = new_string (name);
> > +}
> > +
> > /* The implementation of class gcc::jit::recording::param. */
> >
> > /* Implementation of pure virtual hook
> recording::memento::replay_into
> > @@ -4547,8 +4552,7 @@ recording::block::dump_edges_to_dot
> (pretty_printer *pp)
> > void
> > recording::global::replay_into (replayer *r)
> > {
> > - set_playback_obj (
> > - m_initializer
> > + playback::lvalue *global = m_initializer
> > ? r->new_global_initialized (playback_location (r, m_loc),
> > m_kind,
> > m_type->playback_type (),
> > @@ -4560,7 +4564,12 @@ recording::global::replay_into (replayer *r)
> > : r->new_global (playback_location (r, m_loc),
> > m_kind,
> > m_type->playback_type (),
> > - playback_string (m_name)));
> > + playback_string (m_name));
> > + if (m_link_section != NULL)
> > + {
> > + global->set_link_section(m_link_section->c_str());
> > + }
>
> Coding convention nits: don't use {} when it's just one statement
> (which I think is a bad convention, but it is the project's
> convention).
> Missing spaces between function name and open-paren in both calls
> here.
>
>
> > + set_playback_obj (global);
> > }
> >
>
> [...snip]
>
> > diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
> > index 03fa1160cf0..0691fac579d 100644
> > --- a/gcc/jit/jit-recording.h
> > +++ b/gcc/jit/jit-recording.h
> > @@ -1105,7 +1105,8 @@ public:
> > lvalue (context *ctxt,
> > location *loc,
> > type *type_)
> > - : rvalue (ctxt, loc, type_)
> > + : rvalue (ctxt, loc, type_),
> > + m_link_section(NULL)
> > {}
> >
> > playback::lvalue *
> > @@ -1127,6 +1128,10 @@ public:
> > const char *access_as_rvalue (reproducer ) OVERRIDE;
> > virtual const char *access_as_lvalue (reproducer );
> > virtual bool is_global () const { return false; }
> > + void set_link_section (const char *name);
> > +
> > +protected:
> > + string *m_link_section;
> > };
>
> Can it be private, rather than protected?
Re: [PATCH] libgccjit: add some reflection functions in the jit C api
David: PING Le mardi 12 octobre 2021 à 22:09 -0400, Antoni Boucher a écrit : > David: PING > > Le lundi 27 septembre 2021 à 20:53 -0400, Antoni Boucher a écrit : > > I fixed an issue (it would show an error message when > > gcc_jit_type_dyncast_function_ptr_type was called on a type > > different > > than a function pointer type). > > > > Here's the updated patch. > > > > Le vendredi 18 juin 2021 à 16:37 -0400, David Malcolm a écrit : > > > On Fri, 2021-06-18 at 15:41 -0400, Antoni Boucher wrote: > > > > I have write access now. > > > > > > Great. > > > > > > > I'm not sure how I'm supposed to send my patches: > > > > should I put it in personal branches and you'll merge them? > > > > > > Please send them to this mailing list for review; once they're > > > approved > > > you can merge them. > > > > > > > > > > > And for the MAINTAINERS file, should I just push to master > > > > right > > > > away, > > > > after sending it to the mailing list? > > > > > > I think people just push the MAINTAINERS change and then let the > > > list > > > know, since it makes a good test that write access is working > > > correctly. > > > > > > Dave > > > > > > > > > > > Thanks for your help! > > > > > > > > Le vendredi 18 juin 2021 à 12:09 -0400, David Malcolm a écrit : > > > > > On Fri, 2021-06-18 at 11:55 -0400, Antoni Boucher wrote: > > > > > > Le vendredi 11 juin 2021 à 14:00 -0400, David Malcolm a > > > > > > écrit : > > > > > > > On Fri, 2021-06-11 at 08:15 -0400, Antoni Boucher wrote: > > > > > > > > Thank you for your answer. > > > > > > > > I attached the updated patch. > > > > > > > > > > > > > > BTW you (or possibly me) dropped the mailing lists; was > > > > > > > that > > > > > > > deliberate? > > > > > > > > > > > > Oh, my bad. > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have signed the FSF copyright attribution. > > > > > > > > > > > > > > I can push changes on your behalf, but I'd prefer it if > > > > > > > you > > > > > > > did > > > > > > > it, > > > > > > > especially given that you have various other patches you > > > > > > > want > > > > > > > to > > > > > > > get > > > > > > > in. > > > > > > > > > > > > > > Instructions on how to get push rights to the git repo > > > > > > > are > > > > > > > here: > > > > > > > https://gcc.gnu.org/gitwrite.html > > > > > > > > > > > > > > I can sponsor you. > > > > > > > > > > > > Thanks. > > > > > > I did sign up to get push rights. > > > > > > Have you accepted my request to get those? > > > > > > > > > > I did, but I didn't see any kind of notification. Did you > > > > > get > > > > > an > > > > > email > > > > > about it? > > > > > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > > > >
Re: [PATCH] libgccjit: add some reflection functions in the jit C api
David: PING Le lundi 27 septembre 2021 à 20:53 -0400, Antoni Boucher a écrit : > I fixed an issue (it would show an error message when > gcc_jit_type_dyncast_function_ptr_type was called on a type different > than a function pointer type). > > Here's the updated patch. > > Le vendredi 18 juin 2021 à 16:37 -0400, David Malcolm a écrit : > > On Fri, 2021-06-18 at 15:41 -0400, Antoni Boucher wrote: > > > I have write access now. > > > > Great. > > > > > I'm not sure how I'm supposed to send my patches: > > > should I put it in personal branches and you'll merge them? > > > > Please send them to this mailing list for review; once they're > > approved > > you can merge them. > > > > > > > > And for the MAINTAINERS file, should I just push to master right > > > away, > > > after sending it to the mailing list? > > > > I think people just push the MAINTAINERS change and then let the > > list > > know, since it makes a good test that write access is working > > correctly. > > > > Dave > > > > > > > > Thanks for your help! > > > > > > Le vendredi 18 juin 2021 à 12:09 -0400, David Malcolm a écrit : > > > > On Fri, 2021-06-18 at 11:55 -0400, Antoni Boucher wrote: > > > > > Le vendredi 11 juin 2021 à 14:00 -0400, David Malcolm a > > > > > écrit : > > > > > > On Fri, 2021-06-11 at 08:15 -0400, Antoni Boucher wrote: > > > > > > > Thank you for your answer. > > > > > > > I attached the updated patch. > > > > > > > > > > > > BTW you (or possibly me) dropped the mailing lists; was > > > > > > that > > > > > > deliberate? > > > > > > > > > > Oh, my bad. > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > > > > > > > > > I have signed the FSF copyright attribution. > > > > > > > > > > > > I can push changes on your behalf, but I'd prefer it if you > > > > > > did > > > > > > it, > > > > > > especially given that you have various other patches you > > > > > > want > > > > > > to > > > > > > get > > > > > > in. > > > > > > > > > > > > Instructions on how to get push rights to the git repo are > > > > > > here: > > > > > > https://gcc.gnu.org/gitwrite.html > > > > > > > > > > > > I can sponsor you. > > > > > > > > > > Thanks. > > > > > I did sign up to get push rights. > > > > > Have you accepted my request to get those? > > > > > > > > I did, but I didn't see any kind of notification. Did you get > > > > an > > > > email > > > > about it? > > > > > > > > > > > > Dave > > > > > > > > > > > > > > >
Re: [PATCH] libgccjit: add some reflection functions in the jit C api
I fixed an issue (it would show an error message when gcc_jit_type_dyncast_function_ptr_type was called on a type different than a function pointer type). Here's the updated patch. Le vendredi 18 juin 2021 à 16:37 -0400, David Malcolm a écrit : > On Fri, 2021-06-18 at 15:41 -0400, Antoni Boucher wrote: > > I have write access now. > > Great. > > > I'm not sure how I'm supposed to send my patches: > > should I put it in personal branches and you'll merge them? > > Please send them to this mailing list for review; once they're > approved > you can merge them. > > > > > And for the MAINTAINERS file, should I just push to master right > > away, > > after sending it to the mailing list? > > I think people just push the MAINTAINERS change and then let the list > know, since it makes a good test that write access is working > correctly. > > Dave > > > > > Thanks for your help! > > > > Le vendredi 18 juin 2021 à 12:09 -0400, David Malcolm a écrit : > > > On Fri, 2021-06-18 at 11:55 -0400, Antoni Boucher wrote: > > > > Le vendredi 11 juin 2021 à 14:00 -0400, David Malcolm a écrit : > > > > > On Fri, 2021-06-11 at 08:15 -0400, Antoni Boucher wrote: > > > > > > Thank you for your answer. > > > > > > I attached the updated patch. > > > > > > > > > > BTW you (or possibly me) dropped the mailing lists; was that > > > > > deliberate? > > > > > > > > Oh, my bad. > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > > > > I have signed the FSF copyright attribution. > > > > > > > > > > I can push changes on your behalf, but I'd prefer it if you > > > > > did > > > > > it, > > > > > especially given that you have various other patches you want > > > > > to > > > > > get > > > > > in. > > > > > > > > > > Instructions on how to get push rights to the git repo are > > > > > here: > > > > > https://gcc.gnu.org/gitwrite.html > > > > > > > > > > I can sponsor you. > > > > > > > > Thanks. > > > > I did sign up to get push rights. > > > > Have you accepted my request to get those? > > > > > > I did, but I didn't see any kind of notification. Did you get an > > > email > > > about it? > > > > > > > > > Dave > > > > > > > > > From 95f8b85bcc7b1259eef1e9916de824c752b2f2c0 Mon Sep 17 00:00:00 2001 From: Antoni Boucher Date: Sat, 1 Aug 2020 17:52:17 -0400 Subject: [PATCH] libgccjit: Add some reflection functions [PR96889] 2021-07-19 Antoni Boucher gcc/jit/ PR target/96889 * docs/topics/compatibility.rst (LIBGCCJIT_ABI_16): New ABI tag. * docs/topics/functions.rst: Add documentation for the functions gcc_jit_function_get_return_type and gcc_jit_function_get_param_count * docs/topics/types.rst: Add documentation for the functions gcc_jit_function_type_get_return_type, gcc_jit_function_type_get_param_count, gcc_jit_function_type_get_param_type, gcc_jit_type_unqualified, gcc_jit_type_dyncast_array, gcc_jit_type_is_bool, gcc_jit_type_dyncast_function_ptr_type, gcc_jit_type_is_integral, gcc_jit_type_is_pointer, gcc_jit_type_dyncast_vector, gcc_jit_vector_type_get_element_type, gcc_jit_vector_type_get_num_units, gcc_jit_struct_get_field, gcc_jit_type_is_struct, and gcc_jit_struct_get_field_count * libgccjit.c: (gcc_jit_function_get_return_type, gcc_jit_function_get_param_count, gcc_jit_function_type_get_return_type, gcc_jit_function_type_get_param_count, gcc_jit_function_type_get_param_type, gcc_jit_type_unqualified, gcc_jit_type_dyncast_array, gcc_jit_type_is_bool, gcc_jit_type_dyncast_function_ptr_type, gcc_jit_type_is_integral, gcc_jit_type_is_pointer, gcc_jit_type_dyncast_vector, gcc_jit_vector_type_get_element_type, gcc_jit_vector_type_get_num_units, gcc_jit_struct_get_field, gcc_jit_type_is_struct, gcc_jit_struct_get_field_count): New functions. (struct gcc_jit_function_type, struct gcc_jit_vector_type): New types. * libgccjit.h: (gcc_jit_function_get_return_type, gcc_jit_function_get_param_count, gcc_jit_function_type_get_return_type, gcc_jit_function_type_get_param_count, gcc_jit_function_type_get_param_type, gcc_jit_type_unqualified, gcc_jit_type_dyncast_array, gcc_jit_type_is_bool, gcc_jit_type_dyncast_function_ptr_type, gcc_jit_type_is_integral, gcc_jit_type_is_pointer, gcc_jit_type_dyncast_vector, gcc_jit_vector_type_get_element_type, gcc_jit_vector_type_get_num_units, gcc_jit_struct_get_field, gcc_jit_type_is_struct, gcc_jit_struct_get_field_count): New function declarations. (struct gcc_jit_function_type, struct gcc_jit_vector_type): New types. * jit-recording.h: New functions (is_struct and is_vector) * libgccjit.map (LIBGCCJIT_ABI_16): New ABI tag. gcc/testsuite/ PR target/96889 * jit.dg/all-non-failing-tests.h: Add test-reflection.c. * jit.dg/test-reflection.c: New test. --- gcc/jit/docs/topics/compatibility.rst| 43 ++- gcc/jit/docs/topics/functions.rst| 26 ++ gcc/jit/docs/topics/types.rst| 122 + gcc/jit/jit-recording.h | 7 + gcc/jit/libgccjit.c
Re: [PATCH] libgccjit: add some reflection functions in the jit C api
David: PING Le jeudi 29 juillet 2021 à 08:59 -0400, Antoni Boucher a écrit : > David: PING > > Le lundi 19 juillet 2021 à 12:10 -0400, Antoni Boucher a écrit : > > I'm sending the patch once again for review/approval. > > > > I fixed the doc to use the new function names. > > > > Le vendredi 18 juin 2021 à 16:37 -0400, David Malcolm a écrit : > > > On Fri, 2021-06-18 at 15:41 -0400, Antoni Boucher wrote: > > > > I have write access now. > > > > > > Great. > > > > > > > I'm not sure how I'm supposed to send my patches: > > > > should I put it in personal branches and you'll merge them? > > > > > > Please send them to this mailing list for review; once they're > > > approved > > > you can merge them. > > > > > > > > > > > And for the MAINTAINERS file, should I just push to master > > > > right > > > > away, > > > > after sending it to the mailing list? > > > > > > I think people just push the MAINTAINERS change and then let the > > > list > > > know, since it makes a good test that write access is working > > > correctly. > > > > > > Dave > > > > > > > > > > > Thanks for your help! > > > > > > > > Le vendredi 18 juin 2021 à 12:09 -0400, David Malcolm a écrit : > > > > > On Fri, 2021-06-18 at 11:55 -0400, Antoni Boucher wrote: > > > > > > Le vendredi 11 juin 2021 à 14:00 -0400, David Malcolm a > > > > > > écrit : > > > > > > > On Fri, 2021-06-11 at 08:15 -0400, Antoni Boucher wrote: > > > > > > > > Thank you for your answer. > > > > > > > > I attached the updated patch. > > > > > > > > > > > > > > BTW you (or possibly me) dropped the mailing lists; was > > > > > > > that > > > > > > > deliberate? > > > > > > > > > > > > Oh, my bad. > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have signed the FSF copyright attribution. > > > > > > > > > > > > > > I can push changes on your behalf, but I'd prefer it if > > > > > > > you > > > > > > > did > > > > > > > it, > > > > > > > especially given that you have various other patches you > > > > > > > want > > > > > > > to > > > > > > > get > > > > > > > in. > > > > > > > > > > > > > > Instructions on how to get push rights to the git repo > > > > > > > are > > > > > > > here: > > > > > > > https://gcc.gnu.org/gitwrite.html > > > > > > > > > > > > > > I can sponsor you. > > > > > > > > > > > > Thanks. > > > > > > I did sign up to get push rights. > > > > > > Have you accepted my request to get those? > > > > > > > > > > I did, but I didn't see any kind of notification. Did you > > > > > get > > > > > an > > > > > email > > > > > about it? > > > > > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > > > >
Re: [PATCH] libgccjit: add some reflection functions in the jit C api
David: PING Le lundi 19 juillet 2021 à 12:10 -0400, Antoni Boucher a écrit : > I'm sending the patch once again for review/approval. > > I fixed the doc to use the new function names. > > Le vendredi 18 juin 2021 à 16:37 -0400, David Malcolm a écrit : > > On Fri, 2021-06-18 at 15:41 -0400, Antoni Boucher wrote: > > > I have write access now. > > > > Great. > > > > > I'm not sure how I'm supposed to send my patches: > > > should I put it in personal branches and you'll merge them? > > > > Please send them to this mailing list for review; once they're > > approved > > you can merge them. > > > > > > > > And for the MAINTAINERS file, should I just push to master right > > > away, > > > after sending it to the mailing list? > > > > I think people just push the MAINTAINERS change and then let the > > list > > know, since it makes a good test that write access is working > > correctly. > > > > Dave > > > > > > > > Thanks for your help! > > > > > > Le vendredi 18 juin 2021 à 12:09 -0400, David Malcolm a écrit : > > > > On Fri, 2021-06-18 at 11:55 -0400, Antoni Boucher wrote: > > > > > Le vendredi 11 juin 2021 à 14:00 -0400, David Malcolm a > > > > > écrit : > > > > > > On Fri, 2021-06-11 at 08:15 -0400, Antoni Boucher wrote: > > > > > > > Thank you for your answer. > > > > > > > I attached the updated patch. > > > > > > > > > > > > BTW you (or possibly me) dropped the mailing lists; was > > > > > > that > > > > > > deliberate? > > > > > > > > > > Oh, my bad. > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > > > > > > > > > I have signed the FSF copyright attribution. > > > > > > > > > > > > I can push changes on your behalf, but I'd prefer it if you > > > > > > did > > > > > > it, > > > > > > especially given that you have various other patches you > > > > > > want > > > > > > to > > > > > > get > > > > > > in. > > > > > > > > > > > > Instructions on how to get push rights to the git repo are > > > > > > here: > > > > > > https://gcc.gnu.org/gitwrite.html > > > > > > > > > > > > I can sponsor you. > > > > > > > > > > Thanks. > > > > > I did sign up to get push rights. > > > > > Have you accepted my request to get those? > > > > > > > > I did, but I didn't see any kind of notification. Did you get > > > > an > > > > email > > > > about it? > > > > > > > > > > > > Dave > > > > > > > > > > > > > > >
Re: [PATCH] libgccjit: add some reflection functions in the jit C api
I'm sending the patch once again for review/approval. I fixed the doc to use the new function names. Le vendredi 18 juin 2021 à 16:37 -0400, David Malcolm a écrit : > On Fri, 2021-06-18 at 15:41 -0400, Antoni Boucher wrote: > > I have write access now. > > Great. > > > I'm not sure how I'm supposed to send my patches: > > should I put it in personal branches and you'll merge them? > > Please send them to this mailing list for review; once they're > approved > you can merge them. > > > > > And for the MAINTAINERS file, should I just push to master right > > away, > > after sending it to the mailing list? > > I think people just push the MAINTAINERS change and then let the list > know, since it makes a good test that write access is working > correctly. > > Dave > > > > > Thanks for your help! > > > > Le vendredi 18 juin 2021 à 12:09 -0400, David Malcolm a écrit : > > > On Fri, 2021-06-18 at 11:55 -0400, Antoni Boucher wrote: > > > > Le vendredi 11 juin 2021 à 14:00 -0400, David Malcolm a écrit : > > > > > On Fri, 2021-06-11 at 08:15 -0400, Antoni Boucher wrote: > > > > > > Thank you for your answer. > > > > > > I attached the updated patch. > > > > > > > > > > BTW you (or possibly me) dropped the mailing lists; was that > > > > > deliberate? > > > > > > > > Oh, my bad. > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > > > > I have signed the FSF copyright attribution. > > > > > > > > > > I can push changes on your behalf, but I'd prefer it if you > > > > > did > > > > > it, > > > > > especially given that you have various other patches you want > > > > > to > > > > > get > > > > > in. > > > > > > > > > > Instructions on how to get push rights to the git repo are > > > > > here: > > > > > https://gcc.gnu.org/gitwrite.html > > > > > > > > > > I can sponsor you. > > > > > > > > Thanks. > > > > I did sign up to get push rights. > > > > Have you accepted my request to get those? > > > > > > I did, but I didn't see any kind of notification. Did you get an > > > email > > > about it? > > > > > > > > > Dave > > > > > > > > > From aaf77d109d74afb0f46d3e5d4d094914cb1b21de Mon Sep 17 00:00:00 2001 From: Antoni Boucher Date: Sat, 1 Aug 2020 17:52:17 -0400 Subject: [PATCH] libgccjit: Add some reflection functions [PR96889] 2021-07-19 Antoni Boucher gcc/jit/ PR target/96889 * docs/topics/compatibility.rst (LIBGCCJIT_ABI_16): New ABI tag. * docs/topics/functions.rst: Add documentation for the functions gcc_jit_function_get_return_type and gcc_jit_function_get_param_count * docs/topics/types.rst: Add documentation for the functions gcc_jit_function_type_get_return_type, gcc_jit_function_type_get_param_count, gcc_jit_function_type_get_param_type, gcc_jit_type_unqualified, gcc_jit_type_dyncast_array, gcc_jit_type_is_bool, gcc_jit_type_dyncast_function_ptr_type, gcc_jit_type_is_integral, gcc_jit_type_is_pointer, gcc_jit_type_dyncast_vector, gcc_jit_vector_type_get_element_type, gcc_jit_vector_type_get_num_units, gcc_jit_struct_get_field, gcc_jit_type_is_struct, and gcc_jit_struct_get_field_count * libgccjit.c: (gcc_jit_function_get_return_type, gcc_jit_function_get_param_count, gcc_jit_function_type_get_return_type, gcc_jit_function_type_get_param_count, gcc_jit_function_type_get_param_type, gcc_jit_type_unqualified, gcc_jit_type_dyncast_array, gcc_jit_type_is_bool, gcc_jit_type_dyncast_function_ptr_type, gcc_jit_type_is_integral, gcc_jit_type_is_pointer, gcc_jit_type_dyncast_vector, gcc_jit_vector_type_get_element_type, gcc_jit_vector_type_get_num_units, gcc_jit_struct_get_field, gcc_jit_type_is_struct, gcc_jit_struct_get_field_count): New functions. (struct gcc_jit_function_type, struct gcc_jit_vector_type): New types. * libgccjit.h: (gcc_jit_function_get_return_type, gcc_jit_function_get_param_count, gcc_jit_function_type_get_return_type, gcc_jit_function_type_get_param_count, gcc_jit_function_type_get_param_type, gcc_jit_type_unqualified, gcc_jit_type_dyncast_array, gcc_jit_type_is_bool, gcc_jit_type_dyncast_function_ptr_type, gcc_jit_type_is_integral, gcc_jit_type_is_pointer, gcc_jit_type_dyncast_vector, gcc_jit_vector_type_get_element_type, gcc_jit_vector_type_get_num_units, gcc_jit_struct_get_field, gcc_jit_type_is_struct, gcc_jit_struct_get_field_count): New function declarations. (struct gcc_jit_function_type, struct gcc_jit_vector_type): New types. * jit-recording.h: New functions (is_struct and is_vector) * libgccjit.map (LIBGCCJIT_ABI_16): New ABI tag. gcc/testsuite/ PR target/96889 * jit.dg/all-non-failing-tests.h: Add test-reflection.c. * jit.dg/test-reflection.c: New test. --- gcc/jit/docs/topics/compatibility.rst| 43 ++- gcc/jit/docs/topics/functions.rst| 26 ++ gcc/jit/docs/topics/types.rst| 122 + gcc/jit/jit-recording.h | 7 + gcc/jit/libgccjit.c | 261 +++ gcc/jit/libgccjit.h
Re: [PATCH] libgccjit: Handle truncation and extension for casts [PR 95498]
Ok. Here's the patch with the updated subject and with format fixed. Le vendredi 18 juin 2021 à 16:54 -0400, David Malcolm a écrit : > On Fri, 2021-06-18 at 16:42 -0400, Antoni Boucher wrote: > > I'm sending the patch once again for review. > > > > As it's the first time I'll land a patch, I'm not sure what needs > > to be > > done when it's approved. > > Do I just commit it to the master branch directly? > > Commit (and push), yes, but... > > Please ensure the subject line of the commit matches our policy: > > "libgccjit: Handle truncation and extension for casts [PR95498]" > > is a good subject, whereas: > > "This patch handles truncation and extension for casts in jit." > > is not. > > We have some hooks that will only accept pushes if the commit message > has a correctly formatted ChangeLog. The hooks ought to also add > notification comments to bugzilla for any bugs mentioned in the > commit > message. > > See https://gcc.gnu.org/gitwrite.html#checkin > > > FWIW in my own workflow I have a writable working copy that I keep > for > just doing pushes; > I do a > git pull > verify the build, then > git am FOO.patch --ignore-date > to apply the patch that was tested and approved, then do a last test > with that, then > git push > > That way I only push the patches that I've tested and have been > approved, and the other ones are in an entirely separate working > copy. > This may be overkill though. > > I'm also on #gcc IRC right now on OFTC (dmalcolm) if you run into > issues. > > Dave > > > > > Thanks! > > > > Le vendredi 11 juin 2021 à 13:49 -0400, David Malcolm a écrit : > > > On Thu, 2021-05-27 at 21:22 -0400, Antoni Boucher wrote: > > > > Here's the patch with the condition removed. > > > > I believe everything is now fixed. > > > > Thanks! > > > > > > Thanks; this looks good to me. Is this the latest version of the > > > patch; would you like me to apply it? > > > > > > Dave > > > > > > > > > > > Le jeudi 27 mai 2021 à 18:21 -0400, David Malcolm a écrit : > > > > > On Tue, 2021-05-25 at 20:16 -0400, Antoni Boucher wrote: > > > > > > I updated the patch according to the comments by Tom > > > > > > Tromey. > > > > > > > > > > > > There's one question left about your question regarding > > > > > > C_MAYBE_CONST_EXPR, David: > > > > > > > > > > > > I am not sure if we can get a C_MAYBE_CONST_EXPR from > > > > > > libgccjit, > > > > > > and > > > > > > it > > > > > > indeed seems like it's only created in c-family. > > > > > > However, we do use it in libgccjit here: > > > > > > https://github.com/gcc-mirror/gcc/blob/master/gcc/jit/jit-playback.c#L1180 > > > > > > > > > > > > I tried removing the condition `if (TREE_CODE (t_ret) != > > > > > > C_MAYBE_CONST_EXPR)` and all the tests of libgccjit still > > > > > > pass. > > > > > > > > > > > > That code was copied from here: > > > > > > https://github.com/gcc-mirror/gcc/blob/master/gcc/c/c-convert.c#L175 > > > > > > and might not be needed in libgccjit. > > > > > > > > > > > > Should I just remove the condition, then? > > > > > > > > > > I think so. > > > > > > > > > > Thanks > > > > > Dave > > > > > > > > > > > > > > > > > Le jeudi 13 mai 2021 à 19:58 -0400, David Malcolm a écrit : > > > > > > > On Thu, 2021-05-13 at 19:31 -0400, Antoni Boucher wrote: > > > > > > > > Thanks for your answer. > > > > > > > > > > > > > > > > See my answers below: > > > > > > > > > > > > > > > > Le jeudi 13 mai 2021 à 18:13 -0400, David Malcolm a > > > > > > > > écrit : > > > > > > > > > On Sat, 2021-02-20 at 17:17 -0500, Antoni Boucher via > > > > > > > > > Gcc- > > > > > > > > > patches > > > > > > > > > wrote: > > > > > > > > > > Hi. > > > > > > > > > > Thanks for your feedback! > > > > > > > > > >
[PATCH] Added myself to the MAINTAINERS file
Hi. I pushed a patch adding myself to the maintainers file. From 93022946df2463ad49e3eaa2f6d43c47c16f31c0 Mon Sep 17 00:00:00 2001 From: Antoni Boucher Date: Fri, 18 Jun 2021 16:49:20 -0400 Subject: [PATCH] MAINTAINERS: Add myself for write after approval ChangeLog: 2021-06-18 Antoni Boucher * MAINTAINERS (Write After Approval): Add myself. --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index e04477831eb..32a414ba8af 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -337,6 +337,7 @@ Lynn Boger Ian Bolton Andrea Bona Neil Booth +Antoni Boucher Robert Bowdidge Joel Brobecker Dave Brolley -- 2.32.0
Re: [PATCH] libgccjit: Handle truncation and extension for casts [PR 95498]
I'm sending the patch once again for review. As it's the first time I'll land a patch, I'm not sure what needs to be done when it's approved. Do I just commit it to the master branch directly? Thanks! Le vendredi 11 juin 2021 à 13:49 -0400, David Malcolm a écrit : > On Thu, 2021-05-27 at 21:22 -0400, Antoni Boucher wrote: > > Here's the patch with the condition removed. > > I believe everything is now fixed. > > Thanks! > > Thanks; this looks good to me. Is this the latest version of the > patch; would you like me to apply it? > > Dave > > > > > Le jeudi 27 mai 2021 à 18:21 -0400, David Malcolm a écrit : > > > On Tue, 2021-05-25 at 20:16 -0400, Antoni Boucher wrote: > > > > I updated the patch according to the comments by Tom Tromey. > > > > > > > > There's one question left about your question regarding > > > > C_MAYBE_CONST_EXPR, David: > > > > > > > > I am not sure if we can get a C_MAYBE_CONST_EXPR from > > > > libgccjit, > > > > and > > > > it > > > > indeed seems like it's only created in c-family. > > > > However, we do use it in libgccjit here: > > > > https://github.com/gcc-mirror/gcc/blob/master/gcc/jit/jit-playback.c#L1180 > > > > > > > > I tried removing the condition `if (TREE_CODE (t_ret) != > > > > C_MAYBE_CONST_EXPR)` and all the tests of libgccjit still pass. > > > > > > > > That code was copied from here: > > > > https://github.com/gcc-mirror/gcc/blob/master/gcc/c/c-convert.c#L175 > > > > and might not be needed in libgccjit. > > > > > > > > Should I just remove the condition, then? > > > > > > I think so. > > > > > > Thanks > > > Dave > > > > > > > > > > > Le jeudi 13 mai 2021 à 19:58 -0400, David Malcolm a écrit : > > > > > On Thu, 2021-05-13 at 19:31 -0400, Antoni Boucher wrote: > > > > > > Thanks for your answer. > > > > > > > > > > > > See my answers below: > > > > > > > > > > > > Le jeudi 13 mai 2021 à 18:13 -0400, David Malcolm a écrit : > > > > > > > On Sat, 2021-02-20 at 17:17 -0500, Antoni Boucher via > > > > > > > Gcc- > > > > > > > patches > > > > > > > wrote: > > > > > > > > Hi. > > > > > > > > Thanks for your feedback! > > > > > > > > > > > > > > > > > > > > > > Sorry about the delay in responding. > > > > > > > > > > > > > > In the past I was hesitant about adding more cast support > > > > > > > to > > > > > > > libgccjit > > > > > > > since I felt that the user could always just create a > > > > > > > union > > > > > > > to > > > > > > > do > > > > > > > the > > > > > > > cast. Then I tried actually using the libgccjit API to > > > > > > > do > > > > > > > this, > > > > > > > and > > > > > > > realized how much work it adds, so I now think we do want > > > > > > > to > > > > > > > support > > > > > > > casting more types. > > > > > > > > > > > > > > > > > > > > > > See answers below: > > > > > > > > > > > > > > > > On Sat, Feb 20, 2021 at 11:20:35AM -0700, Tom Tromey > > > > > > > > wrote: > > > > > > > > > > > > > > "Antoni" == Antoni Boucher via Gcc-patches > > > > > > > > > > > > > > < > > > > > > > > > > > > > > gcc-patches@gcc.gnu.org> writes: > > > > > > > > > > > > > > > > > > Antoni> gcc/jit/ > > > > > > > > > Antoni> PR target/95498 > > > > > > > > > Antoni> * jit-playback.c: Add support to > > > > > > > > > handle > > > > > > > > > truncation > > > > > > > > > and extension > > > > > > > > > Antoni> in the convert function. > > > > > > > > > > > &g
Re: [PATCH] libgccjit: add some reflection functions in the jit C api
I have write access now. I'm not sure how I'm supposed to send my patches: should I put it in personal branches and you'll merge them? And for the MAINTAINERS file, should I just push to master right away, after sending it to the mailing list? Thanks for your help! Le vendredi 18 juin 2021 à 12:09 -0400, David Malcolm a écrit : > On Fri, 2021-06-18 at 11:55 -0400, Antoni Boucher wrote: > > Le vendredi 11 juin 2021 à 14:00 -0400, David Malcolm a écrit : > > > On Fri, 2021-06-11 at 08:15 -0400, Antoni Boucher wrote: > > > > Thank you for your answer. > > > > I attached the updated patch. > > > > > > BTW you (or possibly me) dropped the mailing lists; was that > > > deliberate? > > > > Oh, my bad. > > > > [...] > > > > > > > > > > > > I have signed the FSF copyright attribution. > > > > > > I can push changes on your behalf, but I'd prefer it if you did > > > it, > > > especially given that you have various other patches you want to > > > get > > > in. > > > > > > Instructions on how to get push rights to the git repo are here: > > > https://gcc.gnu.org/gitwrite.html > > > > > > I can sponsor you. > > > > Thanks. > > I did sign up to get push rights. > > Have you accepted my request to get those? > > I did, but I didn't see any kind of notification. Did you get an > email > about it? > > > Dave >
Re: [PATCH] libgccjit: add some reflection functions in the jit C api
Le vendredi 11 juin 2021 à 14:00 -0400, David Malcolm a écrit :
> On Fri, 2021-06-11 at 08:15 -0400, Antoni Boucher wrote:
> > Thank you for your answer.
> > I attached the updated patch.
>
> BTW you (or possibly me) dropped the mailing lists; was that
> deliberate?
Oh, my bad.
> >
> > See my answers below.
> >
> > Le jeudi 10 juin 2021 à 18:41 -0400, David Malcolm a écrit :
> > > On Thu, 2021-05-27 at 21:51 -0400, Antoni Boucher wrote:
> > > > I chose option A, so everything is a size_t, now.
> > > > I also renamed the dyncast functions.
> > > > Here's the new patch.
> > >
> > > Thanks, sorry again about the delays in reviewing your work.
> > >
> > > You didn't specify how you tested the patch; are you running the
> > > full
> > > jit regression test suite?
> >
> > Yes, I run the full jit test suite.
>
> Great.
>
> [...snip...]
>
> > >
> > > I can't remember, sorry, do you have push rights to the gcc git
> > > repository?
> >
> > I don't have push rights; it's actually my first contribution to
> > gcc.
>
> Congratulations! I'm excited about having Rust support for GCC (two
> different ways, in fact!)
Yup. Exciting times!
>
> > I have signed the FSF copyright attribution.
>
> I can push changes on your behalf, but I'd prefer it if you did it,
> especially given that you have various other patches you want to get
> in.
>
> Instructions on how to get push rights to the git repo are here:
> https://gcc.gnu.org/gitwrite.html
>
> I can sponsor you.
Thanks.
I did sign up to get push rights.
Have you accepted my request to get those?
>
> Note that your patches would still need review/approval ("Write After
> Approval").
>
> > > Do you have a preference as to which patch you want me to look at
> > > next?
> > > Otherwise I'll go through them in the order in
> > > https://github.com/antoyo/rustc_codegen_gcc/tree/master/gcc-patches
> >
> > You can indeed look in this directory in the order they were added.
> > There was one patch before the reflection one (0001-This-patch-
> > handles-
> > truncation-and-extension-for-cast.patch), but since it's only a
> > bugfix,
> > it doesn't matter if it's merged after.
>
> That one looks good to me now too (I've replied on that patch).
>
> >
> > This one is ready for review, but I believe the other one needs
> > correction on my end since the last review you made. I'll make sure
> > to
> > fix them soon.
>
> Now I'm confused as to which patches you're referring to, sorry.
> I'll
> hold off for now on further reviews; let me know when you want me to
> look at them, and which ones.
>
> Thanks
> Dave
>
Re: [PATCH] libgccjit: Add function to set the initial value of a global variable [PR96089]
David: this one wasn't reviewed yet by you, so you can review it. Le jeudi 20 mai 2021 à 21:27 -0400, Antoni Boucher a écrit : > Hi. > > I made this patch to set an arbitrary value to a global variable. > > This patch suffers from the same issue as inline assembly > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380), i.e. it > segfaults if the `rvalue` is created after the global variable. > It seems to be a design issue so I'm not sure what would be the fix > for > it and having it fixed would allow me to test this new function much > more and see if things are missing (i.e. it might require a way to > create a constant struct). > See the link above for an explanation of this issue. > > Thanks for the review.
Re: [PATCH] libgccjit: add some reflection functions in the jit C api
I chose option A, so everything is a size_t, now. I also renamed the dyncast functions. Here's the new patch. Le jeudi 27 mai 2021 à 18:19 -0400, David Malcolm a écrit : > On Tue, 2021-05-25 at 20:19 -0400, Antoni Boucher wrote: > > @David: PING > > > > As far as I know, the only remaining question is about using > > `ssize_t` > > for the return type of some functions. > > Here's why I use this type: > > > > That seemed off to return NULL for the functions returning a > > size_t to indicate an error. So I changed it to return -1 (and > > return > > type to ssize_t). Is that the proper way to indicate an error? > > > > Once I know the answer for this error handling question, I'll fix > > the > > types. > > > > Thanks! > > I think the things that accept params for indexes should be size_t > (i.e. unsigned). > > As for the error-handling, I've been going back and forth. > > The various return of -1 in the patch all occur when NULL is passed > in > as the gcc_jit_foo*, for the various foo. Unfortunately this means > that > we can't get at a jit context to emit the error on, so jit_error is > called with a NULL context, and hence merely prints to stderr; it > can't > set state on any jit context. > > Presumably if the code is passing in NULL for one of these things, > then > something's gone wrong already. > > Option (A): returning a size_t (unsigned): > - No way to indicate error if the user passes in NULL, or a bogus > value, beyond output on stderr; we have to defensively return 0, > which > the user's code is likely to gracefully handle > > Option (B): returning a ssize_t: > - Can return -1 if the user passes in NULL or a bogus value. But if > the user doesn't check for -1 and blithely casts to unsigned (e.g. > allocating a buffer), their code is likely to explode with a very > large > allocation. > > Consider e.g. gcc_jit_function_type_get_param_count. If the user > uses > gcc_jit_type_is_function_ptr_type to dynamically cast some type to > function_type and forgets to check, and passes in NULL, then... > > ...with option (A), it returns 0, as if the function has no params; > eventually a type-checking error occurs. > > ...with option (B), it returns -1, and the user who didn't check > before > has to check again > > So I think I prefer option (A), but I'm willing to be convinced on > the > alternative. > > I also now think that the dynamic cast functions (e.g. > gcc_jit_type_is_function_ptr_type) should be "_dyncast_" rather than > "_is_" (e.g. gcc_jit_type_dyncast_function_ptr_type) to make it clear > that this is a dynamic cast that can fail, and to contrast them with > the "_as_" functions which are static casts. > > Hope this makes sense and is constructive. > Dave > > > > > > Le jeudi 13 mai 2021 à 17:30 -0400, David Malcolm a écrit : > > > On Tue, 2020-11-03 at 17:13 -0500, Antoni Boucher wrote: > > > > I was missing a check in gcc_jit_struct_get_field, I added it > > > > in > > > > this > > > > new patch. > > > > > > > > > > Sorry about the long delay in reviewing this patch. > > > > > > The main high-level points are: > > > - currently the get_*_count functions return "ssize_t" - why? > > > Only > > > unsigned values are meaningful; shouldn't they return "size_t" > > > instead? > > > > > > - the various "lookup by index" functions take "int" i.e. signed, > > > but > > > only >= 0 is meaningful. I think it makes sense to make them > > > take > > > size_t instead. > > > > > > Sorry if we covered that before in the review, it's been a while. > > > > > > Various nitpicks inline below... > > > > > > [...snip...] > > > > > > > diff --git a/gcc/jit/docs/topics/compatibility.rst > > > > b/gcc/jit/docs/topics/compatibility.rst > > > > index 6bfa101ed71..236e5c72d81 100644 > > > > --- a/gcc/jit/docs/topics/compatibility.rst > > > > +++ b/gcc/jit/docs/topics/compatibility.rst > > > > @@ -226,3 +226,44 @@ entrypoints: > > > > > > > > ``LIBGCCJIT_ABI_14`` covers the addition of > > > > :func:`gcc_jit_global_set_initializer` > > > > + > > > > +.. _LIBGCCJIT_ABI_15: > > > > + > > > > +``LIBGCCJIT_ABI_15`` > > > > + > > > > +``LIBGCCJIT_ABI_15`` covers the addition of reflection > > > > functions > > > > via > > > > API > > > > +entrypoints: > > > > > > This needs updating, as I used LIBGCCJIT_ABI_15 for inline asm. > > > > > > [...snip...] > > > > > > > diff --git a/gcc/jit/docs/topics/functions.rst > > > > b/gcc/jit/docs/topics/functions.rst > > > > index eb40d64010e..aa6de87282d 100644 > > > > --- a/gcc/jit/docs/topics/functions.rst > > > > +++ b/gcc/jit/docs/topics/functions.rst > > > > @@ -171,6 +171,16 @@ Functions > > > > underlying string, so it is valid to pass in a pointer to > > > > an > > > > on- > > > > stack > > > > buffer. > > > > > > > > +.. function:: ssize_t \ > > > > + gcc_jit_function_get_param_count > > > > (gcc_jit_function > > > > *func) > > > > + > > > > + Get the number of
Re: [PATCH] libgccjit: Handle truncation and extension for casts [PR 95498]
Here's the patch with the condition removed.
I believe everything is now fixed.
Thanks!
Le jeudi 27 mai 2021 à 18:21 -0400, David Malcolm a écrit :
> On Tue, 2021-05-25 at 20:16 -0400, Antoni Boucher wrote:
> > I updated the patch according to the comments by Tom Tromey.
> >
> > There's one question left about your question regarding
> > C_MAYBE_CONST_EXPR, David:
> >
> > I am not sure if we can get a C_MAYBE_CONST_EXPR from libgccjit,
> > and
> > it
> > indeed seems like it's only created in c-family.
> > However, we do use it in libgccjit here:
> > https://github.com/gcc-mirror/gcc/blob/master/gcc/jit/jit-playback.c#L1180
> >
> > I tried removing the condition `if (TREE_CODE (t_ret) !=
> > C_MAYBE_CONST_EXPR)` and all the tests of libgccjit still pass.
> >
> > That code was copied from here:
> > https://github.com/gcc-mirror/gcc/blob/master/gcc/c/c-convert.c#L175
> > and might not be needed in libgccjit.
> >
> > Should I just remove the condition, then?
>
> I think so.
>
> Thanks
> Dave
>
> >
> > Le jeudi 13 mai 2021 à 19:58 -0400, David Malcolm a écrit :
> > > On Thu, 2021-05-13 at 19:31 -0400, Antoni Boucher wrote:
> > > > Thanks for your answer.
> > > >
> > > > See my answers below:
> > > >
> > > > Le jeudi 13 mai 2021 à 18:13 -0400, David Malcolm a écrit :
> > > > > On Sat, 2021-02-20 at 17:17 -0500, Antoni Boucher via Gcc-
> > > > > patches
> > > > > wrote:
> > > > > > Hi.
> > > > > > Thanks for your feedback!
> > > > > >
> > > > >
> > > > > Sorry about the delay in responding.
> > > > >
> > > > > In the past I was hesitant about adding more cast support to
> > > > > libgccjit
> > > > > since I felt that the user could always just create a union
> > > > > to
> > > > > do
> > > > > the
> > > > > cast. Then I tried actually using the libgccjit API to do
> > > > > this,
> > > > > and
> > > > > realized how much work it adds, so I now think we do want to
> > > > > support
> > > > > casting more types.
> > > > >
> > > > >
> > > > > > See answers below:
> > > > > >
> > > > > > On Sat, Feb 20, 2021 at 11:20:35AM -0700, Tom Tromey wrote:
> > > > > > > > > > > > "Antoni" == Antoni Boucher via Gcc-patches <
> > > > > > > > > > > > gcc-patches@gcc.gnu.org> writes:
> > > > > > >
> > > > > > > Antoni> gcc/jit/
> > > > > > > Antoni> PR target/95498
> > > > > > > Antoni> * jit-playback.c: Add support to handle
> > > > > > > truncation
> > > > > > > and extension
> > > > > > > Antoni> in the convert function.
> > > > > > >
> > > > > > > Antoni> + switch (dst_code)
> > > > > > > Antoni> + {
> > > > > > > Antoni> + case INTEGER_TYPE:
> > > > > > > Antoni> + case ENUMERAL_TYPE:
> > > > > > > Antoni> + t_ret = convert_to_integer (dst_type,
> > > > > > > expr);
> > > > > > > Antoni> + goto maybe_fold;
> > > > > > > Antoni> +
> > > > > > > Antoni> + default:
> > > > > > > Antoni> + gcc_assert
> > > > > > > (gcc::jit::active_playback_ctxt);
> > > > > > > Antoni> + gcc::jit::active_playback_ctxt->add_error
> > > > > > > (NULL,
> > > > > > > "unhandled conversion");
> > > > > > > Antoni> + fprintf (stderr, "input expression:\n");
> > > > > > > Antoni> + debug_tree (expr);
> > > > > > > Antoni> + fprintf (stderr, "requested type:\n");
> > > > > > > Antoni> + debug_tree (dst_type);
> > > > > > > Antoni> + return error_mark_node;
> > > > > > > Antoni> +
> > > > > > > Antoni> + maybe_fold:
> > > > > > > Antoni> + if (TREE_CODE (t_ret) !=
> > > > > > > C_MAYBE_CON
Re: [PATCH] libgccjit: Add support for types used by atomic builtins [PR96066] [PR96067]
Hi.
Here's the new patch with the fixes requested.
Le jeudi 20 mai 2021 à 16:24 -0400, David Malcolm a écrit :
> On Mon, 2021-05-17 at 21:02 -0400, Antoni Boucher via Jit wrote:
> > Hello.
> > This patch fixes the issue with using atomic builtins in libgccjit.
> > Thanks to review it.
>
> [...snip...]
>
> > diff --git a/gcc/jit/jit-recording.c b/gcc/jit/jit-recording.c
> > index 117ff70114c..de876ff9fa6 100644
> > --- a/gcc/jit/jit-recording.c
> > +++ b/gcc/jit/jit-recording.c
> > @@ -2598,8 +2598,18 @@
> > recording::memento_of_get_pointer::accepts_writes_from (type
> > *rtype)
> > return false;
> >
> > /* It's OK to assign to a (const T *) from a (T *). */
> > - return m_other_type->unqualified ()
> > - ->accepts_writes_from (rtype_points_to);
> > + if (m_other_type->unqualified ()
> > + ->accepts_writes_from (rtype_points_to)) {
> > + return true;
> > + }
> > +
> > + /* It's OK to assign to a (volatile const T *) from a (volatile
> > const T *). */
> > + if (m_other_type->unqualified ()->unqualified ()
> > + ->accepts_writes_from (rtype_points_to->unqualified ())) {
> > + return true;
> > + }
>
> Presumably you need this to get the atomic builtins working?
Yes!
>
> If I'm reading the above correctly, the new test doesn't distinguish
> between the 3 different kinds of qualifiers (aligned, volatile, and
> const), it merely tries to strip some of them off.
>
> It's not valid to e.g. assign to a (aligned T *) from a (const T *).
>
> Maybe we need an internal enum to discriminate between different
> subclasses of decorated_type?
Done.
>
>
> > +
> > + return false;
> > }
> >
> > /* Implementation of pure virtual hook
> > recording::memento::replay_into
> > diff --git a/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > b/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > index 4202eb7798b..dfc6596358c 100644
> > --- a/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > +++ b/gcc/testsuite/jit.dg/all-non-failing-tests.h
> > @@ -181,6 +181,13 @@
> > #undef create_code
> > #undef verify_code
> >
> > +/* test-builtin-types.c */
> > +#define create_code create_code_builtin_types
> > +#define verify_code verify_code_builtin_types
> > +#include "test-builtin-types.c"
> > +#undef create_code
> > +#undef verify_code
> > +
> > /* test-hello-world.c */
> > #define create_code create_code_hello_world
> > #define verify_code verify_code_hello_world
>
> As with various other patches, this needs to also add a new entry to
> the "testcases" array making use of the new
> {create|verify}_code_builtin_types functions.
Done.
>
> [...snip...]
>
> Hope this is constructive
> Dave
>
From b1b06887e519ae100cb31888f451f7aa0bc55dbe Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sun, 9 May 2021 20:14:37 -0400
Subject: [PATCH] Add support for types used by atomic builtins [PR96066]
[PR96067]
2021-05-17 Antoni Boucher
gcc/jit/
PR target/PR96066
PR target/PR96067
* jit-builtins.c: Implement missing types for builtins.
* jit-recording.c: Allow sending a volatile const void * as
argument.
* jit-recording.h: New enum decorated_type_variant, new
function type::get_variant, and new field type::m_variant.
gcc/testsuite/
PR target/PR96066
PR target/PR96067
* jit.dg/all-non-failing-tests.h: Add test-builtin-types.c.
* jit.dg/test-builtin-types.c: New test.
---
gcc/jit/jit-builtins.c | 10 ++---
gcc/jit/jit-recording.c | 14 ++-
gcc/jit/jit-recording.h | 31 ---
gcc/testsuite/jit.dg/all-non-failing-tests.h | 12 +-
gcc/testsuite/jit.dg/test-builtin-types.c| 41
5 files changed, 94 insertions(+), 14 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-builtin-types.c
diff --git a/gcc/jit/jit-builtins.c b/gcc/jit/jit-builtins.c
index 1ea96f4e025..c279dd858f9 100644
--- a/gcc/jit/jit-builtins.c
+++ b/gcc/jit/jit-builtins.c
@@ -541,11 +541,11 @@ builtins_manager::make_primitive_type (enum jit_builtin_type type_id)
// case BT_DFLOAT128:
// case BT_VALIST_REF:
// case BT_VALIST_ARG:
-// case BT_I1:
-// case BT_I2:
-// case BT_I4:
-// case BT_I8:
-// case BT_I16:
+case BT_I1: return m_ctxt->get_int_type (1, true);
+case BT_I2: return m_ctxt->get_int_type (2, true);
+case BT_I4: return m_ctxt->get_int_type (4, true);
+case BT_I8: return m_ctxt->get_int_type (8, true);
+case BT_I16: return m_ctxt->get_int_type (16, true);
// case BT_PTR_CONST_STRING:
}
}
diff --git a/gcc/jit/jit-recording.c b/gcc/jit/jit-recording.c
index 117ff70114c..798be57a611 100644
--- a/gcc/jit/jit-recording.c
+++ b/gcc/jit/jit-recording.c
@@ -2598,8 +2598,18 @@ recording::memento_of_get_pointer::accepts_writes_from (type *rtype)
return false;
/* It's OK to assign to a (const T *)
Re: [PATCH] libgccjit: add some reflection functions in the jit C api
@David: PING
As far as I know, the only remaining question is about using `ssize_t`
for the return type of some functions.
Here's why I use this type:
That seemed off to return NULL for the functions returning a
size_t to indicate an error. So I changed it to return -1 (and return
type to ssize_t). Is that the proper way to indicate an error?
Once I know the answer for this error handling question, I'll fix the
types.
Thanks!
Le jeudi 13 mai 2021 à 17:30 -0400, David Malcolm a écrit :
> On Tue, 2020-11-03 at 17:13 -0500, Antoni Boucher wrote:
> > I was missing a check in gcc_jit_struct_get_field, I added it in this
> > new patch.
> >
>
> Sorry about the long delay in reviewing this patch.
>
> The main high-level points are:
> - currently the get_*_count functions return "ssize_t" - why? Only
> unsigned values are meaningful; shouldn't they return "size_t" instead?
>
> - the various "lookup by index" functions take "int" i.e. signed, but
> only >= 0 is meaningful. I think it makes sense to make them take
> size_t instead.
>
> Sorry if we covered that before in the review, it's been a while.
>
> Various nitpicks inline below...
>
> [...snip...]
>
> > diff --git a/gcc/jit/docs/topics/compatibility.rst
> > b/gcc/jit/docs/topics/compatibility.rst
> > index 6bfa101ed71..236e5c72d81 100644
> > --- a/gcc/jit/docs/topics/compatibility.rst
> > +++ b/gcc/jit/docs/topics/compatibility.rst
> > @@ -226,3 +226,44 @@ entrypoints:
> >
> > ``LIBGCCJIT_ABI_14`` covers the addition of
> > :func:`gcc_jit_global_set_initializer`
> > +
> > +.. _LIBGCCJIT_ABI_15:
> > +
> > +``LIBGCCJIT_ABI_15``
> > +
> > +``LIBGCCJIT_ABI_15`` covers the addition of reflection functions via
> > API
> > +entrypoints:
>
> This needs updating, as I used LIBGCCJIT_ABI_15 for inline asm.
>
> [...snip...]
>
> > diff --git a/gcc/jit/docs/topics/functions.rst
> > b/gcc/jit/docs/topics/functions.rst
> > index eb40d64010e..aa6de87282d 100644
> > --- a/gcc/jit/docs/topics/functions.rst
> > +++ b/gcc/jit/docs/topics/functions.rst
> > @@ -171,6 +171,16 @@ Functions
> > underlying string, so it is valid to pass in a pointer to an on-
> > stack
> > buffer.
> >
> > +.. function:: ssize_t \
> > + gcc_jit_function_get_param_count (gcc_jit_function
> > *func)
> > +
> > + Get the number of parameters of the function.
> > +
> > +.. function:: gcc_jit_type \*
> > + gcc_jit_function_get_return_type (gcc_jit_function
> > *func)
> > +
> > + Get the return type of the function.
>
> As noted before, this doesn't yet document all the new entrypoints; I
> think you wanted to hold off until all the details were thrashed out,
> but hopefully we're close.
>
> The documentation for an entrypoint should specify which ABI it was
> added in.
>
> [...snip...]
>
> > +/* Public entrypoint. See description in libgccjit.h.
> > +
> > + After error-checking, the real work is done by the
> > + gcc::jit::recording::type::is_struct method, in
> > + jit-recording.c. */
> > +
> > +gcc_jit_struct *
> > +gcc_jit_type_is_struct (gcc_jit_type *type)
> > +{
> > + RETURN_NULL_IF_FAIL (type, NULL, NULL, "NULL type");
> > + gcc::jit::recording::struct_ *struct_type = type->is_struct ();
> > + return (gcc_jit_struct *)struct_type;
> > +}
> > +
> > +/* Public entrypoint. See description in libgccjit.h.
> > +
> > + After error-checking, the real work is done by the
> > + gcc::jit::recording::vector_type::get_num_units method, in
> > + jit-recording.c. */
> > +
> > +ssize_t
> > +gcc_jit_vector_type_get_num_units (gcc_jit_vector_type *vector_type)
> > +{
> > + RETURN_VAL_IF_FAIL (vector_type, -1, NULL, NULL, "NULL
> > vector_type");
> > + return vector_type->get_num_units ();
> > +}
> > +
> > +/* Public entrypoint. See description in libgccjit.h.
> > +
> > + After error-checking, the real work is done by the
> > + gcc::jit::recording::vector_type::get_element_type method, in
> > + jit-recording.c. */
> > +
> > +gcc_jit_type *
> > +gcc_jit_vector_type_get_element_type (gcc_jit_vector_type
> > *vector_type)
> > +{
> > + RETURN_NULL_IF_FAIL (vector_type, NULL, NULL, "NULL vector_type");
> > + return (gcc_jit_type *)vector_type->get_element_type ();
> > +}
> > +
> > +/* Public entrypoint. See description in libgccjit.h.
> > +
> > + After error-checking, the real work is done by the
> > + gcc::jit::recording::type::unqualified method, in
> > + jit-recording.c. */
> > +
> > +gcc_jit_type *
> > +gcc_jit_type_unqualified (gcc_jit_type *type)
> > +{
> > + RETURN_NULL_IF_FAIL (type, NULL, NULL, "NULL type");
> > +
> > + return (gcc_jit_type *)type->unqualified ();
> > +}
> > +
> > +/* Public entrypoint. See description in libgccjit.h.
> > +
> > + After error-checking, the real work is done by the
> > + gcc::jit::recording::type::dyn_cast_function_type method, in
> > + jit-recording.c. */
> > +
> > +gcc_jit_function_type *
> >
Re: [PATCH] libgccjit: Handle truncation and extension for casts [PR 95498]
I updated the patch according to the comments by Tom Tromey.
There's one question left about your question regarding
C_MAYBE_CONST_EXPR, David:
I am not sure if we can get a C_MAYBE_CONST_EXPR from libgccjit, and it
indeed seems like it's only created in c-family.
However, we do use it in libgccjit here:
https://github.com/gcc-mirror/gcc/blob/master/gcc/jit/jit-playback.c#L1180
I tried removing the condition `if (TREE_CODE (t_ret) !=
C_MAYBE_CONST_EXPR)` and all the tests of libgccjit still pass.
That code was copied from here:
https://github.com/gcc-mirror/gcc/blob/master/gcc/c/c-convert.c#L175
and might not be needed in libgccjit.
Should I just remove the condition, then?
Le jeudi 13 mai 2021 à 19:58 -0400, David Malcolm a écrit :
> On Thu, 2021-05-13 at 19:31 -0400, Antoni Boucher wrote:
> > Thanks for your answer.
> >
> > See my answers below:
> >
> > Le jeudi 13 mai 2021 à 18:13 -0400, David Malcolm a écrit :
> > > On Sat, 2021-02-20 at 17:17 -0500, Antoni Boucher via Gcc-patches
> > > wrote:
> > > > Hi.
> > > > Thanks for your feedback!
> > > >
> > >
> > > Sorry about the delay in responding.
> > >
> > > In the past I was hesitant about adding more cast support to
> > > libgccjit
> > > since I felt that the user could always just create a union to do
> > > the
> > > cast. Then I tried actually using the libgccjit API to do this,
> > > and
> > > realized how much work it adds, so I now think we do want to
> > > support
> > > casting more types.
> > >
> > >
> > > > See answers below:
> > > >
> > > > On Sat, Feb 20, 2021 at 11:20:35AM -0700, Tom Tromey wrote:
> > > > > > > > > > "Antoni" == Antoni Boucher via Gcc-patches <
> > > > > > > > > > gcc-patches@gcc.gnu.org> writes:
> > > > >
> > > > > Antoni> gcc/jit/
> > > > > Antoni> PR target/95498
> > > > > Antoni> * jit-playback.c: Add support to handle
> > > > > truncation
> > > > > and extension
> > > > > Antoni> in the convert function.
> > > > >
> > > > > Antoni> + switch (dst_code)
> > > > > Antoni> + {
> > > > > Antoni> + case INTEGER_TYPE:
> > > > > Antoni> + case ENUMERAL_TYPE:
> > > > > Antoni> + t_ret = convert_to_integer (dst_type, expr);
> > > > > Antoni> + goto maybe_fold;
> > > > > Antoni> +
> > > > > Antoni> + default:
> > > > > Antoni> + gcc_assert (gcc::jit::active_playback_ctxt);
> > > > > Antoni> + gcc::jit::active_playback_ctxt->add_error (NULL,
> > > > > "unhandled conversion");
> > > > > Antoni> + fprintf (stderr, "input expression:\n");
> > > > > Antoni> + debug_tree (expr);
> > > > > Antoni> + fprintf (stderr, "requested type:\n");
> > > > > Antoni> + debug_tree (dst_type);
> > > > > Antoni> + return error_mark_node;
> > > > > Antoni> +
> > > > > Antoni> + maybe_fold:
> > > > > Antoni> + if (TREE_CODE (t_ret) != C_MAYBE_CONST_EXPR)
> > >
> > > Do we even get C_MAYBE_CONST_EXPR in libgccjit? That tree code is
> > > defined in c-family/c-common.def; how can nodes of that kind be
> > > created
> > > outside of the c-family?
> >
> > I am not sure, but that seems like it's only created in c-family
> > indeed.
> > However, we do use it in libgccjit here:
> >
> > https://github.com/gcc-mirror/gcc/blob/master/gcc/jit/jit-playback.c#L1180
> >
> > >
> > > > > Antoni> + t_ret = fold (t_ret);
> > > > > Antoni> + return t_ret;
> > > > >
> > > > > It seems weird to have a single 'goto' to maybe_fold,
> > > > > especially
> > > > > inside
> > > > > a switch like this.
> > > > >
> > > > > If you think the maybe_fold code won't be reused, then it
> > > > > should
> > > > > just
> > > > > be
> > > > > hoisted up and the 'goto' removed.
> > > >
> > > > This actually depends on how the support for cast between
> > > > integers
> > > > and
> > > > pointe
[PATCH] libgccjit: Add function to set the initial value of a global variable [PR96089]
Hi.
I made this patch to set an arbitrary value to a global variable.
This patch suffers from the same issue as inline assembly
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380), i.e. it
segfaults if the `rvalue` is created after the global variable.
It seems to be a design issue so I'm not sure what would be the fix for
it and having it fixed would allow me to test this new function much
more and see if things are missing (i.e. it might require a way to
create a constant struct).
See the link above for an explanation of this issue.
Thanks for the review.
From 0a5fd7f759e1bd7becc993f01bdcf84ff8fc5fd5 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sat, 15 May 2021 10:54:36 -0400
Subject: [PATCH] Add function to set the initial value of a global variable
[PR96089]
2021-05-20 Antoni Boucher
gcc/jit/
PR target/96089
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_19): New ABI
tag.
* docs/topics/expressions.rst: Add documentation for the
function gcc_jit_global_set_initializer_value.
* jit-playback.c: New function (new_global_with_value).
* jit-playback.h: New function (new_global_with_value).
* jit-recording.c: Add support for setting a value to a
global variable.
* jit-recording.h: New function (set_initializer_value) and
new field m_initializer_value.
* libgccjit.c: New macro RETURN_IF_FAIL_PRINTF5 and new
function (gcc_jit_global_set_initializer_value).
* libgccjit.h: New function (gcc_jit_global_set_initializer_value).
* libgccjit.map (LIBGCCJIT_ABI_19): New ABI tag.
gcc/testsuite/
PR target/96089
* jit.dg/test-global-set-initializer.c: Add test for the new
function (gcc_jit_global_set_initializer_value).
---
gcc/jit/docs/topics/compatibility.rst | 9
gcc/jit/docs/topics/expressions.rst | 14 ++
gcc/jit/jit-playback.c| 18
gcc/jit/jit-playback.h| 7 +++
gcc/jit/jit-recording.c | 34 ---
gcc/jit/jit-recording.h | 8
gcc/jit/libgccjit.c | 43 +++
gcc/jit/libgccjit.h | 13 ++
gcc/jit/libgccjit.map | 14 ++
.../jit.dg/test-global-set-initializer.c | 15 +++
10 files changed, 169 insertions(+), 6 deletions(-)
diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst
index 239b6aa1a92..666eb3a1c51 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -243,3 +243,12 @@ embedding assembler instructions:
* :func:`gcc_jit_extended_asm_add_input_operand`
* :func:`gcc_jit_extended_asm_add_clobber`
* :func:`gcc_jit_context_add_top_level_asm`
+
+.. _LIBGCCJIT_ABI_19:
+
+``LIBGCCJIT_ABI_19``
+---
+``LIBGCCJIT_ABI_19`` covers the addition of an API entrypoint to set the value
+of a global variable:
+
+ * :func:`gcc_jit_global_set_initializer_value`
diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst
index 396259ef07e..f638cb68fdd 100644
--- a/gcc/jit/docs/topics/expressions.rst
+++ b/gcc/jit/docs/topics/expressions.rst
@@ -603,6 +603,20 @@ Global variables
#ifdef LIBGCCJIT_HAVE_gcc_jit_global_set_initializer
+.. function:: void
+ gcc_jit_global_set_initializer_value (gcc_jit_lvalue *global,\
+gcc_jit_rvalue *value)
+
+ Set an initializer for ``global`` using the specified value.
+ ``global`` must be the same type as ``value``.
+
+ This entrypoint was added in :ref:`LIBGCCJIT_ABI_19`; you can test for
+ its presence using
+
+ .. code-block:: c
+
+ #ifdef LIBGCCJIT_HAVE_gcc_jit_global_set_initializer_value
+
Working with pointers, structs and unions
-
diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c
index c6136301243..d86701a8ae6 100644
--- a/gcc/jit/jit-playback.c
+++ b/gcc/jit/jit-playback.c
@@ -664,6 +664,24 @@ new_global_initialized (location *loc,
return global_finalize_lvalue (inner);
}
+playback::lvalue *
+playback::context::
+new_global_with_value (location *loc,
+ enum gcc_jit_global_kind kind,
+ type *type,
+ playback::rvalue *value,
+ const char *name)
+{
+ tree inner = global_new_decl (loc, kind, type, name);
+
+ tree inner_type = type->as_tree ();
+ tree initial = value->as_tree ();
+ gcc_assert (TREE_CONSTANT (initial));
+ DECL_INITIAL (inner) = initial;
+
+ return global_finalize_lvalue (inner);
+}
+
/* Implementation of the various
gcc::jit::playback::context::new_rvalue_from_const
methods.
diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
index
[PATCH] libgccjit: Add support for setting the link section of global variables [PR100688]
Hello.
This patch adds support to set the link section of global variables.
I used the ABI 18 because I submitted other patches up to 17.
Thanks for the review.
From c867732ee36003759d479497c85135ecfc4a0cf3 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Wed, 12 May 2021 07:57:54 -0400
Subject: [PATCH] Add support for setting the link section of global variables
[PR100688]
2021-05-19 Antoni Boucher
gcc/jit/
PR target/100688
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_18): New ABI
tag.
* docs/topics/expressions.rst: Add documentation for the
function gcc_jit_lvalue_set_link_section.
* jit-playback.h: New function (set_link_section) and
rvalue::m_inner protected.
* jit-recording.c: New function (set_link_section) and
support for setting the link section.
* jit-recording.h: New function (set_link_section) and new
field m_link_section.
* libgccjit.c: New function (gcc_jit_lvalue_set_link_section).
* libgccjit.h: New function (gcc_jit_lvalue_set_link_section).
* libgccjit.map (LIBGCCJIT_ABI_18): New ABI tag.
gcc/testsuite/
PR target/100688
* jit.dg/all-non-failing-tests.h: Add test-link-section.c.
* jit.dg/test-link_section.c: New test.
---
gcc/jit/docs/topics/compatibility.rst| 9 +++
gcc/jit/docs/topics/expressions.rst | 12 ++
gcc/jit/jit-playback.h | 8 +++
gcc/jit/jit-recording.c | 23 +++---
gcc/jit/jit-recording.h | 7 +-
gcc/jit/libgccjit.c | 12 ++
gcc/jit/libgccjit.h | 13 ++
gcc/jit/libgccjit.map| 11 +
gcc/testsuite/jit.dg/all-non-failing-tests.h | 7 ++
gcc/testsuite/jit.dg/test-link-section.c | 25
10 files changed, 123 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-link-section.c
diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst
index 239b6aa1a92..94e3127f049 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -243,3 +243,12 @@ embedding assembler instructions:
* :func:`gcc_jit_extended_asm_add_input_operand`
* :func:`gcc_jit_extended_asm_add_clobber`
* :func:`gcc_jit_context_add_top_level_asm`
+
+.. _LIBGCCJIT_ABI_18:
+
+``LIBGCCJIT_ABI_18``
+---
+``LIBGCCJIT_ABI_18`` covers the addition of an API entrypoint to set the link
+section of a variable:
+
+ * :func:`gcc_jit_lvalue_set_link_section`
diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst
index 396259ef07e..b39f6c02527 100644
--- a/gcc/jit/docs/topics/expressions.rst
+++ b/gcc/jit/docs/topics/expressions.rst
@@ -539,6 +539,18 @@ where the rvalue is computed by reading from the storage area.
in C.
+.. function:: void
+ gcc_jit_lvalue_set_link_section (gcc_jit_lvalue *lvalue,
+ const char *name)
+
+ Set the link section of a variable; analogous to:
+
+ .. code-block:: c
+
+ int variable __attribute__((section(".section")));
+
+ in C.
+
Global variables
diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
index 825a3e172e9..8b0f65e87e8 100644
--- a/gcc/jit/jit-playback.h
+++ b/gcc/jit/jit-playback.h
@@ -650,6 +650,8 @@ public:
private:
context *m_ctxt;
+
+protected:
tree m_inner;
};
@@ -670,6 +672,12 @@ public:
rvalue *
get_address (location *loc);
+ void
+ set_link_section (const char* name)
+ {
+set_decl_section_name (m_inner, name);
+ }
+
private:
bool mark_addressable (location *loc);
};
diff --git a/gcc/jit/jit-recording.c b/gcc/jit/jit-recording.c
index 117ff70114c..214e6f487fe 100644
--- a/gcc/jit/jit-recording.c
+++ b/gcc/jit/jit-recording.c
@@ -3713,6 +3713,11 @@ recording::lvalue::get_address (recording::location *loc)
return result;
}
+void recording::lvalue::set_link_section (const char *name)
+{
+ m_link_section = new_string (name);
+}
+
/* The implementation of class gcc::jit::recording::param. */
/* Implementation of pure virtual hook recording::memento::replay_into
@@ -4547,8 +4552,7 @@ recording::block::dump_edges_to_dot (pretty_printer *pp)
void
recording::global::replay_into (replayer *r)
{
- set_playback_obj (
-m_initializer
+ playback::lvalue *global = m_initializer
? r->new_global_initialized (playback_location (r, m_loc),
m_kind,
m_type->playback_type (),
@@ -4560,7 +4564,12 @@ recording::global::replay_into (replayer *r)
: r->new_global (playback_location (r, m_loc),
m_kind,
m_type->playback_type (),
- playback_string (m_name)));
+ playback_string (m_name));
+ if
[PATCH] libgccjit: Add support for TLS variable [PR95415]
Hello.
This patch adds support for TLS variables.
One thing to fix before we merge it is the libgccjit.map file which
contains LIBGCCJIT_ABI_16 instead of LIBGCCJIT_ABI_17.
LIBGCCJIT_ABI_16 was added in one of my other patches.
Thanks for the review.
From 6092e3d347972d331ed9ac6cae153168e98ecd0d Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Tue, 11 May 2021 19:23:54 -0400
Subject: [PATCH] Add support for TLS variable [PR95415]
2021-05-18 Antoni Boucher
gcc/jit/
PR target/95415
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_17): New ABI
tag.
* docs/topics/expressions.rst: Add document for the function
gcc_jit_lvalue_set_tls_model.
* jit-playback.h: New function (set_tls_model) and make
rvalue::m_inner public.
* jit-recording.c: New function (set_tls_model), new
variables (tls_models and tls_model_enum_strings) and support
for setting the tls model.
* jit-recording.h: New function (set_tls_model) and new
field m_tls_model.
* libgccjit.c: New function (gcc_jit_lvalue_set_tls_model).
* libgccjit.h: New function (gcc_jit_lvalue_set_tls_model)
and new enum (gcc_jit_tls_model).
* libgccjit.map (LIBGCCJIT_ABI_17): New ABI tag.
gcc/testsuite/
PR target/95415
* jit.dg/all-non-failing-tests.h: Add test-tls.c.
* jit.dg/test-tls.c: New test.
---
gcc/jit/docs/topics/compatibility.rst| 9 +
gcc/jit/docs/topics/expressions.rst | 28 +
gcc/jit/jit-playback.h | 8
gcc/jit/jit-recording.c | 41 ++--
gcc/jit/jit-recording.h | 7 +++-
gcc/jit/libgccjit.c | 18 +
gcc/jit/libgccjit.h | 21 ++
gcc/jit/libgccjit.map| 5 +++
gcc/testsuite/jit.dg/all-non-failing-tests.h | 7
gcc/testsuite/jit.dg/test-tls.c | 29 ++
10 files changed, 169 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-tls.c
diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst
index 239b6aa1a92..d10bc1df080 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -243,3 +243,12 @@ embedding assembler instructions:
* :func:`gcc_jit_extended_asm_add_input_operand`
* :func:`gcc_jit_extended_asm_add_clobber`
* :func:`gcc_jit_context_add_top_level_asm`
+
+.. _LIBGCCJIT_ABI_17:
+
+``LIBGCCJIT_ABI_17``
+---
+``LIBGCCJIT_ABI_17`` covers the addition of an API entrypoint to set the
+thread-local storage model of a variable:
+
+ * :func:`gcc_jit_lvalue_set_tls_model`
diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst
index 396259ef07e..68defd6a311 100644
--- a/gcc/jit/docs/topics/expressions.rst
+++ b/gcc/jit/docs/topics/expressions.rst
@@ -539,6 +539,34 @@ where the rvalue is computed by reading from the storage area.
in C.
+.. function:: void\
+ gcc_jit_lvalue_set_tls_model (gcc_jit_lvalue *lvalue,\
+enum gcc_jit_tls_model model)
+
+ Make a variable a thread-local variable.
+
+ The "model" parameter determines the thread-local storage model of the "lvalue":
+
+ .. type:: enum gcc_jit_tls_model
+
+ .. c:macro:: GCC_JIT_TLS_MODEL_GLOBAL_DYNAMIC
+
+ .. c:macro:: GCC_JIT_TLS_MODEL_LOCAL_DYNAMIC
+
+ .. c:macro:: GCC_JIT_TLS_MODEL_INITIAL_EXEC
+
+ .. c:macro:: GCC_JIT_TLS_MODEL_LOCAL_EXEC
+
+ .. c:macro:: GCC_JIT_TLS_MODEL_DEFAULT
+
+ This is analogous to:
+
+ .. code-block:: c
+
+ _Thread_local int foo;
+
+ in C.
+
Global variables
diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
index 825a3e172e9..654a9c472d4 100644
--- a/gcc/jit/jit-playback.h
+++ b/gcc/jit/jit-playback.h
@@ -650,6 +650,8 @@ public:
private:
context *m_ctxt;
+
+protected:
tree m_inner;
};
@@ -670,6 +672,12 @@ public:
rvalue *
get_address (location *loc);
+ void
+ set_tls_model (enum tls_model tls_model)
+ {
+set_decl_tls_model (m_inner, tls_model);
+ }
+
private:
bool mark_addressable (location *loc);
};
diff --git a/gcc/jit/jit-recording.c b/gcc/jit/jit-recording.c
index 117ff70114c..64f3ae2d8f9 100644
--- a/gcc/jit/jit-recording.c
+++ b/gcc/jit/jit-recording.c
@@ -3713,6 +3713,12 @@ recording::lvalue::get_address (recording::location *loc)
return result;
}
+void
+recording::lvalue::set_tls_model (enum gcc_jit_tls_model model)
+{
+m_tls_model = model;
+}
+
/* The implementation of class gcc::jit::recording::param. */
/* Implementation of pure virtual hook recording::memento::replay_into
@@ -4539,6 +4545,15 @@ recording::block::dump_edges_to_dot (pretty_printer *pp)
# pragma GCC
Re: [PATCH] libgccjit: Add support for sized integer types, including 128-bit integers [PR95325]
I had forgotten to update the documentation. This new patch contains it. Le mardi 18 mai 2021 à 08:23 -0400, Antoni Boucher a écrit : > Hello. > This patch add support for sized integer types. > Maybe it should check whether the size of a byte for the current > platform is 8 bits and do other checks so that they're only available > when it makes sense. > What do you think? > Thanks. From 05d931244a575f3d03d8c7ff409d539e0cc6d154 Mon Sep 17 00:00:00 2001 From: Antoni Boucher Date: Mon, 10 May 2021 19:43:02 -0400 Subject: [PATCH] Add support for sized integer types, including 128-bit integers [PR95325] 2021-05-18 Antoni Boucher gcc/jit/ PR target/95325 * docs/topics/types.rst: Add documentation for the new types GCC_JIT_TYPE_UINT8_T, GCC_JIT_TYPE_UINT16_T, GCC_JIT_TYPE_UINT32_T, GCC_JIT_TYPE_UINT64_T, GCC_JIT_TYPE_UINT128_T, GCC_JIT_TYPE_INT8_T, GCC_JIT_TYPE_INT16_T, GCC_JIT_TYPE_INT32_T, GCC_JIT_TYPE_INT64_T, GCC_JIT_TYPE_INT128_T. * jit-playback.c: Add support for the sized integer types. * jit-recording.c: Add support for the sized integer types. * libgccjit.h (GCC_JIT_TYPE_UINT8_T, GCC_JIT_TYPE_UINT16_T, GCC_JIT_TYPE_UINT32_T, GCC_JIT_TYPE_UINT64_T, GCC_JIT_TYPE_UINT128_T, GCC_JIT_TYPE_INT8_T, GCC_JIT_TYPE_INT16_T, GCC_JIT_TYPE_INT32_T, GCC_JIT_TYPE_INT64_T, GCC_JIT_TYPE_INT128_T): New enum variants for gcc_jit_types. gcc/testsuite/ PR target/95325 * jit.dg/test-types.c: Add tests for sized integer types. --- gcc/jit/docs/topics/types.rst | 10 +++ gcc/jit/jit-playback.c| 21 ++ gcc/jit/jit-recording.c | 73 gcc/jit/libgccjit.h | 11 +++ gcc/testsuite/jit.dg/test-types.c | 111 ++ 5 files changed, 226 insertions(+) diff --git a/gcc/jit/docs/topics/types.rst b/gcc/jit/docs/topics/types.rst index 831f11b679a..68accacca45 100644 --- a/gcc/jit/docs/topics/types.rst +++ b/gcc/jit/docs/topics/types.rst @@ -76,6 +76,16 @@ Standard types :c:data:`GCC_JIT_TYPE_UNSIGNED_LONG`C's ``unsigned long`` :c:data:`GCC_JIT_TYPE_LONG_LONG`C99's ``long long`` (signed) :c:data:`GCC_JIT_TYPE_UNSIGNED_LONG_LONG` C99's ``unsigned long long`` + :c:data:`GCC_JIT_TYPE_UINT8_T` C99's ``uint8_t`` + :c:data:`GCC_JIT_TYPE_UINT16_T` C99's ``uint16_t`` + :c:data:`GCC_JIT_TYPE_UINT32_T` C99's ``uint32_t`` + :c:data:`GCC_JIT_TYPE_UINT64_T` C99's ``uint64_t`` + :c:data:`GCC_JIT_TYPE_UINT128_T`C99's ``__uint128_t`` + :c:data:`GCC_JIT_TYPE_INT8_T` C99's ``int8_t`` + :c:data:`GCC_JIT_TYPE_INT16_T` C99's ``int16_t`` + :c:data:`GCC_JIT_TYPE_INT32_T` C99's ``int32_t`` + :c:data:`GCC_JIT_TYPE_INT64_T` C99's ``int64_t`` + :c:data:`GCC_JIT_TYPE_INT128_T` C99's ``__int128_t`` :c:data:`GCC_JIT_TYPE_FLOAT` :c:data:`GCC_JIT_TYPE_DOUBLE` :c:data:`GCC_JIT_TYPE_LONG_DOUBLE` diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c index c6136301243..40630aa1ab8 100644 --- a/gcc/jit/jit-playback.c +++ b/gcc/jit/jit-playback.c @@ -193,6 +193,27 @@ get_tree_node_for_type (enum gcc_jit_types type_) case GCC_JIT_TYPE_UNSIGNED_INT: return unsigned_type_node; +case GCC_JIT_TYPE_UINT8_T: + return unsigned_intQI_type_node; +case GCC_JIT_TYPE_UINT16_T: + return uint16_type_node; +case GCC_JIT_TYPE_UINT32_T: + return uint32_type_node; +case GCC_JIT_TYPE_UINT64_T: + return uint64_type_node; +case GCC_JIT_TYPE_UINT128_T: + return uint128_type_node; +case GCC_JIT_TYPE_INT8_T: + return intQI_type_node; +case GCC_JIT_TYPE_INT16_T: + return intHI_type_node; +case GCC_JIT_TYPE_INT32_T: + return intSI_type_node; +case GCC_JIT_TYPE_INT64_T: + return intDI_type_node; +case GCC_JIT_TYPE_INT128_T: + return intTI_type_node; + case GCC_JIT_TYPE_LONG: return long_integer_type_node; case GCC_JIT_TYPE_UNSIGNED_LONG: diff --git a/gcc/jit/jit-recording.c b/gcc/jit/jit-recording.c index 117ff70114c..b67ae8bfb78 100644 --- a/gcc/jit/jit-recording.c +++ b/gcc/jit/jit-recording.c @@ -2247,6 +2247,18 @@ recording::memento_of_get_type::get_size () case GCC_JIT_TYPE_UNSIGNED_LONG_LONG: size = LONG_LONG_TYPE_SIZE; break; +case GCC_JIT_TYPE_UINT8_T: +case GCC_JIT_TYPE_UINT16_T: +case GCC_JIT_TYPE_UINT32_T: +case GCC_JIT_TYPE_UINT64_T: +case GCC_JIT_TYPE_UINT128_T: +case GCC_JIT_TYPE_INT8_T: +case GCC_JIT_TYPE_INT16_T: +case GCC_JIT_TYPE_INT32_T: +case GCC_JIT_TYPE_INT64_T: +case GCC_JIT_TYPE_INT128_T: + size = 128; + break; case GCC_JIT_TYPE_FLOAT: size = FLOAT_TYPE_SIZE; break; @@ -2295,6 +2307,16 @@
[PATCH] libgccjit: Add support for sized integer types, including 128-bit integers [PR95325]
Hello. This patch add support for sized integer types. Maybe it should check whether the size of a byte for the current platform is 8 bits and do other checks so that they're only available when it makes sense. What do you think? Thanks. From d194a03fe3f2e8164c39413b79da9c43e236cf37 Mon Sep 17 00:00:00 2001 From: Antoni Boucher Date: Mon, 10 May 2021 19:43:02 -0400 Subject: [PATCH] Add support for sized integer types, including 128-bit integers [PR95325] 2021-05-18 Antoni Boucher gcc/jit/ PR target/95325 * jit-playback.c: Add support for the sized integer types. * jit-recording.c: Add support for the sized integer types. * libgccjit.h (GCC_JIT_TYPE_UINT8_T, GCC_JIT_TYPE_UINT16_T, GCC_JIT_TYPE_UINT32_T, GCC_JIT_TYPE_UINT64_T, GCC_JIT_TYPE_UINT128_T, GCC_JIT_TYPE_INT8_T, GCC_JIT_TYPE_INT16_T, GCC_JIT_TYPE_INT32_T, GCC_JIT_TYPE_INT64_T, GCC_JIT_TYPE_INT128_T): New enum variants for gcc_jit_types. gcc/testsuite/ PR target/95325 * jit.dg/test-types.c: Add tests for sized integer types. --- gcc/jit/jit-playback.c| 21 ++ gcc/jit/jit-recording.c | 73 gcc/jit/libgccjit.h | 11 +++ gcc/testsuite/jit.dg/test-types.c | 111 ++ 4 files changed, 216 insertions(+) diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c index c6136301243..40630aa1ab8 100644 --- a/gcc/jit/jit-playback.c +++ b/gcc/jit/jit-playback.c @@ -193,6 +193,27 @@ get_tree_node_for_type (enum gcc_jit_types type_) case GCC_JIT_TYPE_UNSIGNED_INT: return unsigned_type_node; +case GCC_JIT_TYPE_UINT8_T: + return unsigned_intQI_type_node; +case GCC_JIT_TYPE_UINT16_T: + return uint16_type_node; +case GCC_JIT_TYPE_UINT32_T: + return uint32_type_node; +case GCC_JIT_TYPE_UINT64_T: + return uint64_type_node; +case GCC_JIT_TYPE_UINT128_T: + return uint128_type_node; +case GCC_JIT_TYPE_INT8_T: + return intQI_type_node; +case GCC_JIT_TYPE_INT16_T: + return intHI_type_node; +case GCC_JIT_TYPE_INT32_T: + return intSI_type_node; +case GCC_JIT_TYPE_INT64_T: + return intDI_type_node; +case GCC_JIT_TYPE_INT128_T: + return intTI_type_node; + case GCC_JIT_TYPE_LONG: return long_integer_type_node; case GCC_JIT_TYPE_UNSIGNED_LONG: diff --git a/gcc/jit/jit-recording.c b/gcc/jit/jit-recording.c index 117ff70114c..b67ae8bfb78 100644 --- a/gcc/jit/jit-recording.c +++ b/gcc/jit/jit-recording.c @@ -2247,6 +2247,18 @@ recording::memento_of_get_type::get_size () case GCC_JIT_TYPE_UNSIGNED_LONG_LONG: size = LONG_LONG_TYPE_SIZE; break; +case GCC_JIT_TYPE_UINT8_T: +case GCC_JIT_TYPE_UINT16_T: +case GCC_JIT_TYPE_UINT32_T: +case GCC_JIT_TYPE_UINT64_T: +case GCC_JIT_TYPE_UINT128_T: +case GCC_JIT_TYPE_INT8_T: +case GCC_JIT_TYPE_INT16_T: +case GCC_JIT_TYPE_INT32_T: +case GCC_JIT_TYPE_INT64_T: +case GCC_JIT_TYPE_INT128_T: + size = 128; + break; case GCC_JIT_TYPE_FLOAT: size = FLOAT_TYPE_SIZE; break; @@ -2295,6 +2307,16 @@ recording::memento_of_get_type::dereference () case GCC_JIT_TYPE_UNSIGNED_LONG: case GCC_JIT_TYPE_LONG_LONG: case GCC_JIT_TYPE_UNSIGNED_LONG_LONG: +case GCC_JIT_TYPE_UINT8_T: +case GCC_JIT_TYPE_UINT16_T: +case GCC_JIT_TYPE_UINT32_T: +case GCC_JIT_TYPE_UINT64_T: +case GCC_JIT_TYPE_UINT128_T: +case GCC_JIT_TYPE_INT8_T: +case GCC_JIT_TYPE_INT16_T: +case GCC_JIT_TYPE_INT32_T: +case GCC_JIT_TYPE_INT64_T: +case GCC_JIT_TYPE_INT128_T: case GCC_JIT_TYPE_FLOAT: case GCC_JIT_TYPE_DOUBLE: case GCC_JIT_TYPE_LONG_DOUBLE: @@ -2347,6 +2369,16 @@ recording::memento_of_get_type::is_int () const case GCC_JIT_TYPE_UNSIGNED_LONG: case GCC_JIT_TYPE_LONG_LONG: case GCC_JIT_TYPE_UNSIGNED_LONG_LONG: +case GCC_JIT_TYPE_UINT8_T: +case GCC_JIT_TYPE_UINT16_T: +case GCC_JIT_TYPE_UINT32_T: +case GCC_JIT_TYPE_UINT64_T: +case GCC_JIT_TYPE_UINT128_T: +case GCC_JIT_TYPE_INT8_T: +case GCC_JIT_TYPE_INT16_T: +case GCC_JIT_TYPE_INT32_T: +case GCC_JIT_TYPE_INT64_T: +case GCC_JIT_TYPE_INT128_T: return true; case GCC_JIT_TYPE_FLOAT: @@ -2400,6 +2432,16 @@ recording::memento_of_get_type::is_float () const case GCC_JIT_TYPE_UNSIGNED_LONG: case GCC_JIT_TYPE_LONG_LONG: case GCC_JIT_TYPE_UNSIGNED_LONG_LONG: +case GCC_JIT_TYPE_UINT8_T: +case GCC_JIT_TYPE_UINT16_T: +case GCC_JIT_TYPE_UINT32_T: +case GCC_JIT_TYPE_UINT64_T: +case GCC_JIT_TYPE_UINT128_T: +case GCC_JIT_TYPE_INT8_T: +case GCC_JIT_TYPE_INT16_T: +case GCC_JIT_TYPE_INT32_T: +case GCC_JIT_TYPE_INT64_T: +case GCC_JIT_TYPE_INT128_T: return false; case GCC_JIT_TYPE_FLOAT: @@ -2453,6 +2495,16 @@
[PATCH] libgccjit: Add support for types used by atomic builtins [PR96066] [PR96067]
Hello.
This patch fixes the issue with using atomic builtins in libgccjit.
Thanks to review it.
From 0ce53d373ffba9f3f80a2d2b4e1a7d724ba31b7d Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sun, 9 May 2021 20:14:37 -0400
Subject: [PATCH] Add support for types used by atomic builtins [PR96066]
[PR96067]
2021-05-17 Antoni Boucher
gcc/jit/
PR target/PR96066
PR target/PR96067
* jit-builtins.c: Implement missing types for builtins.
* jit-recording.c:: Allow sending a volatile const void * as
argument.
gcc/testsuite/
PR target/PR96066
PR target/PR96067
* jit.dg/all-non-failing-tests.h: Add test-builtin-types.c.
* jit.dg/test-builtin-types.c
---
gcc/jit/jit-builtins.c | 10 ++---
gcc/jit/jit-recording.c | 14 ++-
gcc/testsuite/jit.dg/all-non-failing-tests.h | 7
gcc/testsuite/jit.dg/test-builtin-types.c| 41
4 files changed, 65 insertions(+), 7 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-builtin-types.c
diff --git a/gcc/jit/jit-builtins.c b/gcc/jit/jit-builtins.c
index 1ea96f4e025..c279dd858f9 100644
--- a/gcc/jit/jit-builtins.c
+++ b/gcc/jit/jit-builtins.c
@@ -541,11 +541,11 @@ builtins_manager::make_primitive_type (enum jit_builtin_type type_id)
// case BT_DFLOAT128:
// case BT_VALIST_REF:
// case BT_VALIST_ARG:
-// case BT_I1:
-// case BT_I2:
-// case BT_I4:
-// case BT_I8:
-// case BT_I16:
+case BT_I1: return m_ctxt->get_int_type (1, true);
+case BT_I2: return m_ctxt->get_int_type (2, true);
+case BT_I4: return m_ctxt->get_int_type (4, true);
+case BT_I8: return m_ctxt->get_int_type (8, true);
+case BT_I16: return m_ctxt->get_int_type (16, true);
// case BT_PTR_CONST_STRING:
}
}
diff --git a/gcc/jit/jit-recording.c b/gcc/jit/jit-recording.c
index 117ff70114c..de876ff9fa6 100644
--- a/gcc/jit/jit-recording.c
+++ b/gcc/jit/jit-recording.c
@@ -2598,8 +2598,18 @@ recording::memento_of_get_pointer::accepts_writes_from (type *rtype)
return false;
/* It's OK to assign to a (const T *) from a (T *). */
- return m_other_type->unqualified ()
-->accepts_writes_from (rtype_points_to);
+ if (m_other_type->unqualified ()
+->accepts_writes_from (rtype_points_to)) {
+ return true;
+ }
+
+ /* It's OK to assign to a (volatile const T *) from a (volatile const T *). */
+ if (m_other_type->unqualified ()->unqualified ()
+->accepts_writes_from (rtype_points_to->unqualified ())) {
+ return true;
+ }
+
+ return false;
}
/* Implementation of pure virtual hook recording::memento::replay_into
diff --git a/gcc/testsuite/jit.dg/all-non-failing-tests.h b/gcc/testsuite/jit.dg/all-non-failing-tests.h
index 4202eb7798b..dfc6596358c 100644
--- a/gcc/testsuite/jit.dg/all-non-failing-tests.h
+++ b/gcc/testsuite/jit.dg/all-non-failing-tests.h
@@ -181,6 +181,13 @@
#undef create_code
#undef verify_code
+/* test-builtin-types.c */
+#define create_code create_code_builtin_types
+#define verify_code verify_code_builtin_types
+#include "test-builtin-types.c"
+#undef create_code
+#undef verify_code
+
/* test-hello-world.c */
#define create_code create_code_hello_world
#define verify_code verify_code_hello_world
diff --git a/gcc/testsuite/jit.dg/test-builtin-types.c b/gcc/testsuite/jit.dg/test-builtin-types.c
new file mode 100644
index 000..e20d71571b5
--- /dev/null
+++ b/gcc/testsuite/jit.dg/test-builtin-types.c
@@ -0,0 +1,41 @@
+#include
+#include
+#include
+#include
+
+#include "libgccjit.h"
+
+#include "harness.h"
+
+void
+create_code (gcc_jit_context *ctxt, void *user_data)
+{
+ CHECK_NON_NULL (gcc_jit_context_get_builtin_function (ctxt, "__atomic_fetch_add_4"));
+
+ gcc_jit_function *atomic_load = gcc_jit_context_get_builtin_function (ctxt, "__atomic_load_8");
+
+ gcc_jit_type *volatile_void_ptr =
+gcc_jit_type_get_volatile(gcc_jit_type_get_const(gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_VOID_PTR)));
+ gcc_jit_type *void_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_VOID);
+ gcc_jit_type *long_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_LONG);
+ gcc_jit_type *int_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_INT);
+ gcc_jit_function *func =
+gcc_jit_context_new_function (ctxt, NULL, GCC_JIT_FUNCTION_EXPORTED, void_type, "atomics", 0, NULL, 0);
+
+ gcc_jit_lvalue *variable = gcc_jit_function_new_local (func, NULL, long_type, "variable");
+ gcc_jit_rvalue *builtin_args[2];
+ gcc_jit_rvalue *param1 = gcc_jit_lvalue_get_address(variable, NULL);
+ builtin_args[0] = gcc_jit_context_new_cast(ctxt, NULL, param1, volatile_void_ptr);
+ builtin_args[1] = gcc_jit_context_new_rvalue_from_long(ctxt, int_type, 0);
+ gcc_jit_context_new_call (ctxt, NULL, atomic_load, 2, builtin_args);
+}
+
+void
+verify_code (gcc_jit_context *ctxt, gcc_jit_result *result)
+{
Re: [PATCH] libgccjit: add some reflection functions in the jit C api
Thanks for your reviews.
I attached the new patch to this email.
See answers below:
Le jeudi 13 mai 2021 à 17:30 -0400, David Malcolm a écrit :
> On Tue, 2020-11-03 at 17:13 -0500, Antoni Boucher wrote:
> > I was missing a check in gcc_jit_struct_get_field, I added it in
> > this
> > new patch.
> >
>
> Sorry about the long delay in reviewing this patch.
>
> The main high-level points are:
> - currently the get_*_count functions return "ssize_t" - why? Only
> unsigned values are meaningful; shouldn't they return "size_t"
> instead?
For those, I had this question in a previous email:
That seemed off to return NULL for the functions returning a
size_t to indicate an error. So I changed it to return -1 (and return
type to ssize_t). Is that the proper way to indicate an error?
Once I know the answer for this error handling question, I'll fix the
types.
> - the various "lookup by index" functions take "int" i.e. signed, but
> only >= 0 is meaningful. I think it makes sense to make them take
> size_t instead.
That's fixed in the new patch.
> Sorry if we covered that before in the review, it's been a while.
>
> Various nitpicks inline below...
>
> [...snip...]
>
> > diff --git a/gcc/jit/docs/topics/compatibility.rst
> > b/gcc/jit/docs/topics/compatibility.rst
> > index 6bfa101ed71..236e5c72d81 100644
> > --- a/gcc/jit/docs/topics/compatibility.rst
> > +++ b/gcc/jit/docs/topics/compatibility.rst
> > @@ -226,3 +226,44 @@ entrypoints:
> >
> > ``LIBGCCJIT_ABI_14`` covers the addition of
> > :func:`gcc_jit_global_set_initializer`
> > +
> > +.. _LIBGCCJIT_ABI_15:
> > +
> > +``LIBGCCJIT_ABI_15``
> > +
> > +``LIBGCCJIT_ABI_15`` covers the addition of reflection functions via
> > API
> > +entrypoints:
>
> This needs updating, as I used LIBGCCJIT_ABI_15 for inline asm.
This was updated for the new patch.
> [...snip...]
>
> > diff --git a/gcc/jit/docs/topics/functions.rst
> > b/gcc/jit/docs/topics/functions.rst
> > index eb40d64010e..aa6de87282d 100644
> > --- a/gcc/jit/docs/topics/functions.rst
> > +++ b/gcc/jit/docs/topics/functions.rst
> > @@ -171,6 +171,16 @@ Functions
> > underlying string, so it is valid to pass in a pointer to an on-
> > stack
> > buffer.
> >
> > +.. function:: ssize_t \
> > + gcc_jit_function_get_param_count (gcc_jit_function
> > *func)
> > +
> > + Get the number of parameters of the function.
> > +
> > +.. function:: gcc_jit_type \*
> > + gcc_jit_function_get_return_type (gcc_jit_function
> > *func)
> > +
> > + Get the return type of the function.
>
> As noted before, this doesn't yet document all the new entrypoints; I
> think you wanted to hold off until all the details were thrashed out,
> but hopefully we're close.
>
> The documentation for an entrypoint should specify which ABI it was
> added in.
The documentation was added in the new patch.
> [...snip...]
>
> > +/* Public entrypoint. See description in libgccjit.h.
> > +
> > + After error-checking, the real work is done by the
> > + gcc::jit::recording::type::is_struct method, in
> > + jit-recording.c. */
> > +
> > +gcc_jit_struct *
> > +gcc_jit_type_is_struct (gcc_jit_type *type)
> > +{
> > + RETURN_NULL_IF_FAIL (type, NULL, NULL, "NULL type");
> > + gcc::jit::recording::struct_ *struct_type = type->is_struct ();
> > + return (gcc_jit_struct *)struct_type;
> > +}
> > +
> > +/* Public entrypoint. See description in libgccjit.h.
> > +
> > + After error-checking, the real work is done by the
> > + gcc::jit::recording::vector_type::get_num_units method, in
> > + jit-recording.c. */
> > +
> > +ssize_t
> > +gcc_jit_vector_type_get_num_units (gcc_jit_vector_type
> > *vector_type)
> > +{
> > + RETURN_VAL_IF_FAIL (vector_type, -1, NULL, NULL, "NULL
> > vector_type");
> > + return vector_type->get_num_units ();
> > +}
> > +
> > +/* Public entrypoint. See description in libgccjit.h.
> > +
> > + After error-checking, the real work is done by the
> > + gcc::jit::recording::vector_type::get_element_type method, in
> > + jit-recording.c. */
> > +
> > +gcc_jit_type *
> > +gcc_jit_vector_type_get_element_type (gcc_jit_vector_type
> > *vector_type)
> > +{
> > + RETURN_NULL_IF_FAIL (vector_type, NULL, NULL, "NULL
> > vector_type");
> > + return (gcc_jit_type *)vector_type->get_element_type ();
> > +}
> > +
> > +/* Public entrypoint. See description in libgccjit.h.
> > +
> > + After error-checking, the real work is done by the
> > + gcc::jit::recording::type::unqualified method, in
> > + jit-recording.c. */
> > +
> > +gcc_jit_type *
> > +gcc_jit_type_unqualified (gcc_jit_type *type)
> > +{
> > + RETURN_NULL_IF_FAIL (type, NULL, NULL, "NULL type");
> > +
> > + return (gcc_jit_type *)type->unqualified ();
> > +}
> > +
> > +/* Public entrypoint. See description in libgccjit.h.
> > +
> > + After error-checking, the real work is done by the
> > + gcc::jit::recording::type::dyn_cast_function_type method, in
Re: [PATCH] libgccjit: Handle truncation and extension for casts [PR 95498]
Thanks for your answer.
See my answers below:
Le jeudi 13 mai 2021 à 18:13 -0400, David Malcolm a écrit :
> On Sat, 2021-02-20 at 17:17 -0500, Antoni Boucher via Gcc-patches
> wrote:
> > Hi.
> > Thanks for your feedback!
> >
>
> Sorry about the delay in responding.
>
> In the past I was hesitant about adding more cast support to libgccjit
> since I felt that the user could always just create a union to do the
> cast. Then I tried actually using the libgccjit API to do this, and
> realized how much work it adds, so I now think we do want to support
> casting more types.
>
>
> > See answers below:
> >
> > On Sat, Feb 20, 2021 at 11:20:35AM -0700, Tom Tromey wrote:
> > > > > > > > "Antoni" == Antoni Boucher via Gcc-patches <
> > > > > > > > gcc-patches@gcc.gnu.org> writes:
> > >
> > > Antoni> gcc/jit/
> > > Antoni> PR target/95498
> > > Antoni> * jit-playback.c: Add support to handle truncation
> > > and extension
> > > Antoni> in the convert function.
> > >
> > > Antoni> + switch (dst_code)
> > > Antoni> + {
> > > Antoni> + case INTEGER_TYPE:
> > > Antoni> + case ENUMERAL_TYPE:
> > > Antoni> + t_ret = convert_to_integer (dst_type, expr);
> > > Antoni> + goto maybe_fold;
> > > Antoni> +
> > > Antoni> + default:
> > > Antoni> + gcc_assert (gcc::jit::active_playback_ctxt);
> > > Antoni> + gcc::jit::active_playback_ctxt->add_error (NULL,
> > > "unhandled conversion");
> > > Antoni> + fprintf (stderr, "input expression:\n");
> > > Antoni> + debug_tree (expr);
> > > Antoni> + fprintf (stderr, "requested type:\n");
> > > Antoni> + debug_tree (dst_type);
> > > Antoni> + return error_mark_node;
> > > Antoni> +
> > > Antoni> + maybe_fold:
> > > Antoni> + if (TREE_CODE (t_ret) != C_MAYBE_CONST_EXPR)
>
> Do we even get C_MAYBE_CONST_EXPR in libgccjit? That tree code is
> defined in c-family/c-common.def; how can nodes of that kind be created
> outside of the c-family?
I am not sure, but that seems like it's only created in c-family
indeed.
However, we do use it in libgccjit here:
https://github.com/gcc-mirror/gcc/blob/master/gcc/jit/jit-playback.c#L1180
>
> > > Antoni> + t_ret = fold (t_ret);
> > > Antoni> + return t_ret;
> > >
> > > It seems weird to have a single 'goto' to maybe_fold, especially
> > > inside
> > > a switch like this.
> > >
> > > If you think the maybe_fold code won't be reused, then it should
> > > just
> > > be
> > > hoisted up and the 'goto' removed.
> >
> > This actually depends on how the support for cast between integers
> > and
> > pointers will be implemented (see below).
> > If we will support truncating pointers (does that even make sense?
> > and
> > I
> > guess we cannot extend a pointer unless we add the support for
> > uint128_t), that label will be reused for that case.
> > Otherwise, it might not be reused.
> >
> > So, please tell me which option to choose and I'll update my patch.
>
> FWIW I don't think we'll want to support truncating or extending
> pointers.
Ok, but do you think we'll want to support casts between integers and
pointers?
I opened an issue about this
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95438) and would be
willing to do a patch for it eventually.
> >
> > > On the other hand, if the maybe_fold code might be reused for some
> > > other
> > > case, then I suppose I would have the case end with 'break' and
> > > then
> > > have this code outside the switch.
> > >
> > >
> > > In another message, you wrote:
> > >
> > > Antoni> For your question, the current code already works with
> > > boolean and
> > > Antoni> reals and casts between integers and pointers is currently
> > > not
> > > Antoni> supported.
> > >
> > > I am curious why this wasn't supported. It seems like something
> > > that
> > > one might want to do.
> >
> > I have no idea as this is my first contribution to gcc.
> > But this would be indeed very useful and I opened an issue about
> > this:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95438
> >
> > > thanks,
> > > Tom
> >
> > Thanks!
> >
>
>
Re: [PATCH] libgccjit: Handle truncation and extension for casts [PR 95498]
Hi.
Thanks for your feedback!
See answers below:
On Sat, Feb 20, 2021 at 11:20:35AM -0700, Tom Tromey wrote:
"Antoni" == Antoni Boucher via Gcc-patches writes:
Antoni> gcc/jit/
Antoni> PR target/95498
Antoni> * jit-playback.c: Add support to handle truncation and extension
Antoni> in the convert function.
Antoni> + switch (dst_code)
Antoni> +{
Antoni> +case INTEGER_TYPE:
Antoni> +case ENUMERAL_TYPE:
Antoni> + t_ret = convert_to_integer (dst_type, expr);
Antoni> + goto maybe_fold;
Antoni> +
Antoni> +default:
Antoni> + gcc_assert (gcc::jit::active_playback_ctxt);
Antoni> + gcc::jit::active_playback_ctxt->add_error (NULL, "unhandled
conversion");
Antoni> + fprintf (stderr, "input expression:\n");
Antoni> + debug_tree (expr);
Antoni> + fprintf (stderr, "requested type:\n");
Antoni> + debug_tree (dst_type);
Antoni> + return error_mark_node;
Antoni> +
Antoni> +maybe_fold:
Antoni> + if (TREE_CODE (t_ret) != C_MAYBE_CONST_EXPR)
Antoni> +t_ret = fold (t_ret);
Antoni> + return t_ret;
It seems weird to have a single 'goto' to maybe_fold, especially inside
a switch like this.
If you think the maybe_fold code won't be reused, then it should just be
hoisted up and the 'goto' removed.
This actually depends on how the support for cast between integers and
pointers will be implemented (see below).
If we will support truncating pointers (does that even make sense? and I
guess we cannot extend a pointer unless we add the support for
uint128_t), that label will be reused for that case.
Otherwise, it might not be reused.
So, please tell me which option to choose and I'll update my patch.
On the other hand, if the maybe_fold code might be reused for some other
case, then I suppose I would have the case end with 'break' and then
have this code outside the switch.
In another message, you wrote:
Antoni> For your question, the current code already works with boolean and
Antoni> reals and casts between integers and pointers is currently not
Antoni> supported.
I am curious why this wasn't supported. It seems like something that
one might want to do.
I have no idea as this is my first contribution to gcc.
But this would be indeed very useful and I opened an issue about this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95438
thanks,
Tom
Thanks!
Re: [PATCH] libgccjit: Handle truncation and extension for casts [PR 95498]
Hi.
I'd like to know what's the status of the review for this patch.
(Same for my other patch 96889: add some reflection functions in the jit
C api)
Thanks.
On Tue, Jul 21, 2020 at 11:29:57PM +0200, Andrea Corallo wrote:
Hi Antoni,
a couple of nits and some thoughts.
Antoni Boucher via Gcc-patches writes:
2020-07-12 Antoni Boucher
gcc/jit/
PR target/95498
* jit-playback.c: Add support to handle truncation and extension
^^^
here we usually add the function that gets
modified, you can look at other changelog entries as example.
diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c
index 0fddf04da87..4f4a1080c36 100644
--- a/gcc/jit/jit-playback.c
+++ b/gcc/jit/jit-playback.c
@@ -61,22 +61,39 @@ along with GCC; see the file COPYING3. If not see
/* gcc::jit::playback::context::build_cast uses the convert.h API,
which in turn requires the frontend to provide a "convert"
- function, apparently as a fallback.
-
- Hence we provide this dummy one, with the requirement that any casts
- are handled before reaching this. */
+ function, apparently as a fallback for casts that can be simplified
+ (truncation, extension). */
extern tree convert (tree type, tree expr);
tree
convert (tree dst_type, tree expr)
{
- gcc_assert (gcc::jit::active_playback_ctxt);
- gcc::jit::active_playback_ctxt->add_error (NULL, "unhandled conversion");
- fprintf (stderr, "input expression:\n");
- debug_tree (expr);
- fprintf (stderr, "requested type:\n");
- debug_tree (dst_type);
- return error_mark_node;
+ tree t_ret = NULL;
+ t_ret = targetm.convert_to_type (dst_type, expr);
+ if (t_ret)
+ return t_ret;
^^^
indent nit
+ enum tree_code dst_code = TREE_CODE (dst_type);
+ switch (dst_code)
+{
+case INTEGER_TYPE:
+case ENUMERAL_TYPE:
+ t_ret = convert_to_integer (dst_type, expr);
+ goto maybe_fold;
+
+default:
+ gcc_assert (gcc::jit::active_playback_ctxt);
+ gcc::jit::active_playback_ctxt->add_error (NULL, "unhandled conversion");
+ fprintf (stderr, "input expression:\n");
+ debug_tree (expr);
+ fprintf (stderr, "requested type:\n");
+ debug_tree (dst_type);
+ return error_mark_node;
+
+maybe_fold:
+ if (TREE_CODE (t_ret) != C_MAYBE_CONST_EXPR)
+ t_ret = fold (t_ret);
+ return t_ret;
+}
}
Looking at 'convert' at c-convert.c:66 the INTEGER_TYPE case here looks
good, but given the set of casts we accept as input I guess we should
handle also POINTER_TYPE, BOOLEAN_TYPE and REAL_TYPE. What do you think
about?
Hope it helps
Bests
Andrea
Re: [PATCH] libgccjit: add some reflection functions in the jit C api
I was missing a check in gcc_jit_struct_get_field, I added it in this
new patch.
On Thu, Oct 15, 2020 at 05:52:33PM -0400, David Malcolm wrote:
On Thu, 2020-10-15 at 13:39 -0400, Antoni Boucher wrote:
Thanks. I updated the patch with these changes.
Thanks for patch; review below. Sorry if it seems excessively nitpicky
in places.
2020-09-1 Antoni Boucher
gcc/jit/
PR target/96889
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_14): New ABI tag.
15 now.
* docs/topics/functions.rst: Add documentation for the
functions gcc_jit_function_get_return_type and
gcc_jit_function_get_param_count
* libgccjit.c: New functions:
* gcc_jit_function_get_return_type;
* gcc_jit_function_get_param_count;
* gcc_jit_function_type_get_return_type;
* gcc_jit_function_type_get_param_count;
* gcc_jit_function_type_get_param_type;
* gcc_jit_type_unqualified;
* gcc_jit_type_is_array;
* gcc_jit_type_is_bool;
* gcc_jit_type_is_function_ptr_type;
* gcc_jit_type_is_int;
* gcc_jit_type_is_pointer;
* gcc_jit_type_is_vector;
* gcc_jit_vector_type_get_element_type;
* gcc_jit_vector_type_get_num_units;
* gcc_jit_struct_get_field;
* gcc_jit_type_is_struct;
* gcc_jit_struct_get_field_count;
This isn't valid ChangeLog format; it will fail the git hooks.
* libgccjit.h
Likewise.
* jit-recording.h: New functions (is_struct and is_vector)
* libgccjit.map (LIBGCCJIT_ABI_14): New ABI tag.
15 now.
gcc/testsuite/
PR target/96889
* jit.dg/all-non-failing-tests.h: Add test-reflection.c.
* jit.dg/test-reflection.c: New test.
[...]
diff --git a/gcc/jit/docs/topics/functions.rst
b/gcc/jit/docs/topics/functions.rst
index eb40d64010e..9819c28cda2 100644
--- a/gcc/jit/docs/topics/functions.rst
+++ b/gcc/jit/docs/topics/functions.rst
@@ -171,6 +171,16 @@ Functions
underlying string, so it is valid to pass in a pointer to an on-stack
buffer.
+.. function:: size_t \
+ gcc_jit_function_get_param_count (gcc_jit_function *func)
+
+ Get the number of parameters of the function.
+
+.. function:: gcc_jit_type \*
+ gcc_jit_function_get_return_type (gcc_jit_function *func)
+
+ Get the return type of the function.
+
The documentation part of the patch is incomplete: it hasn't been
updated to add all the new entrypoints.
Also, the return type of gcc_jit_function_get_param_count is
inconsistent (size_t above, but ssize_t below).
diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
index 30e37aff387..525b8bc921d 100644
--- a/gcc/jit/jit-recording.h
+++ b/gcc/jit/jit-recording.h
@@ -538,7 +538,9 @@ public:
virtual bool is_bool () const = 0;
virtual type *is_pointer () = 0;
virtual type *is_array () = 0;
+ virtual struct_ *is_struct () { return NULL; }
Can't you use dyn_cast_struct for this?
Or is this about looking through decorated_type? e.g. for const and
volatile variants?
I guess my question is, what is the purpose of gcc_jit_type_is_struct?
virtual bool is_void () const { return false; }
+ virtual vector_type *is_vector () { return NULL; }
Likewise, can't you use dyn_cast_vector_type for this?
virtual bool has_known_size () const { return true; }
bool is_numeric () const
@@ -595,6 +597,8 @@ public:
bool is_bool () const FINAL OVERRIDE;
type *is_pointer () FINAL OVERRIDE { return dereference (); }
type *is_array () FINAL OVERRIDE { return NULL; }
+ vector_type *is_vector () FINAL OVERRIDE { return NULL; }
+ struct_ *is_struct () FINAL OVERRIDE { return NULL; }
Likewise, and this is redundant, as it's merely copying the base class
implementation.
bool is_void () const FINAL OVERRIDE { return m_kind == GCC_JIT_TYPE_VOID; }
public:
@@ -629,6 +633,8 @@ public:
bool is_bool () const FINAL OVERRIDE { return false; }
type *is_pointer () FINAL OVERRIDE { return m_other_type; }
type *is_array () FINAL OVERRIDE { return NULL; }
+ vector_type *is_vector () FINAL OVERRIDE { return NULL; }
+ struct_ *is_struct () FINAL OVERRIDE { return NULL; }
Likewise.
@@ -655,6 +661,7 @@ public:
bool is_bool () const FINAL OVERRIDE { return m_other_type->is_bool (); }
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 (); }
Aha: with a decorated type you look through the decoration.
protected:
type *m_other_type;
@@ -737,6 +744,8 @@ public:
void replay_into (replayer *) FINAL OVERRIDE;
+ vector_type *is_vector () FINAL OVERRIDE { return this; }
+
private:
string *
Re: [PATCH] libgccjit: add some reflection functions in the jit C api
Hi.
Thanks for the review. See the comments below.
I attached the updated patch.
On Thu, Oct 15, 2020 at 05:52:33PM -0400, David Malcolm wrote:
On Thu, 2020-10-15 at 13:39 -0400, Antoni Boucher wrote:
Thanks. I updated the patch with these changes.
Thanks for patch; review below. Sorry if it seems excessively nitpicky
in places.
2020-09-1 Antoni Boucher
gcc/jit/
PR target/96889
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_14): New ABI tag.
15 now.
* docs/topics/functions.rst: Add documentation for the
functions gcc_jit_function_get_return_type and
gcc_jit_function_get_param_count
* libgccjit.c: New functions:
* gcc_jit_function_get_return_type;
* gcc_jit_function_get_param_count;
* gcc_jit_function_type_get_return_type;
* gcc_jit_function_type_get_param_count;
* gcc_jit_function_type_get_param_type;
* gcc_jit_type_unqualified;
* gcc_jit_type_is_array;
* gcc_jit_type_is_bool;
* gcc_jit_type_is_function_ptr_type;
* gcc_jit_type_is_int;
* gcc_jit_type_is_pointer;
* gcc_jit_type_is_vector;
* gcc_jit_vector_type_get_element_type;
* gcc_jit_vector_type_get_num_units;
* gcc_jit_struct_get_field;
* gcc_jit_type_is_struct;
* gcc_jit_struct_get_field_count;
This isn't valid ChangeLog format; it will fail the git hooks.
Is there any way to run that locally to check the format automatically?
* libgccjit.h
Likewise.
* jit-recording.h: New functions (is_struct and is_vector)
* libgccjit.map (LIBGCCJIT_ABI_14): New ABI tag.
15 now.
gcc/testsuite/
PR target/96889
* jit.dg/all-non-failing-tests.h: Add test-reflection.c.
* jit.dg/test-reflection.c: New test.
[...]
diff --git a/gcc/jit/docs/topics/functions.rst
b/gcc/jit/docs/topics/functions.rst
index eb40d64010e..9819c28cda2 100644
--- a/gcc/jit/docs/topics/functions.rst
+++ b/gcc/jit/docs/topics/functions.rst
@@ -171,6 +171,16 @@ Functions
underlying string, so it is valid to pass in a pointer to an on-stack
buffer.
+.. function:: size_t \
+ gcc_jit_function_get_param_count (gcc_jit_function *func)
+
+ Get the number of parameters of the function.
+
+.. function:: gcc_jit_type \*
+ gcc_jit_function_get_return_type (gcc_jit_function *func)
+
+ Get the return type of the function.
+
The documentation part of the patch is incomplete: it hasn't been
updated to add all the new entrypoints.
Indeed, I wanted some feedback before I write the documentation. I'll
write it soon.
Also, the return type of gcc_jit_function_get_param_count is
inconsistent (size_t above, but ssize_t below).
diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
index 30e37aff387..525b8bc921d 100644
--- a/gcc/jit/jit-recording.h
+++ b/gcc/jit/jit-recording.h
@@ -538,7 +538,9 @@ public:
virtual bool is_bool () const = 0;
virtual type *is_pointer () = 0;
virtual type *is_array () = 0;
+ virtual struct_ *is_struct () { return NULL; }
Can't you use dyn_cast_struct for this?
We could, but wouldn't that be inconvenient for the user to call
gcc_jit_type_unqualified every time they want to call a function such as
gcc_jit_type_is_struct?
(I don't mind if you prefer to make the call to gcc_jit_type_unqualified
explicit in user code.)
Or is this about looking through decorated_type? e.g. for const and
volatile variants?
I guess my question is, what is the purpose of gcc_jit_type_is_struct?
The purpose is to be able to get information about the fields of the
struct, if the type is a struct.
virtual bool is_void () const { return false; }
+ virtual vector_type *is_vector () { return NULL; }
Likewise, can't you use dyn_cast_vector_type for this?
Same as for is_struct().
virtual bool has_known_size () const { return true; }
bool is_numeric () const
@@ -595,6 +597,8 @@ public:
bool is_bool () const FINAL OVERRIDE;
type *is_pointer () FINAL OVERRIDE { return dereference (); }
type *is_array () FINAL OVERRIDE { return NULL; }
+ vector_type *is_vector () FINAL OVERRIDE { return NULL; }
+ struct_ *is_struct () FINAL OVERRIDE { return NULL; }
Likewise, and this is redundant, as it's merely copying the base class
implementation.
bool is_void () const FINAL OVERRIDE { return m_kind == GCC_JIT_TYPE_VOID; }
public:
@@ -629,6 +633,8 @@ public:
bool is_bool () const FINAL OVERRIDE { return false; }
type *is_pointer () FINAL OVERRIDE { return m_other_type; }
type *is_array () FINAL OVERRIDE { return NULL; }
+ vector_type *is_vector () FINAL OVERRIDE { return NULL; }
+ struct_ *is_struct () FINAL OVERRIDE { return NULL; }
Likewise.
@@ -655,6 +661,7 @@ public:
bool
Re: [PATCH] libgccjit: Handle truncation and extension for casts [PR 95498]
Hi.
Sorry for the long delay.
I attached the updated patch.
For your question, the current code already works with boolean and reals
and casts between integers and pointers is currently not supported.
The tests now pass: I'm assuming I had to clean the build folder or
something to make that work.
David, any more insight about whether this is the good solution for the
problem?
Thanks.
On Tue, Jul 21, 2020 at 11:29:57PM +0200, Andrea Corallo wrote:
Hi Antoni,
a couple of nits and some thoughts.
Antoni Boucher via Gcc-patches writes:
2020-07-12 Antoni Boucher
gcc/jit/
PR target/95498
* jit-playback.c: Add support to handle truncation and extension
^^^
here we usually add the function that gets
modified, you can look at other changelog entries as example.
diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c
index 0fddf04da87..4f4a1080c36 100644
--- a/gcc/jit/jit-playback.c
+++ b/gcc/jit/jit-playback.c
@@ -61,22 +61,39 @@ along with GCC; see the file COPYING3. If not see
/* gcc::jit::playback::context::build_cast uses the convert.h API,
which in turn requires the frontend to provide a "convert"
- function, apparently as a fallback.
-
- Hence we provide this dummy one, with the requirement that any casts
- are handled before reaching this. */
+ function, apparently as a fallback for casts that can be simplified
+ (truncation, extension). */
extern tree convert (tree type, tree expr);
tree
convert (tree dst_type, tree expr)
{
- gcc_assert (gcc::jit::active_playback_ctxt);
- gcc::jit::active_playback_ctxt->add_error (NULL, "unhandled conversion");
- fprintf (stderr, "input expression:\n");
- debug_tree (expr);
- fprintf (stderr, "requested type:\n");
- debug_tree (dst_type);
- return error_mark_node;
+ tree t_ret = NULL;
+ t_ret = targetm.convert_to_type (dst_type, expr);
+ if (t_ret)
+ return t_ret;
^^^
indent nit
+ enum tree_code dst_code = TREE_CODE (dst_type);
+ switch (dst_code)
+{
+case INTEGER_TYPE:
+case ENUMERAL_TYPE:
+ t_ret = convert_to_integer (dst_type, expr);
+ goto maybe_fold;
+
+default:
+ gcc_assert (gcc::jit::active_playback_ctxt);
+ gcc::jit::active_playback_ctxt->add_error (NULL, "unhandled conversion");
+ fprintf (stderr, "input expression:\n");
+ debug_tree (expr);
+ fprintf (stderr, "requested type:\n");
+ debug_tree (dst_type);
+ return error_mark_node;
+
+maybe_fold:
+ if (TREE_CODE (t_ret) != C_MAYBE_CONST_EXPR)
+ t_ret = fold (t_ret);
+ return t_ret;
+}
}
Looking at 'convert' at c-convert.c:66 the INTEGER_TYPE case here looks
good, but given the set of casts we accept as input I guess we should
handle also POINTER_TYPE, BOOLEAN_TYPE and REAL_TYPE. What do you think
about?
Hope it helps
Bests
Andrea
>From 3f42dc30d9276d7b830103479a3b03f5fc9027ec Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sun, 5 Jul 2020 19:07:30 -0400
Subject: [PATCH] This patch handles truncation and extension for casts in jit.
2020-07-12 Antoni Boucher
gcc/jit/
PR target/95498
* jit-playback.c (convert): Add support to handle truncation and
extension in the convert function.
gcc/testsuite/
PR target/95498
* jit.dg/all-non-failing-tests.h: New test.
* jit.dg/test-cast.c: New test.
Signed-off-by: Antoni Boucher
---
gcc/jit/jit-playback.c | 39
gcc/testsuite/jit.dg/all-non-failing-tests.h | 10 +++
gcc/testsuite/jit.dg/test-cast.c | 66
3 files changed, 104 insertions(+), 11 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-cast.c
diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c
index 4fac64dcab7..6cfe0371ec3 100644
--- a/gcc/jit/jit-playback.c
+++ b/gcc/jit/jit-playback.c
@@ -61,22 +61,39 @@ along with GCC; see the file COPYING3. If not see
/* gcc::jit::playback::context::build_cast uses the convert.h API,
which in turn requires the frontend to provide a "convert"
- function, apparently as a fallback.
-
- Hence we provide this dummy one, with the requirement that any casts
- are handled before reaching this. */
+ function, apparently as a fallback for casts that can be simplified
+ (truncation, extension). */
extern tree convert (tree type, tree expr);
tree
convert (tree dst_type, tree expr)
{
- gcc_assert (gcc::jit::active_playback_ctxt);
- gcc::jit::active_playback_ctxt->add_error (NULL, "unhandled conversion");
- fprintf (stderr, "input expression:\n");
- debug_tree (expr);
- fprintf (stderr, "requested type:\n");
- debug_tree (dst_type);
- return error_mark_node;
+ tree t_ret = NULL;
+ t_ret = targetm.convert_to_type (dst_type, expr);
+ if (t_ret)
+ retu
Re: [PATCH] libgccjit: add some reflection functions in the jit C api
Thanks. I updated the patch with these changes.
Is there any tool to automatically check the style?
On Thu, Oct 15, 2020 at 06:23:18PM +0200, Andrea Corallo wrote:
Antoni Boucher via Jit writes:
Hi Antoni,
Just had a quick look, please find some quite minor comments in line.
From b0edc9eb8e8d3ba9e1c6a8d061a8627c0b0cf102 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sat, 1 Aug 2020 17:52:17 -0400
Subject: [PATCH] This patch add some reflection functions in the jit C api
[PR96889]
2020-09-1 Antoni Boucher
gcc/jit/
PR target/96889
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_14): New ABI tag.
* docs/topics/functions.rst: Add documentation for the
functions gcc_jit_function_get_return_type and
gcc_jit_function_get_param_count
* libgccjit.c: New functions:
* gcc_jit_function_get_return_type;
* gcc_jit_function_get_param_count;
* gcc_jit_function_type_get_return_type;
* gcc_jit_function_type_get_param_count;
* gcc_jit_function_type_get_param_type;
* gcc_jit_type_unqualified;
* gcc_jit_type_is_array;
* gcc_jit_type_is_bool;
* gcc_jit_type_is_function_ptr_type;
* gcc_jit_type_is_int;
* gcc_jit_type_is_pointer;
* gcc_jit_type_is_vector;
* gcc_jit_vector_type_get_element_type;
* gcc_jit_vector_type_get_num_units;
* gcc_jit_struct_get_field;
* gcc_jit_type_is_struct;
* gcc_jit_struct_get_field_count;
* libgccjit.h
* jit-recording.h: New functions (is_struct and is_vector)
* libgccjit.map (LIBGCCJIT_ABI_14): New ABI tag.
gcc/testsuite/
PR target/96889
* jit.dg/all-non-failing-tests.h: Add test-reflection.c.
* jit.dg/test-reflection.c: New test.
---
gcc/jit/docs/topics/compatibility.rst| 41 +++
gcc/jit/docs/topics/functions.rst| 10 +
gcc/jit/jit-recording.h | 16 ++
gcc/jit/libgccjit.c | 254 +++
gcc/jit/libgccjit.h | 117 +
gcc/jit/libgccjit.map| 21 ++
gcc/testsuite/jit.dg/all-non-failing-tests.h | 10 +
gcc/testsuite/jit.dg/test-reflection.c | 89 +++
8 files changed, 558 insertions(+)
create mode 100644 gcc/testsuite/jit.dg/test-reflection.c
diff --git a/gcc/jit/docs/topics/compatibility.rst
b/gcc/jit/docs/topics/compatibility.rst
index 6bfa101ed71..16f24d20a75 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -226,3 +226,44 @@ entrypoints:
``LIBGCCJIT_ABI_14`` covers the addition of
:func:`gcc_jit_global_set_initializer`
+
+.. _LIBGCCJIT_ABI_15:
+
+``LIBGCCJIT_ABI_15``
+
+``LIBGCCJIT_ABI_15`` covers the addition of reflection functions via API
+entrypoints:
+
+ * :func:`gcc_jit_function_get_return_type`
+
+ * :func:`gcc_jit_function_get_param_count`
+
+ * :func:`gcc_jit_type_is_array`
+
+ * :func:`gcc_jit_type_is_bool`
+
+ * :func:`gcc_jit_type_is_int`
+
+ * :func:`gcc_jit_type_is_pointer`
+
+ * :func:`gcc_jit_type_is_struct`
+
+ * :func:`gcc_jit_type_is_vector`
+
+ * :func:`gcc_jit_type_unqualified`
+
+ * :func:`gcc_jit_type_is_function_ptr_type`
+
+ * :func:`gcc_jit_function_type_get_return_type`
+
+ * :func:`gcc_jit_function_type_get_param_count`
+
+ * :func:`gcc_jit_function_type_get_param_type`
+
+ * :func:`gcc_jit_vector_type_get_num_units`
+
+ * :func:`gcc_jit_vector_type_get_element_type`
+
+ * :func:`gcc_jit_struct_get_field`
+
+ * :func:`gcc_jit_struct_get_field_count`
diff --git a/gcc/jit/docs/topics/functions.rst
b/gcc/jit/docs/topics/functions.rst
index eb40d64010e..9819c28cda2 100644
--- a/gcc/jit/docs/topics/functions.rst
+++ b/gcc/jit/docs/topics/functions.rst
@@ -171,6 +171,16 @@ Functions
underlying string, so it is valid to pass in a pointer to an on-stack
buffer.
+.. function:: size_t \
+ gcc_jit_function_get_param_count (gcc_jit_function *func)
+
+ Get the number of parameters of the function.
+
+.. function:: gcc_jit_type \*
+ gcc_jit_function_get_return_type (gcc_jit_function *func)
+
+ Get the return type of the function.
+
Blocks
--
.. type:: gcc_jit_block
diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
index 30e37aff387..525b8bc921d 100644
--- a/gcc/jit/jit-recording.h
+++ b/gcc/jit/jit-recording.h
@@ -538,7 +538,9 @@ public:
virtual bool is_bool () const = 0;
virtual type *is_pointer () = 0;
virtual type *is_array () = 0;
+ virtual struct_ *is_struct () { return NULL; }
virtual bool is_void () const { return false; }
+ virtual vector_type *is_vector () { return NULL; }
virtual bool has_known_size () const { return true; }
bool
Re: [PATCH] libgccjit: add some reflection functions in the jit C api
Hi.
I added all the functions I need in this new patch.
Please tell me if that looks good and I'll add documentation for those
functions.
Thanks.
On Fri, Oct 02, 2020 at 04:24:26PM -0400, David Malcolm wrote:
On Fri, 2020-10-02 at 16:17 -0400, David Malcolm wrote:
On Tue, 2020-09-01 at 21:01 -0400, Antoni Boucher via Jit wrote:
> Hello.
> This WIP patch implements new reflection functions in the C API as
> mentioned in bug 96889.
> I'm looking forward for feedbacks on this patch.
> It's WIP because I'll probably add a few more reflection functions.
> Thanks.
Sorry about the belated review, looks like I missed this one.
At a high level, it seems reasonable.
Do you have a copyright assignment in place for GCC contributions?
See https://gcc.gnu.org/contribute.html
[...]
diff --git a/gcc/jit/docs/topics/compatibility.rst
> b/gcc/jit/docs/topics/compatibility.rst
> index bb3387fa583..7e786194ded 100644
> --- a/gcc/jit/docs/topics/compatibility.rst
> +++ b/gcc/jit/docs/topics/compatibility.rst
> @@ -219,3 +219,14 @@ entrypoints:
>* :func:`gcc_jit_version_minor`
>
>* :func:`gcc_jit_version_patchlevel`
> +
> +.. _LIBGCCJIT_ABI_14:
> +
> +``LIBGCCJIT_ABI_14``
> +
> +``LIBGCCJIT_ABI_14`` covers the addition of reflection functions
> via API
> +entrypoints:
> +
> + * :func:`gcc_jit_function_get_return_type`
> +
> + * :func:`gcc_jit_function_get_param_count`
This will now need bumping to 15; 14 covers the addition of
gcc_jit_global_set_initializer.
[...]
> +/* Public entrypoint. See description in libgccjit.h.
> +
> + After error-checking, the real work is done by the
> + gcc::jit::recording::function::get_return_type method, in
> + jit-recording.h. */
> +
> +gcc_jit_type *
> +gcc_jit_function_get_return_type (gcc_jit_function *func)
> +{
This one is missing a:
RETURN_NULL_IF_FAIL (func, NULL, NULL, "NULL function");
> +return (gcc_jit_type *)func->get_return_type ();
> +}
[...]
> diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
> index 1c5a12e9c01..6999ce25ca2 100644
> --- a/gcc/jit/libgccjit.h
> +++ b/gcc/jit/libgccjit.h
[...]
> @@ -1503,6 +1511,22 @@ gcc_jit_version_minor (void);
> extern int
> gcc_jit_version_patchlevel (void);
>
> +#define LIBGCCJIT_HAVE_gcc_jit_function_reflection
> +
> +/* Reflection functions to get the number of parameters and return
> types of
> + a function from the C API.
"return type", is better grammar, I think, given that "function" is
singular.
> +
> + "vec_type" should be a vector type, created using
> gcc_jit_type_get_vector.
This line about "vec_type" seems to be a leftover from a copy
> + This API entrypoint was added in LIBGCCJIT_ABI_14; you can test
> for its
> + presence using
> + #ifdef LIBGCCJIT_HAVE_gcc_jit_function_reflection
Version number will need bumping, as mentioned above.
[...]
> diff --git a/gcc/jit/libgccjit.map b/gcc/jit/libgccjit.map
> index 6137dd4b4b0..b28f81a7a32 100644
> --- a/gcc/jit/libgccjit.map
> +++ b/gcc/jit/libgccjit.map
> @@ -186,4 +186,10 @@ LIBGCCJIT_ABI_13 {
> gcc_jit_version_major;
> gcc_jit_version_minor;
> gcc_jit_version_patchlevel;
> -} LIBGCCJIT_ABI_12;
> \ No newline at end of file
> +} LIBGCCJIT_ABI_12;
> +
> +LIBGCCJIT_ABI_14 {
> + global:
> +gcc_jit_function_get_return_type;
> +gcc_jit_function_get_param_count;
> +} LIBGCCJIT_ABI_13;
Likewise.
[...]
Otherwise looks good to me.
Bonus points for adding C++ bindings (and docs for them), but I don't
know of anyone using the C++ bindings.
Also, please add "PR jit/96889" to the ChangeLog entries, and [PR96889]
to the subject line.
Dave
>From b0edc9eb8e8d3ba9e1c6a8d061a8627c0b0cf102 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sat, 1 Aug 2020 17:52:17 -0400
Subject: [PATCH] This patch add some reflection functions in the jit C api
[PR96889]
2020-09-1 Antoni Boucher
gcc/jit/
PR target/96889
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_14): New ABI tag.
* docs/topics/functions.rst: Add documentation for the
functions gcc_jit_function_get_return_type and
gcc_jit_function_get_param_count
* libgccjit.c: New functions:
* gcc_jit_function_get_return_type;
* gcc_jit_function_get_param_count;
* gcc_jit_function_type_get_return_type;
* gcc_jit_function_type_get_param_count;
* gcc_jit_function_type_get_param_type;
* gcc_jit_type_unqualified;
* gcc_jit_type_is_array;
* gcc_jit_type_is_bool;
* gcc_jit_type_is_function_ptr_type;
* gcc_jit_type_is_int;
* gcc_jit_type_is_pointer;
* gcc_jit_type_is_vector;
* gcc_jit_vector_type_get_element_type;
* gcc_jit_vector_type_get_num_units;
* gcc_jit_struct_get_field;
* gcc_jit_type_is_struct;
*
Re: [PATCH] libgccjit: add some reflection functions in the jit C api [WIP]
By the way, that seemed off to return NULL for the function returning a
size_t to indicate an error. So I changed it to return -1 (and return
type to ssize_t). Is that the proper way to indicate an error?
I also wanted to mention that this patch is still a work-in-progress as
I'm adding a few other functions.
On Fri, Oct 02, 2020 at 04:24:26PM -0400, David Malcolm wrote:
On Fri, 2020-10-02 at 16:17 -0400, David Malcolm wrote:
On Tue, 2020-09-01 at 21:01 -0400, Antoni Boucher via Jit wrote:
> Hello.
> This WIP patch implements new reflection functions in the C API as
> mentioned in bug 96889.
> I'm looking forward for feedbacks on this patch.
> It's WIP because I'll probably add a few more reflection functions.
> Thanks.
Sorry about the belated review, looks like I missed this one.
At a high level, it seems reasonable.
Do you have a copyright assignment in place for GCC contributions?
See https://gcc.gnu.org/contribute.html
[...]
diff --git a/gcc/jit/docs/topics/compatibility.rst
> b/gcc/jit/docs/topics/compatibility.rst
> index bb3387fa583..7e786194ded 100644
> --- a/gcc/jit/docs/topics/compatibility.rst
> +++ b/gcc/jit/docs/topics/compatibility.rst
> @@ -219,3 +219,14 @@ entrypoints:
>* :func:`gcc_jit_version_minor`
>
>* :func:`gcc_jit_version_patchlevel`
> +
> +.. _LIBGCCJIT_ABI_14:
> +
> +``LIBGCCJIT_ABI_14``
> +
> +``LIBGCCJIT_ABI_14`` covers the addition of reflection functions
> via API
> +entrypoints:
> +
> + * :func:`gcc_jit_function_get_return_type`
> +
> + * :func:`gcc_jit_function_get_param_count`
This will now need bumping to 15; 14 covers the addition of
gcc_jit_global_set_initializer.
[...]
> +/* Public entrypoint. See description in libgccjit.h.
> +
> + After error-checking, the real work is done by the
> + gcc::jit::recording::function::get_return_type method, in
> + jit-recording.h. */
> +
> +gcc_jit_type *
> +gcc_jit_function_get_return_type (gcc_jit_function *func)
> +{
This one is missing a:
RETURN_NULL_IF_FAIL (func, NULL, NULL, "NULL function");
> +return (gcc_jit_type *)func->get_return_type ();
> +}
[...]
> diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
> index 1c5a12e9c01..6999ce25ca2 100644
> --- a/gcc/jit/libgccjit.h
> +++ b/gcc/jit/libgccjit.h
[...]
> @@ -1503,6 +1511,22 @@ gcc_jit_version_minor (void);
> extern int
> gcc_jit_version_patchlevel (void);
>
> +#define LIBGCCJIT_HAVE_gcc_jit_function_reflection
> +
> +/* Reflection functions to get the number of parameters and return
> types of
> + a function from the C API.
"return type", is better grammar, I think, given that "function" is
singular.
> +
> + "vec_type" should be a vector type, created using
> gcc_jit_type_get_vector.
This line about "vec_type" seems to be a leftover from a copy
> + This API entrypoint was added in LIBGCCJIT_ABI_14; you can test
> for its
> + presence using
> + #ifdef LIBGCCJIT_HAVE_gcc_jit_function_reflection
Version number will need bumping, as mentioned above.
[...]
> diff --git a/gcc/jit/libgccjit.map b/gcc/jit/libgccjit.map
> index 6137dd4b4b0..b28f81a7a32 100644
> --- a/gcc/jit/libgccjit.map
> +++ b/gcc/jit/libgccjit.map
> @@ -186,4 +186,10 @@ LIBGCCJIT_ABI_13 {
> gcc_jit_version_major;
> gcc_jit_version_minor;
> gcc_jit_version_patchlevel;
> -} LIBGCCJIT_ABI_12;
> \ No newline at end of file
> +} LIBGCCJIT_ABI_12;
> +
> +LIBGCCJIT_ABI_14 {
> + global:
> +gcc_jit_function_get_return_type;
> +gcc_jit_function_get_param_count;
> +} LIBGCCJIT_ABI_13;
Likewise.
[...]
Otherwise looks good to me.
Bonus points for adding C++ bindings (and docs for them), but I don't
know of anyone using the C++ bindings.
Also, please add "PR jit/96889" to the ChangeLog entries, and [PR96889]
to the subject line.
Dave
Re: [PATCH] libgccjit: add some reflection functions in the jit C api [PR96889]
Hi.
Thanks for the review.
I attached the updated patch file.
I don't have a copyright assignment, but I'll look at that.
On Fri, Oct 02, 2020 at 04:24:26PM -0400, David Malcolm wrote:
On Fri, 2020-10-02 at 16:17 -0400, David Malcolm wrote:
On Tue, 2020-09-01 at 21:01 -0400, Antoni Boucher via Jit wrote:
> Hello.
> This WIP patch implements new reflection functions in the C API as
> mentioned in bug 96889.
> I'm looking forward for feedbacks on this patch.
> It's WIP because I'll probably add a few more reflection functions.
> Thanks.
Sorry about the belated review, looks like I missed this one.
At a high level, it seems reasonable.
Do you have a copyright assignment in place for GCC contributions?
See https://gcc.gnu.org/contribute.html
[...]
diff --git a/gcc/jit/docs/topics/compatibility.rst
> b/gcc/jit/docs/topics/compatibility.rst
> index bb3387fa583..7e786194ded 100644
> --- a/gcc/jit/docs/topics/compatibility.rst
> +++ b/gcc/jit/docs/topics/compatibility.rst
> @@ -219,3 +219,14 @@ entrypoints:
>* :func:`gcc_jit_version_minor`
>
>* :func:`gcc_jit_version_patchlevel`
> +
> +.. _LIBGCCJIT_ABI_14:
> +
> +``LIBGCCJIT_ABI_14``
> +
> +``LIBGCCJIT_ABI_14`` covers the addition of reflection functions
> via API
> +entrypoints:
> +
> + * :func:`gcc_jit_function_get_return_type`
> +
> + * :func:`gcc_jit_function_get_param_count`
This will now need bumping to 15; 14 covers the addition of
gcc_jit_global_set_initializer.
[...]
> +/* Public entrypoint. See description in libgccjit.h.
> +
> + After error-checking, the real work is done by the
> + gcc::jit::recording::function::get_return_type method, in
> + jit-recording.h. */
> +
> +gcc_jit_type *
> +gcc_jit_function_get_return_type (gcc_jit_function *func)
> +{
This one is missing a:
RETURN_NULL_IF_FAIL (func, NULL, NULL, "NULL function");
> +return (gcc_jit_type *)func->get_return_type ();
> +}
[...]
> diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
> index 1c5a12e9c01..6999ce25ca2 100644
> --- a/gcc/jit/libgccjit.h
> +++ b/gcc/jit/libgccjit.h
[...]
> @@ -1503,6 +1511,22 @@ gcc_jit_version_minor (void);
> extern int
> gcc_jit_version_patchlevel (void);
>
> +#define LIBGCCJIT_HAVE_gcc_jit_function_reflection
> +
> +/* Reflection functions to get the number of parameters and return
> types of
> + a function from the C API.
"return type", is better grammar, I think, given that "function" is
singular.
> +
> + "vec_type" should be a vector type, created using
> gcc_jit_type_get_vector.
This line about "vec_type" seems to be a leftover from a copy
> + This API entrypoint was added in LIBGCCJIT_ABI_14; you can test
> for its
> + presence using
> + #ifdef LIBGCCJIT_HAVE_gcc_jit_function_reflection
Version number will need bumping, as mentioned above.
[...]
> diff --git a/gcc/jit/libgccjit.map b/gcc/jit/libgccjit.map
> index 6137dd4b4b0..b28f81a7a32 100644
> --- a/gcc/jit/libgccjit.map
> +++ b/gcc/jit/libgccjit.map
> @@ -186,4 +186,10 @@ LIBGCCJIT_ABI_13 {
> gcc_jit_version_major;
> gcc_jit_version_minor;
> gcc_jit_version_patchlevel;
> -} LIBGCCJIT_ABI_12;
> \ No newline at end of file
> +} LIBGCCJIT_ABI_12;
> +
> +LIBGCCJIT_ABI_14 {
> + global:
> +gcc_jit_function_get_return_type;
> +gcc_jit_function_get_param_count;
> +} LIBGCCJIT_ABI_13;
Likewise.
[...]
Otherwise looks good to me.
Bonus points for adding C++ bindings (and docs for them), but I don't
know of anyone using the C++ bindings.
Also, please add "PR jit/96889" to the ChangeLog entries, and [PR96889]
to the subject line.
Dave
>From ef3b7d15622cc50dc4cae62fb7c31aeacc0f1ed9 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sat, 1 Aug 2020 17:52:17 -0400
Subject: [PATCH] This patch add some reflection functions in the jit C api
[PR96889]
2020-09-1 Antoni Boucher
gcc/jit/
PR target/96889
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_14): New ABI tag.
* docs/topics/functions.rst: Add documentation for the
functions gcc_jit_function_get_return_type and
gcc_jit_function_get_param_count
* libgccjit.c (gcc_jit_function_get_param_count and
gcc_jit_function_get_return_type): New functions.
* libgccjit.h
* libgccjit.map (LIBGCCJIT_ABI_14): New ABI tag.
gcc/testsuite/
PR target/96889
* jit.dg/all-non-failing-tests.h: Add test-reflection.c.
* jit.dg/test-reflection.c: New test.
---
gcc/jit/docs/topics/compatibility.rst| 11
gcc/jit/docs/topics/functions.rst| 10 +++
gcc/jit/libgccjit.c | 29
gcc/jit/libgccjit.h | 22 +++
gcc/jit/libgccjit.map| 6
gcc/testsuite/jit.dg/all-non-failing-tests.h | 10 +++
gcc/testsuite/jit.dg/test-reflection.c | 27 ++
7 files changed, 115
[PATCH] libgccjit: add some reflection functions in the jit C api
Hello.
This WIP patch implements new reflection functions in the C API as
mentioned in bug 96889.
I'm looking forward for feedbacks on this patch.
It's WIP because I'll probably add a few more reflection functions.
Thanks.
>From 23ab738c0d9202f6798a38fb4aa15edfcc67d11c Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sat, 1 Aug 2020 17:52:17 -0400
Subject: [PATCH] This patch add some reflection functions in the jit C api.
2020-09-1 Antoni Boucher
gcc/jit/
PR target/96889
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_14): New ABI tag.
* docs/topics/functions.rst: Add documentation for the
functions gcc_jit_function_get_return_type and
gcc_jit_function_get_param_count
* libgccjit.c (gcc_jit_function_get_param_count and
gcc_jit_function_get_return_type): New functions.
* libgccjit.h
* libgccjit.map (LIBGCCJIT_ABI_14): New ABI tag.
gcc/testsuite/
PR target/96889
* jit.dg/all-non-failing-tests.h: Add test-reflection.c.
* jit.dg/test-reflection.c: New test.
---
gcc/jit/docs/topics/compatibility.rst| 11
gcc/jit/docs/topics/functions.rst| 10 +++
gcc/jit/libgccjit.c | 28
gcc/jit/libgccjit.h | 24 +
gcc/jit/libgccjit.map| 8 +-
gcc/testsuite/jit.dg/all-non-failing-tests.h | 10 +++
gcc/testsuite/jit.dg/test-reflection.c | 27 +++
7 files changed, 117 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/jit.dg/test-reflection.c
diff --git a/gcc/jit/docs/topics/compatibility.rst
b/gcc/jit/docs/topics/compatibility.rst
index bb3387fa583..7e786194ded 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -219,3 +219,14 @@ entrypoints:
* :func:`gcc_jit_version_minor`
* :func:`gcc_jit_version_patchlevel`
+
+.. _LIBGCCJIT_ABI_14:
+
+``LIBGCCJIT_ABI_14``
+
+``LIBGCCJIT_ABI_14`` covers the addition of reflection functions via API
+entrypoints:
+
+ * :func:`gcc_jit_function_get_return_type`
+
+ * :func:`gcc_jit_function_get_param_count`
diff --git a/gcc/jit/docs/topics/functions.rst
b/gcc/jit/docs/topics/functions.rst
index eb40d64010e..9819c28cda2 100644
--- a/gcc/jit/docs/topics/functions.rst
+++ b/gcc/jit/docs/topics/functions.rst
@@ -171,6 +171,16 @@ Functions
underlying string, so it is valid to pass in a pointer to an on-stack
buffer.
+.. function:: size_t \
+ gcc_jit_function_get_param_count (gcc_jit_function *func)
+
+ Get the number of parameters of the function.
+
+.. function:: gcc_jit_type \*
+ gcc_jit_function_get_return_type (gcc_jit_function *func)
+
+ Get the return type of the function.
+
Blocks
--
.. type:: gcc_jit_block
diff --git a/gcc/jit/libgccjit.c b/gcc/jit/libgccjit.c
index 50130fbbe00..e3f8dd33665 100644
--- a/gcc/jit/libgccjit.c
+++ b/gcc/jit/libgccjit.c
@@ -1012,6 +1012,34 @@ gcc_jit_function_get_param (gcc_jit_function *func, int
index)
return static_cast (func->get_param (index));
}
+/* Public entrypoint. See description in libgccjit.h.
+
+ After error-checking, the real work is done by the
+ gcc::jit::recording::function::get_params method, in
+ jit-recording.h.
+ */
+
+size_t
+gcc_jit_function_get_param_count (gcc_jit_function *func)
+{
+ RETURN_NULL_IF_FAIL (func, NULL, NULL, "NULL function");
+ gcc::jit::recording::context *ctxt = func->m_ctxt;
+ JIT_LOG_FUNC (ctxt->get_logger ());
+ return func->get_params ().length ();
+}
+
+/* Public entrypoint. See description in libgccjit.h.
+
+ After error-checking, the real work is done by the
+ gcc::jit::recording::function::get_return_type method, in
+ jit-recording.h. */
+
+gcc_jit_type *
+gcc_jit_function_get_return_type (gcc_jit_function *func)
+{
+return (gcc_jit_type *)func->get_return_type ();
+}
+
/* Public entrypoint. See description in libgccjit.h.
After error-checking, the real work is done by the
diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
index 1c5a12e9c01..6999ce25ca2 100644
--- a/gcc/jit/libgccjit.h
+++ b/gcc/jit/libgccjit.h
@@ -740,6 +740,14 @@ gcc_jit_function_as_object (gcc_jit_function *func);
extern gcc_jit_param *
gcc_jit_function_get_param (gcc_jit_function *func, int index);
+/* Get the number of params of a function. */
+extern size_t
+gcc_jit_function_get_param_count (gcc_jit_function *func);
+
+/* Get the return type of a function. */
+extern gcc_jit_type *
+gcc_jit_function_get_return_type (gcc_jit_function *func);
+
/* Emit the function in graphviz format. */
extern void
gcc_jit_function_dump_to_dot (gcc_jit_function *func,
@@ -1503,6 +1511,22 @@ gcc_jit_version_minor (void);
extern int
gcc_jit_version_patchlevel (void);
+#define LIBGCCJIT_HAVE_gcc_jit_function_reflection
+
+/*
[PATCH] libgccjit: Handle truncation and extension for casts [PR 95498]
Hello.
As mentioned in bug 95498, some conversions do not work. After
investigation, it turns out that it's caused by multiple casts on an
expression where it should do a truncation/extension.
I added a testcase, but for some reasons, the tests only pass when ran
via `./testsuite/jit/test-cast.c.exe`, not when ran via `make check-jit
RUNTESTFLAGS="-v -v -v jit.exp=test-cast.c"`.
Furthermore, some other tests failed, but they also fail on master.
Also, I was under the impression that adding `STRIP_TYPE_NOPS (t_expr);`
in `playback::context::build_cast` would be a better fix for this, but
that doesn't fix the issue.
Am I missing something?
It's my first contribution to gcc, so I'd need help for fixing the tests
and also a confirmation that this is the best way to fix this issue.
Thanks.
>From 140333077a4c5f8ce80f7e5716eecc90781594fa Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sun, 5 Jul 2020 19:07:30 -0400
Subject: [PATCH] This patch handles truncation and extension for casts in jit.
2020-07-12 Antoni Boucher
gcc/jit/
PR target/95498
* jit-playback.c: Add support to handle truncation and extension
in the convert function.
gcc/testsuite/
PR target/95498
* jit.dg/all-non-failing-tests.h: New test.
* jit.dg/test-cast.c: New test.
---
gcc/jit/jit-playback.c | 39
gcc/testsuite/jit.dg/all-non-failing-tests.h | 10 +++
gcc/testsuite/jit.dg/test-cast.c | 66
3 files changed, 104 insertions(+), 11 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-cast.c
diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c
index 0fddf04da87..4f4a1080c36 100644
--- a/gcc/jit/jit-playback.c
+++ b/gcc/jit/jit-playback.c
@@ -61,22 +61,39 @@ along with GCC; see the file COPYING3. If not see
/* gcc::jit::playback::context::build_cast uses the convert.h API,
which in turn requires the frontend to provide a "convert"
- function, apparently as a fallback.
-
- Hence we provide this dummy one, with the requirement that any casts
- are handled before reaching this. */
+ function, apparently as a fallback for casts that can be simplified
+ (truncation, extension). */
extern tree convert (tree type, tree expr);
tree
convert (tree dst_type, tree expr)
{
- gcc_assert (gcc::jit::active_playback_ctxt);
- gcc::jit::active_playback_ctxt->add_error (NULL, "unhandled conversion");
- fprintf (stderr, "input expression:\n");
- debug_tree (expr);
- fprintf (stderr, "requested type:\n");
- debug_tree (dst_type);
- return error_mark_node;
+ tree t_ret = NULL;
+ t_ret = targetm.convert_to_type (dst_type, expr);
+ if (t_ret)
+ return t_ret;
+ enum tree_code dst_code = TREE_CODE (dst_type);
+ switch (dst_code)
+{
+case INTEGER_TYPE:
+case ENUMERAL_TYPE:
+ t_ret = convert_to_integer (dst_type, expr);
+ goto maybe_fold;
+
+default:
+ gcc_assert (gcc::jit::active_playback_ctxt);
+ gcc::jit::active_playback_ctxt->add_error (NULL, "unhandled conversion");
+ fprintf (stderr, "input expression:\n");
+ debug_tree (expr);
+ fprintf (stderr, "requested type:\n");
+ debug_tree (dst_type);
+ return error_mark_node;
+
+maybe_fold:
+ if (TREE_CODE (t_ret) != C_MAYBE_CONST_EXPR)
+ t_ret = fold (t_ret);
+ return t_ret;
+}
}
namespace gcc {
diff --git a/gcc/testsuite/jit.dg/all-non-failing-tests.h
b/gcc/testsuite/jit.dg/all-non-failing-tests.h
index 632ab8cfb2e..a1481699b16 100644
--- a/gcc/testsuite/jit.dg/all-non-failing-tests.h
+++ b/gcc/testsuite/jit.dg/all-non-failing-tests.h
@@ -98,6 +98,13 @@
#undef create_code
#undef verify_code
+/* test-cast.c */
+#define create_code create_code_cast
+#define verify_code verify_code_cast
+#include "test-cast.c"
+#undef create_code
+#undef verify_code
+
/* test-compound-assignment.c */
#define create_code create_code_compound_assignment
#define verify_code verify_code_compound_assignment
@@ -354,6 +361,9 @@ const struct testcase testcases[] = {
{"calling_internal_function",
create_code_calling_internal_function,
verify_code_calling_internal_function},
+ {"cast",
+ create_code_cast,
+ verify_code_cast},
{"compound_assignment",
create_code_compound_assignment,
verify_code_compound_assignment},
diff --git a/gcc/testsuite/jit.dg/test-cast.c b/gcc/testsuite/jit.dg/test-cast.c
new file mode 100644
index 000..2b1e385ae40
--- /dev/null
+++ b/gcc/testsuite/jit.dg/test-cast.c
@@ -0,0 +1,66 @@
+#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:
+char
+my_casts (int x)
+{
+ return (char)(long) x;
+}
+ */
+ gcc_jit_type *int_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_INT);
+ gcc_jit_type *long_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_LONG);
