public inbox for jit@gcc.gnu.org
 help / color / mirror / Atom feed
From: Joshua Saxby <joshua.a.saxby@gmail.com>
To: jit@gcc.gnu.org
Subject: Digging a bit deeper into JIT's compile internals
Date: Sat, 10 Jun 2023 17:26:23 +0100	[thread overview]
Message-ID: <CALPFi8MfNCOcGdZ131W67XAUTeoWPBdOOQ-w+aqquA6H8-9xvg@mail.gmail.com> (raw)
In-Reply-To: <mailman.10.1686398403.3625244.jit@gcc.gnu.org>

[-- Attachment #1: Type: text/plain, Size: 3174 bytes --]

After following files jit-recording.cc and jit-playback.cc, I think I've
found out where I need to patch JIT to do what I want it to do.

Looks like both compiling to file and memory ultimately rely upon
playback::context::compile() to do the bulk of their work and then override
a postprocess() method to do additional handling pertaining to their
specific task.

If I can find a way to cache or store the intermediate result generated by
compile(), I should then be able to restructure this to have the follow-up
tasks required by both different forms of compilation to be done starting
with this intermediate result.

Anyone see a problem with my approach? I'm hoping it will be possible to
reüse compilation results produced by compile() in this way without it
causing any conflicts...

Regards,
*J.S.*



*My PGP Public Key Identity*

pub   4096R/*B7A947E4* 2016-11-16 [expires: 2025-12-31]
      Key fingerprint = *E2C4 514F F0FA 52D1 896A  B1D6 3D42 BFD9 B7A9 47E4*
uid       Joshua Saxby <joshua.a.saxby+UMvLnvbsOxBHaeiCHvbdunpz@gmail.com>
uid                   Joshua Saxby (saxbophone) <joshua.a.saxby@gmail.com>
sub   4096R/0A445946 2016-11-16 [expires: 2025-12-31]




On Sat, 10 Jun 2023 at 13:00, <jit-request@gcc.gnu.org> wrote:

> Send Jit mailing list submissions to
>         jit@gcc.gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://gcc.gnu.org/mailman/listinfo/jit
> or, via email, send a message with subject or body 'help' to
>         jit-request@gcc.gnu.org
>
> You can reach the person managing the list at
>         jit-owner@gcc.gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Jit digest..."
> Today's Topics:
>
>    1. Modifying the jit compiler API? (Joshua Saxby)
>
>
>
> ---------- Forwarded message ----------
> From: Joshua Saxby <joshua.a.saxby@gmail.com>
> To: jit@gcc.gnu.org
> Cc:
> Bcc:
> Date: Sat, 10 Jun 2023 00:04:43 +0100
> Subject: Modifying the jit compiler API?
> Currently the JIT has two functions allowing you to compile a context
> either to memory or to file.
>
> But what if you want to compile to both? There doesn't seem to be any way
> to do this except by calling both functions separately which I believe will
> effectively be two separate compilations...
>
> Presumably, it should be possible to modify this part of the API to compile
> to some form of intermediate representation of the work that is common to
> both kinds of compilation, and then turn that into code in memory and in
> file, respectively.
>
> Anyone got any pointers for me on where in the code would be the best place
> for me to modify to dupport this? I did take a look in the implementation
> code of JIT sone weeks ago and remember seeing lots of complicated stuff
> regarding recordings and replays that looked relevant...
>
> A slighty simpler alteration I am also interested in making is allowing
> compile to file to compile to a buffer in memory as well as a file (I
> suppose it could be termed "compile to binary"). Maybe I should start with
> that...
>
>

       reply	other threads:[~2023-06-10 16:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.10.1686398403.3625244.jit@gcc.gnu.org>
2023-06-10 16:26 ` Joshua Saxby [this message]
2023-06-10 21:47   ` David Malcolm
2023-06-11 10:24     ` Joshua Saxby
2023-06-11 10:35     ` Rationale for compiling to memory and file Joshua Saxby

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALPFi8MfNCOcGdZ131W67XAUTeoWPBdOOQ-w+aqquA6H8-9xvg@mail.gmail.com \
    --to=joshua.a.saxby@gmail.com \
    --cc=jit@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).