From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1918 invoked by alias); 14 May 2003 16:06:23 -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 1894 invoked from network); 14 May 2003 16:06:22 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 14 May 2003 16:06:22 -0000 Received: from localhost.toronto.redhat.com (tornado.toronto.redhat.com [172.16.14.228]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 400E0800021; Wed, 14 May 2003 12:06:22 -0400 (EDT) Subject: Re: [tree-ssa] RFC: Dropping INDIRECT_REF variables From: Diego Novillo To: "Timothy J. Wood" Cc: "gcc@gcc.gnu.org" In-Reply-To: <2D0876A9-8621-11D7-93E7-000A9567A046@omnigroup.com> References: <2D0876A9-8621-11D7-93E7-000A9567A046@omnigroup.com> Content-Type: text/plain Organization: Red Hat Canada Message-Id: <1052928382.8234.25.camel@frodo.toronto.redhat.com> Mime-Version: 1.0 Date: Wed, 14 May 2003 16:06:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg01414.txt.bz2 On Wed, 2003-05-14 at 11:31, Timothy J. Wood wrote: > On Wednesday, May 14, 2003, at 08:09 AM, Diego Novillo wrote: > > - We disable the ability to treat non-aliased pointer > > dereferences as if they were variables. We would lose the > > ability to do some optimizations like: > > Please forgive me if I'm way off base here, but one example on PPC > that your code snippet reminded me of was int->float conversion. > Actually, it's my fault. I wasn't clear enough. My proposal is to drop support on the base framework, only. INDIRECT_REFs would need to be supported by other passes like SSAPRE. > void convert(int *input, float *output, unsigned int count) > { > while (count--) > *output++ = *input++; > } > > both words of the double on the stack are written on each loop even > though the one 32-bit portion is always the same. This store should be > hoisted outside the loop (in the degenerate case above this can by a > pretty big performance win). I don't have a 3.3 compiler right now, > but on Mac OS X 10.2 (3.1-based): > Well, we never get to this level of detail on trees. The code you quote above is not optimizable at the tree level: foo (input, output, count) { int T.1; float T.2; while (1) { count = count - 1; if (count == 0ffffffff) { goto ; }; T.1 = *input; T.2 = (float)T.1; input = input + 4B; *output = T.2; output = output + 4B }; :; } There's nothing in that loop that could be hoisted out. If we knew the value of 'count' we could probably unroll the loop, but that's about it. It's important to note that there are many details that are not exposed in the tree IL. Essentially, if you have a target specific optimization problem, you won't be able to fix it at the tree level. The optimizations we do on the trees help indirectly, of course. Diego.