From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1283 invoked by alias); 20 Jul 2002 18:59:29 -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 27480 invoked from network); 20 Jul 2002 16:12:47 -0000 Received: from unknown (HELO executor.cambridge.redhat.com) (195.224.55.237) by sources.redhat.com with SMTP; 20 Jul 2002 16:12:47 -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 165C8ABAFC; Sat, 20 Jul 2002 17:12:43 +0100 (BST) Received: by prospero.cambridge.redhat.com (Postfix, from userid 4046) id 1A767F83C1; Sat, 20 Jul 2002 17:09:42 +0100 (BST) To: Mark Mitchell Cc: Richard Henderson , gcc@gcc.gnu.org, Jason Merrill Subject: Re: [tree-ssa] Simplifying TARGET_EXPR From: Jason Merrill Date: Sat, 20 Jul 2002 18:54: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: multipart/mixed; boundary="=-=-=" X-SW-Source: 2002-07/txt/msg00906.txt.bz2 --=-=-= Content-length: 594 I'm interested in what y'all think about the second issue; it's something I've run into previously when thinking about expanding NEW_EXPR. One problem with (b) is that using it requires the frontend to know about passing by invisible reference. However, in the cases where we pass by invisible reference because TREE_ADDRESSABLE is set on the type, it's already controlled by the frontend, so that doesn't seem like a big issue. For cases where we would pass by invisiref for other reasons, doing a bitwise copy is just inefficient, and we could leave it up to the optimizer to fix that up. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Content-length: 773 From: Jason Merrill Subject: [tree-ssa] Simplifying TARGET_EXPR Date: Tue, 16 Jul 2002 11:02:01 +0100 To: gcc@gcc.gnu.org MIME-Version: 1.0 Content-length: 613 [snip] 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 --=-=-=--