From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3770 invoked by alias); 13 May 2003 13:57:33 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 3693 invoked from network); 13 May 2003 13:57:32 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 13 May 2003 13:57:32 -0000 Received: from localhost (tornado.toronto.redhat.com [172.16.14.228]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 5C8F2800030; Tue, 13 May 2003 09:57:31 -0400 (EDT) Subject: Re: [tree-ssa] Out of SSA status and issues From: Diego Novillo To: Andrew Macleod Cc: Michael Matz , gcc mailing list In-Reply-To: <1052832579.7945.109.camel@p4> References: <1052829751.27232.220.camel@frodo.toronto.redhat.com> <1052830223.7945.83.camel@p4> <1052831126.27232.241.camel@frodo.toronto.redhat.com> <1052832579.7945.109.camel@p4> Content-Type: text/plain Organization: Red Hat Canada Message-Id: <1052834248.27232.297.camel@frodo.toronto.redhat.com> Mime-Version: 1.0 Date: Tue, 13 May 2003 13:57:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg01303.txt.bz2 On Tue, 2003-05-13 at 09:29, Andrew MacLeod wrote: > > > > 1. foo() > > 2. { > > 3. int *p; > > 4. > > 5. p_1 = malloc(); > > 6. p_4 = malloc(); > > 7. return *(p_1)_3 + 9; > > 8. } > > > > Will the coalescer DTRT here? Yes, it's a silly transformation, but I'm > > wondering if we don't have a bigger problem here. I've been toying with > > Sure, the coalescer will handle this easily. p_1 and p_4 conflict, so > they will get assigned something like: > > p = malloc () > p.33 = malloc() > return *p + 9 > Excellent. > Doesn't make the copy-prop example right tho. > What example? The one I gave with 'p = malloc()' or the one you had with 'T.6'? I already agreed that copyprop in the case of your example code was wrong, *T.6 is aliased, right? In which case, we should never see *T.6 in a real operand. If we do, then we have a bug in get_stmt_operands. > If you take the original case, and use the new format, you'd get: > > # (*T.6_12)_13 = VDEF <(*T.6)_7>; > T.6_12 = T.2_8 + T.5_11; > > # VUSE ; > i_14 = (*T.6_12)_13 <<<--- This is an issue.... > > # (*T.6_12)_22 = VDEF <(*T.6_12)_13> > # VUSE > *T.6_12 = 30; > }; > # i_1 = PHI ; > Wait. The above is wrong. On some statements you have *T.6 in VDEF operands, and in 'i_14 = (*T.6_12)_13' you have it as a real operand. Did we really rename the program like that? Is *T.6 aliased? If so, then we have a different problem. Aliased references should always be voperands. Now, let's assume for a minute that the code above didn't use pointers. I'll replace uses of *T.6 with J: i_14 = J_13; J_12 = 30; }; # i_1 = PHI ; The above transformation should be OK, right? The point I've been trying to convey is that if we now changed J for an UNALIASED pointer dereference '*p', then the trasnformation should also be valid: i_14 = *(p_3)_13; *(p_3)_14 = 30; }; # i_1 = PHI ; The copies that the coalescer must insert are exactly the same, right? It needs to create a temporary to hold the value of *(p_3)_13. We know that we are referencing the same memory location p_3 and that memory location is not aliased, because all references to *p appear as real operands. What am I missing? I agree that we should not do this for performance reasons. I'm merely trying to figure out if treating INDIRECT_REFs as first-class variables is doable as I think it is. It would certainly be easier for me to punt and treat them as regular expressions and let SSAPRE deal with them. > I don't think it should have the _13. And of course, the VUSE shouldn't > be there since T.6_12 is now a real use. In fact, the aliased variable > should be a VUSE... so I think it ought to look like: > > # VUSE <(*T.6_12)_13> > i_14 = *T.6_12 > Yes. I'm surprised it doesn't. Send me a test case? Diego.