From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118634 invoked by alias); 10 Jul 2015 18:34:50 -0000 Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: jit-owner@gcc.gnu.org Received: (qmail 118608 invoked by uid 89); 10 Jul 2015 18:34:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.98.7 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Message-ID: <55A01062.8000301@redhat.com> Date: Thu, 01 Jan 2015 00:00:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Armin Rigo , David Malcolm CC: Basile Starynkevitch , jit@gcc.gnu.org, GCC Development Subject: Re: GCC/JIT and precise garbage collection support? References: <559EF2F1.6000000@starynkevitch.net> <1436493224.31573.32.camel@surprise> <1436537517.31573.48.camel@surprise> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-SW-Source: 2015-q3/txt/msg00082.txt.bz2 On 07/10/2015 09:04 AM, Armin Rigo wrote: > Hi David, > > On 10 July 2015 at 16:11, David Malcolm 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. I wonder how much overlap there is between this need and what we're going to need to do for resumable functions which are being discussed in the ISO C++ standards meetings. jeff