From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18523 invoked by alias); 17 May 2003 17:09:16 -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 18468 invoked from network); 17 May 2003 17:09:15 -0000 Received: from unknown (HELO mail.goquest.com) (12.18.108.6) by sources.redhat.com with SMTP; 17 May 2003 17:09:15 -0000 Received: (qmail 13235 invoked by uid 0); 17 May 2003 17:09:07 -0000 Received: from mszick@goquest.com by mail.goquest.com by uid 502 with qmail-scanner-1.15 (spamassassin: 2.31. Clear:. Processed in 1.059571 secs); 17 May 2003 17:09:07 -0000 Received: from unknown (HELO wolf686) (66.90.217.95) by mail.goquest.com with SMTP; 17 May 2003 17:09:06 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Michael S. Zick To: kenner@vlsi1.ultra.nyu.edu (Richard Kenner), mszick@goquest.com Subject: Re: [tree-ssa] Out of SSA status and issues Date: Sat, 17 May 2003 17:19:00 -0000 Cc: gcc@gcc.gnu.org References: <10305131528.AA14941@vlsi1.ultra.nyu.edu> In-Reply-To: <10305131528.AA14941@vlsi1.ultra.nyu.edu> MIME-Version: 1.0 Message-Id: <03051712013700.00962@wolf686> Content-Transfer-Encoding: 8bit X-SW-Source: 2003-05/txt/msg01661.txt.bz2 On Tuesday 13 May 2003 10:28 am, Richard Kenner wrote: > Consider instead that '*p' is just the name given a register's > contents. Neither 'i' nor '9' are processor internal. Both are > external to the cpu. The memory reference for 'i' is source code > implicit, the memory reference for '*p' is source code explicit. > > True, but given caching effects, it's hard to see how *p could be less > expensive than 'i'. Six of one and half a dozen of the other. Its a Union. I am using "Union" in the general sense of either the union of two or more data structures OR two or more code structures. In this usage of "Union", an assignment statement is a "Union" - including the assignment of a function result. Our terminology and viewpoint differ, but we are talking about the same thing. As to the subject of this thread, a link you may find interesting: Not for the specialization of "C" that the compiler processes, but for the compiler options that allow it to be stopped and dump its internals. Clipped from the help menu: OPTIMIZATION OPTIONS: -ssa use optimizations based on ssa-form. -no disable optimization technique -do enable optimization technique The following optimization techniques are currently supported: CF constant folding INL function inlining LUR loop unrolling WLUR with-loop unrolling LUS loop unswitching DCR dead code removal DFR dead function removal LIR loop invariant removal CSE common subexpression elimination WLT with-loop transformation WLF with-loop folding DLAW application of the distributive law IVE index vector elimination AE array elimination RCO refcount optimization UIP update-in-place AP array padding APL array placement TSI tile size inference (blocking) TSP tile size pragmas (blocking) MTO multi-thread optimization SBE syncronisation barrier elimination PHM private heap management APS arena preselection (in conjunction with PHM) RCAO refcount allocation optimiz. (in conjunction with PHM) MSCA memory size cache adjustment (in conjunction with PHM) OPT enables/disables all optimizations at once. Lower case letters may be used to indicate optimization techniques. Command line arguments are evaluated from left to right, i.e., "-no OPT -do INL" disables all optimizations except for function inlining. Mike