From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7010 invoked by alias); 21 Feb 2008 16:00:36 -0000 Received: (qmail 6906 invoked by uid 22791); 21 Feb 2008 16:00:33 -0000 X-Spam-Check-By: sourceware.org Received: from fg-out-1718.google.com (HELO fg-out-1718.google.com) (72.14.220.155) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 21 Feb 2008 16:00:02 +0000 Received: by fg-out-1718.google.com with SMTP id d23so66659fga.28 for ; Thu, 21 Feb 2008 07:59:09 -0800 (PST) Received: by 10.86.97.7 with SMTP id u7mr9623774fgb.39.1203609549651; Thu, 21 Feb 2008 07:59:09 -0800 (PST) Received: from ?192.168.76.107? ( [195.176.176.226]) by mx.google.com with ESMTPS id e11sm188139fga.5.2008.02.21.07.59.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 21 Feb 2008 07:59:08 -0800 (PST) Message-ID: <47BD9FCB.2040805@gnu.org> Date: Thu, 21 Feb 2008 16:54:00 -0000 From: Paolo Bonzini User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Richard Guenther CC: GCC Patches Subject: Re: PING: PR/17236, improve long long multiply on x86 (middle-end) References: <47BBDFFE.5030001@gnu.org> <84fc9c000802210745n7b9b1c86w56166383d9eefede@mail.gmail.com> In-Reply-To: <84fc9c000802210745n7b9b1c86w56166383d9eefede@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2008-02/txt/msg00925.txt.bz2 Richard Guenther wrote: > 2008/2/20 Paolo Bonzini : >> http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00995.html > > The combine trick is obvious, but I'd like to know whether the two > other tweaks have an impact on other targets. Does the combine > trick alone help? Can you try crafting a testcase somehow (I realize > this might be difficult, but maybe counting the number of moves > works out in a target dependent test). No, all three are necessary. Each is a tiny step further: with the regclass.c hunk GCC "considers" using %eax, but without the local-alloc.c hunk that class is already taken by another pseudo. The combine.c hunk is actually the least necessary of all; without it, GCC just generates one more memory access, but not more spills. The regclass.c hunk is also pretty obvious -- it is just a trick to improve coalescing between a register that dies and one that has a duplicate constraint with the dying register (a la regmove). Note that if the register does not die, the behavior is the same as without the patch (alt_cost += 2). Most RISC processors would probably be unaffected by the changes, since they have plenty of registers and no small register classes. sh could be an, ehm, interesting target to test. Paolo