From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29163 invoked by alias); 22 Jun 2011 00:59:02 -0000 Received: (qmail 29154 invoked by uid 22791); 22 Jun 2011 00:59:02 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from dair.pair.com (HELO dair.pair.com) (209.68.1.49) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Wed, 22 Jun 2011 00:58:48 +0000 Received: (qmail 4863 invoked by uid 20157); 22 Jun 2011 00:58:47 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 22 Jun 2011 00:58:47 -0000 Date: Wed, 22 Jun 2011 03:28:00 -0000 From: Hans-Peter Nilsson To: Georg-Johann Lay cc: Denis Chertykov , gcc-patches@gcc.gnu.org, Anatoly Sokolov , "Eric B. Weddington" , Richard Henderson Subject: Re: [Patch, AVR]: Fix PR46779 In-Reply-To: <4DF650B7.3030705@gjlay.de> Message-ID: References: <4DF0FAB5.6070704@gjlay.de> <4DF11D20.4030907@gjlay.de> <4DF1ED76.4030507@gjlay.de> <4DF650B7.3030705@gjlay.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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-06/txt/msg01648.txt.bz2 On Mon, 13 Jun 2011, Georg-Johann Lay wrote: > [In CCing Richard Henderson] > Denis Chertykov schrieb: > > 2011/6/10 Georg-Johann Lay : > > > Then I observed trouble with DI patterns during libgcc build and had > > > to remove > > > > > > * "zero_extendqidi2" > > > * "zero_extendhidi2" > > > * "zero_extendsidi2" > > > > > > These are "orphan" insns: they deal with DI without having movdi > > > support so I removed them. > > > > This seems strange for me. > > As far as I know, to support a mode a respective mov insn is needed, For the record, not in general, just if you have patterns operating on DImode. I.e. if you always have to call into libgcc for every operation, you're fine with just SImode, as the access will be split into SImode accesses. (That reload can't split the access is arguably a wart.) It's even documented, "node Standard Names" for mov@var{m}: "If there are patterns accepting operands in larger modes, @samp{mov@var{m}} must be defined for integer modes of those sizes." > which is > not the case for DI. I don't know the exact rationale behind that > (reloading?), Yes. (I ran into problems with this myself long ago.) > just read is on gcc list by Ian Taylor (and also that it is > stronly discouraged to have more than one mov insn per mode). That is correct. > So if the requirement to have mov insn is dropped and without the burden to > implement movdi, it would be rather easy to implement adddi3 and subdi3 for > avr... Resist the temptation... I see you did. :) brgds, H-P