From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107839 invoked by alias); 22 Sep 2015 17:59:07 -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 107823 invoked by uid 89); 22 Sep 2015 17:59:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mailout01.t-online.de Received: from mailout01.t-online.de (HELO mailout01.t-online.de) (194.25.134.80) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 22 Sep 2015 17:59:05 +0000 Received: from fwd03.aul.t-online.de (fwd03.aul.t-online.de [172.20.27.148]) by mailout01.t-online.de (Postfix) with SMTP id 71D3F51C520; Tue, 22 Sep 2015 19:27:06 +0200 (CEST) Received: from [192.168.0.16] (ZqIuVUZFQh-pHDuWEj+IMxYPUCz3sa9kNxG-yoWHFYNY4blwdFlLlOSDuKbLt-OQRY@[115.165.93.200]) by fwd03.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1ZeRLM-0nlqq00; Tue, 22 Sep 2015 19:27:04 +0200 Message-ID: <1442942820.2509.57.camel@t-online.de> Subject: Re: ifcvt vs. expand_binop From: Oleg Endo To: Kyrill Tkachov Cc: GCC Patches , Jeff Law , Richard Henderson Date: Tue, 22 Sep 2015 18:39:00 -0000 In-Reply-To: <1442936932.2509.45.camel@t-online.de> References: <1442928926.2509.23.camel@t-online.de> <560163D6.7050901@arm.com> <1442936932.2509.45.camel@t-online.de> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg01681.txt.bz2 On Wed, 2015-09-23 at 00:48 +0900, Oleg Endo wrote: > I haven't checked the details. But I guess because expand_binop wants > to somehow reuse the input and output it creates a DImode pseudo, puts > the input there, does the DImode plus and the returned "target" is a > SImode subreg of the DImode result. The strange thing is the first > clobber (insn 50)... Maybe there's some other hidden problem in > expand_binop which is triggered by ifcvt in this case. OK ... this particular problem is in SH's md. The addsi3 expander purposefully fails if the output reg is the same as the 1st input reg. This was added because of some issues with LRA. Because of that expand_binop_directly fails and a widened op is tried, which goes wrong for some other reason (not going to investigate now). I guess there's no need for the ifcvt patch in this case. Sorry for the noise. Cheers, Oleg