From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15314 invoked by alias); 7 Nov 2011 16:08:20 -0000 Received: (qmail 15306 invoked by uid 22791); 7 Nov 2011 16:08:19 -0000 X-SWARE-Spam-Status: No, hits=-7.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Nov 2011 16:08:06 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pA7G86FK021742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Nov 2011 11:08:06 -0500 Received: from anchor.twiddle.net (vpn-225-162.phx2.redhat.com [10.3.225.162]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id pA7G85LJ032046; Mon, 7 Nov 2011 11:08:06 -0500 Message-ID: <4EB80265.1030407@redhat.com> Date: Mon, 07 Nov 2011 16:11:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0 MIME-Version: 1.0 To: Richard Guenther CC: Aldy Hernandez , gcc-patches Subject: Re: [patch] 19/n: trans-mem: middle end/misc patches (LAST PATCH) References: <4EB2EC3F.6000908@redhat.com> <4EB6D797.4070309@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-11/txt/msg00977.txt.bz2 On 11/07/2011 01:44 AM, Richard Guenther wrote: > It just catched my eye... moving it to expand_call_stmt would be nice > indeed, but I was suggesting to add that note where we produce the > CALL rtx, not sure if that's reasonably straight-forward (I suppose there > was a reason to go with the hack above ...). Because targets emit all sorts of stuff in gen_call that isn't a CALL_INSN. We have to search anyway. And the guts of expand_call are complex enough already; no need to make it worse. r~