public inbox for jit@gcc.gnu.org
 help / color / mirror / Atom feed
From: Armin Rigo <arigo@tunes.org>
To: David Malcolm <dmalcolm@redhat.com>
Cc: Basile Starynkevitch <basile@starynkevitch.net>,
	jit@gcc.gnu.org,  GCC Development <gcc@gcc.gnu.org>
Subject: Re: GCC/JIT and precise garbage collection support?
Date: Thu, 01 Jan 2015 00:00:00 -0000	[thread overview]
Message-ID: <CAMSv6X3kfoydJAJ1AJXvcDqCaLrSFGp4a=Cqsqxo==iqP1Tj=w@mail.gmail.com> (raw)
In-Reply-To: <1436537517.31573.48.camel@surprise>

Hi David,

On 10 July 2015 at 16:11, David Malcolm <dmalcolm@redhat.com> wrote:
> AIUI, we have CALL_INSN instructions all the way through the RTL phase
> of the backend, so we can identify which locations in the generated code
> are calls; presumably we'd need at each CALL_INSN to determine somehow
> which RTL expressions tagged as being GC-aware are live (perhaps a
> mixture of registers and fp-offset expressions?)
>
> So presumably we could use that information (maybe in the final pass) to
> write out some metadata describing for each %pc callsite the relevant GC
> roots.
>
> Armin: does this sound like what you need?

Not quite.  I can understand that you're trying to find some solution
with automatic discovery of the live variables of a "GC pointer" type
and so on.  This is more than we need, and if
we had that, then we'd need to work harder to remove the extra stuff.
We only want the end result: attach to each CALL_INSN a list of
variables which should be stored in the stack map for that call, and
be ready to see these locations be modified from outside across the
call if a GC occurs.


A bientôt,

Armin.

  reply	other threads:[~2015-07-10 15:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-01  0:00 Basile Starynkevitch
2015-01-01  0:00 ` Andrew Haley
2015-01-01  0:00 ` David Malcolm
2015-01-01  0:00   ` Armin Rigo
2015-01-01  0:00     ` David Malcolm
2015-01-01  0:00       ` Armin Rigo [this message]
2015-01-01  0:00         ` Jeff Law
2015-01-01  0:00           ` Andrew Haley
2015-01-01  0:00           ` Trevor Saunders

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='CAMSv6X3kfoydJAJ1AJXvcDqCaLrSFGp4a=Cqsqxo==iqP1Tj=w@mail.gmail.com' \
    --to=arigo@tunes.org \
    --cc=basile@starynkevitch.net \
    --cc=dmalcolm@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --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).