public inbox for jit@gcc.gnu.org
 help / color / mirror / Atom feed
* rustc_codegen_gcc and libgccjit for GCC 12 ?
@ 2022-04-08 19:36 David Malcolm
  2022-04-08 20:37 ` Antoni Boucher
  2022-04-11  6:00 ` Richard Biener
  0 siblings, 2 replies; 5+ messages in thread
From: David Malcolm @ 2022-04-08 19:36 UTC (permalink / raw)
  To: Antoni Boucher, gcc-patches, jit, Richard Biener, jakub

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.


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.

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?


[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).


Hope the above makes sense; sorry again for not getting to these
patches sooner.

Dave



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: rustc_codegen_gcc and libgccjit for GCC 12 ?
  2022-04-08 19:36 rustc_codegen_gcc and libgccjit for GCC 12 ? David Malcolm
@ 2022-04-08 20:37 ` Antoni Boucher
  2022-04-11 23:56   ` David Malcolm
  2022-04-11  6:00 ` Richard Biener
  1 sibling, 1 reply; 5+ messages in thread
From: Antoni Boucher @ 2022-04-08 20:37 UTC (permalink / raw)
  To: David Malcolm, gcc-patches, jit, Richard Biener, jakub

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 sooner.
> 
> Dave
> 
> 


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: rustc_codegen_gcc and libgccjit for GCC 12 ?
  2022-04-08 19:36 rustc_codegen_gcc and libgccjit for GCC 12 ? David Malcolm
  2022-04-08 20:37 ` Antoni Boucher
@ 2022-04-11  6:00 ` Richard Biener
  1 sibling, 0 replies; 5+ messages in thread
From: Richard Biener @ 2022-04-11  6:00 UTC (permalink / raw)
  To: David Malcolm; +Cc: Antoni Boucher, gcc-patches, jit, jakub

On Fri, 8 Apr 2022, 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.
> 
> 
> 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.

libgccjit isn't release critical apart from build breaking things,
so I'm fine with pushing extra improvements there.  If needed we'll
revert build breakers, possibly leaving the thing in some weird state.

Richard.

> 
> 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.
> 
> 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?
> 
> 
> [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).
> 
> 
> Hope the above makes sense; sorry again for not getting to these
> patches sooner.
> 
> Dave
> 
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: rustc_codegen_gcc and libgccjit for GCC 12 ?
  2022-04-08 20:37 ` Antoni Boucher
@ 2022-04-11 23:56   ` David Malcolm
  2022-04-12 21:59     ` David Malcolm
  0 siblings, 1 reply; 5+ messages in thread
From: David Malcolm @ 2022-04-11 23:56 UTC (permalink / raw)
  To: Antoni Boucher, gcc-patches, jit, Richard Biener, jakub

On Fri, 2022-04-08 at 16:37 -0400, Antoni Boucher wrote:
> On Fri, 2022-04-08 at 15:36 -0400, David Malcolm wrote:

[...snip...]

> 
> 

> > 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!

Thanks.

I've been working through them today, fixing things up so they commit
cleanly, and fixing a few more nits, but it's clear I'm not going to be
done tonight.

I hope to push the 5 jit patches to trunk for GCC 12 tomorrow (assuming
my tests pass).

Dave
> 


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: rustc_codegen_gcc and libgccjit for GCC 12 ?
  2022-04-11 23:56   ` David Malcolm
@ 2022-04-12 21:59     ` David Malcolm
  0 siblings, 0 replies; 5+ messages in thread
From: David Malcolm @ 2022-04-12 21:59 UTC (permalink / raw)
  To: Antoni Boucher, gcc-patches, jit, Richard Biener, jakub

On Mon, 2022-04-11 at 19:56 -0400, David Malcolm wrote:
> On Fri, 2022-04-08 at 16:37 -0400, Antoni Boucher wrote:
> > On Fri, 2022-04-08 at 15:36 -0400, David Malcolm wrote:
> 
> [...snip...]
> 
> > 
> > 
> 
> > > 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!
> 
> Thanks.
> 
> I've been working through them today, fixing things up so they commit
> cleanly, and fixing a few more nits, but it's clear I'm not going to
> be
> done tonight.
> 
> I hope to push the 5 jit patches to trunk for GCC 12 tomorrow
> (assuming
> my tests pass).

I've now pushed the 5 jit patches to trunk for GCC 12, as 
  r12-8116-gaf80ea97b61847
through:
  r12-8120-g6e5ad1cc24a315
after successful bootstrap and regression testing on x86_64-pc-linux-
gnu; see various other recent mails to the gcc-patches/jit mailing
lists for the details of the specific patches.

Hopefully that's everything that will be needed for gcc 12 for a
version of rustc_codegen_gcc to be able to use upstream gcc 12
libgccjit (and that I didn't break anything).

I'm working on a wwwdocs patch for the GCC 12 release notes (for these
libgccjit API extensions).

Thanks again for all the patches
Dave


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-04-12 21:59 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-08 19:36 rustc_codegen_gcc and libgccjit for GCC 12 ? David Malcolm
2022-04-08 20:37 ` Antoni Boucher
2022-04-11 23:56   ` David Malcolm
2022-04-12 21:59     ` David Malcolm
2022-04-11  6:00 ` Richard Biener

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).