From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26386 invoked by alias); 12 Apr 2011 17:25:59 -0000 Received: (qmail 26353 invoked by uid 22791); 12 Apr 2011 17:25:57 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RFC_ABUSE_POST,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from qmta10.emeryville.ca.mail.comcast.net (HELO qmta10.emeryville.ca.mail.comcast.net) (76.96.30.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Apr 2011 17:25:51 +0000 Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta10.emeryville.ca.mail.comcast.net with comcast id WgwA1g0021eYJf8AAhRrbP; Tue, 12 Apr 2011 17:25:51 +0000 Received: from up.mrs.kithrup.com ([24.4.193.8]) by omta19.emeryville.ca.mail.comcast.net with comcast id WhRp1g00n0BKwT401hRq1H; Tue, 12 Apr 2011 17:25:50 +0000 Subject: Re: [gc-improv] Permanent vs function RTL obstack fix Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mike Stump In-Reply-To: Date: Tue, 12 Apr 2011 17:25:00 -0000 Cc: Jeff Law , Steven Bosscher , gcc-patches@gcc.gnu.org, Richard Guenther Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D9D56F4.3050203@gmail.com> <4D9F1D63.9010509@redhat.com> <4DA35F98.9060304@redhat.com> To: Laurynas Biveinis X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-04/txt/msg00911.txt.bz2 On Apr 12, 2011, at 4:46 AM, Laurynas Biveinis wrote: >> So what's the plan for the case where you need to change the lifetime of >> an object? >=20 > Copying it. Frankly at the moment I don't how much trouble does deep > copying from scratch to function entails, The code to copy isn't too hard and if fairly simple to understand, test an= d do. Roughly, you just need to understand how deep you have to copy, part= of this is ensuring you iterator over all the pointers in the objects that= might point to the shorter lifetime. The problems of the past would be, all the other folks that have live point= ers into anything which is copied. You have the first pointer and that is = trivial to change, but all the other pointers could be problematic. Some o= f the problems were when some of the pointers pointed to the new and some o= f the pointers pointed to the old, then, for all the data hanging off those= data structures that were supposed to be single pieces of data, there were= now two copies of that data. Imagine if you had two TREE_ASM_WRITTENs for= a `single' decl. RTL is vastly simpler than a _DECL node. For just gener= ated RTL (combine temp rtl building), I would not expect any problems. Lik= ewise scratch to function, those should be easy enough. Harder are functio= n to anything longer, say, permanent.