From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112380 invoked by alias); 10 Jul 2015 15:05:06 -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 112359 invoked by uid 89); 10 Jul 2015 15:05:05 -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=-0.6 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham 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: mail-la0-f47.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=2QB9BsWX94OJ7SqwoXNDkTBdysAVT8C03wWEI3LWAjw=; b=D5GhDRsx9kYbWeZlkxABBeLB5aywT888iXocMSYXOSHMNfSGI28Vj/uHyWZR6rrQPW RKW6Df69PZzLvhO/RjBs/ozkONu+sx2wYrFCcqqDxXSbWAvREDoPqHC5DyIDYQfoS2BI w0L6n87aRWIzLTe+D06PkQ7n5FkG0FimmgD9fymB3ZEu7dLXuxdEi+7tz3+GDkvL0bRE g4Ma9y2TRMuUp5R7hBhNwxsHmnhLj4vbzaH1nLQJtBdX4DFaZsg0tKOT/ij7aSIQmbCk mr7FIGYfhEBax7/Wg/hkz2mALWFHfSfVnAyOyS9LiByS6Rsr3ruBDN7efexkC1a4qO5z 5hkw== X-Received: by 10.112.48.68 with SMTP id j4mr19993378lbn.60.1436540701218; Fri, 10 Jul 2015 08:05:01 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1436537517.31573.48.camel@surprise> References: <559EF2F1.6000000@starynkevitch.net> <1436493224.31573.32.camel@surprise> <1436537517.31573.48.camel@surprise> From: Armin Rigo Date: Thu, 01 Jan 2015 00:00:00 -0000 X-Google-Sender-Auth: lRDa1nDtZHN9DbD0q_hLH6zmMv8 Message-ID: Subject: Re: GCC/JIT and precise garbage collection support? To: David Malcolm Cc: Basile Starynkevitch , jit@gcc.gnu.org, GCC Development Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-q3/txt/msg00080.txt.bz2 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. A bient=C3=B4t, Armin.