From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24916 invoked by alias); 21 Jul 2002 21:56:09 -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 24909 invoked from network); 21 Jul 2002 21:56:08 -0000 Received: from unknown (HELO localhost.localdomain) (66.60.148.227) by sources.redhat.com with SMTP; 21 Jul 2002 21:56:08 -0000 Received: from warlock.codesourcery.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g6LLsXC16195; Sun, 21 Jul 2002 14:54:33 -0700 Date: Sun, 21 Jul 2002 18:14:00 -0000 From: Mark Mitchell To: Gabriel Dos Reis cc: Jason Merrill , Richard Henderson , "gcc@gcc.gnu.org" Subject: Re: [tree-ssa] Simplifying TARGET_EXPR Message-ID: <52110000.1027288471@warlock.codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SW-Source: 2002-07/txt/msg00978.txt.bz2 > Do you think we should always elide copy-constructors by default, > unless explicitly told the contrary? Yes. I think the front end shoul consistently try hard to elide copy-constructors, then give up and hand off the result to the optimizers without hoping for any more elision. Maybe I'm developing an unhealthy paranoia. On the one hand, optimizing away more copy constructors is like optimizinga away more copies between scalars, and I'm all for having -O2 do more of that! On the other, copy constructor elision is observable behavior in the program, and it's going to make it hard to do debug, profile, and otherwise analyze your program if the number of copy constructor calls changes when you optimize. My two cents, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com