From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1342 invoked by alias); 16 Jul 2002 10:22:57 -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 1332 invoked from network); 16 Jul 2002 10:22:55 -0000 Received: from unknown (HELO executor.cambridge.redhat.com) (195.224.55.237) by sources.redhat.com with SMTP; 16 Jul 2002 10:22:55 -0000 Received: from prospero.cambridge.redhat.com (dell-paw-2.cambridge.redhat.com [195.224.55.226]) by executor.cambridge.redhat.com (Postfix) with ESMTP id 5E535ABB2E for ; Tue, 16 Jul 2002 11:22:54 +0100 (BST) Received: by prospero.cambridge.redhat.com (Postfix, from userid 4046) id 96C26F8D66; Tue, 16 Jul 2002 11:22:52 +0100 (BST) To: gcc@gcc.gnu.org Subject: [tree-ssa] Simplifying TARGET_EXPR From: Jason Merrill Date: Tue, 16 Jul 2002 09:52:00 -0000 Message-ID: User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.1 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-07/txt/msg00672.txt.bz2 Thinking about simplifying TARGET_EXPR, I see two issues to be dealt with: 1) expand_expr's treatment of TARGET_EXPR depends on whether or not it is being expanded with a target: if so, it initializes the target object; if not, it initializes a new object. There's no way to model that behavior with the current simplification code, as there's no concept of 'target'. However, I think that the copy-elision should only occur under an INIT_EXPR, so we can check for TARGET_EXPR in simplify_modify_expr. This should work fine. 2) Passing a TARGET_EXPR to a call means initializing the temporary on the stack and passing its address to the call. There's no way to express this in a simplified form; if we replace the TARGET_EXPR with the variable it initializes, expand_call will make a bitwise copy, which is wrong. I can think of two solutions to this: a) Change expand_call to not copy variables with DECL_ARTIFICIAL set. b) Pass an ADDR_EXPR of the variable instead, and change expand_call to handle that case. My preference is for (b), as (a) might have unintended consequences. Thoughts? Jason