From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1016 invoked by alias); 31 Oct 2014 17:23:08 -0000 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 Received: (qmail 1003 invoked by uid 89); 31 Oct 2014 17:23:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 31 Oct 2014 17:23:06 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1XkFuf-00042B-Ta from Bernd_Schmidt@mentor.com ; Fri, 31 Oct 2014 10:23:02 -0700 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.181.6; Fri, 31 Oct 2014 17:23:00 +0000 Message-ID: <5453C563.2030804@codesourcery.com> Date: Fri, 31 Oct 2014 17:27:00 -0000 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.8.0 MIME-Version: 1.0 To: Segher Boessenkool CC: GCC Patches Subject: Re: ptx preliminary rtl patches [1/4] References: <5411A2A6.1030303@codesourcery.com> <20141030173615.GA22655@gate.crashing.org> In-Reply-To: <20141030173615.GA22655@gate.crashing.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2014-10/txt/msg03341.txt.bz2 On 10/30/2014 06:36 PM, Segher Boessenkool wrote: > On Thu, Sep 11, 2014 at 03:24:54PM +0200, Bernd Schmidt wrote: >> The nvptx backend is somewhat unusual in that call insns set a pseudo. >> The combiner is surprised by this and allows combining them into other >> insns, which remain as INSN rather than CALL_INSN. Aborts ensue. > > distribute_notes has code for when I2 is a CALL. This suggests that > on some other targets there can be useful combinations made, so it > isn't in that case terribly nice to disable all combinations with CALLs > as I0 or I1 or I2. > > Or it's dead code :-) I suspect the latter. As far as I can tell the patch does not change code generation on x86_64 at least (on a large set of input files including gcc, spec2k and linux-kernel). Bernd