This is the mail archive of the
mailing list for the GCC project.
Re: GCC/JIT and precise garbage collection support?
- From: Armin Rigo <arigo at tunes dot org>
- To: David Malcolm <dmalcolm at redhat dot com>
- Cc: Basile Starynkevitch <basile at starynkevitch dot net>, jit at gcc dot gnu dot org, GCC Development <gcc at gcc dot gnu dot org>
- Date: Fri, 10 Jul 2015 17:04:21 +0200
- Subject: Re: GCC/JIT and precise garbage collection support?
- Authentication-results: sourceware.org; auth=none
- References: <559EF2F1 dot 6000000 at starynkevitch dot net> <1436493224 dot 31573 dot 32 dot camel at surprise> <CAMSv6X2XjYZ5Q_zUEDY0-Tt_EAuow9WC7sO7Kh5PSk0xKheWGg at mail dot gmail dot com> <1436537517 dot 31573 dot 48 dot camel at surprise>
On 10 July 2015 at 16:11, David Malcolm <email@example.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
> 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.