From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3043 invoked by alias); 24 Jun 2010 18:03:24 -0000 Received: (qmail 2925 invoked by uid 22791); 24 Jun 2010 18:03:22 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE 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.43rc1) with ESMTP; Thu, 24 Jun 2010 18:03:16 +0000 Received: by fg-out-1718.google.com with SMTP id e12so1771732fga.8 for ; Thu, 24 Jun 2010 11:03:13 -0700 (PDT) Received: by 10.102.193.9 with SMTP id q9mr3290321muf.11.1277402593558; Thu, 24 Jun 2010 11:03:13 -0700 (PDT) Received: from [93.103.18.160] (93-103-18-160.static.t-2.net [93.103.18.160]) by mx.google.com with ESMTPS id i5sm12377128mue.19.2010.06.24.11.03.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 24 Jun 2010 11:03:12 -0700 (PDT) Subject: Re: PATCH: PR target/44588: Very inefficient 8bit mod/div From: Uros Bizjak To: "H.J. Lu" Cc: Paolo Bonzini , gcc-patches@gcc.gnu.org In-Reply-To: References: <20100621193321.GA13780@intel.com> <1277229955.2613.1.camel@localhost> <1277232299.2613.13.camel@localhost> <4C224592.5090100@gnu.org> <4C224EB7.8090900@gnu.org> <4C225D75.2070106@gnu.org> <4C22624E.1050207@gnu.org> <4C228D24.7040407@gnu.org> <4C229DC0.1050108@gnu.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 24 Jun 2010 19:01:00 -0000 Message-ID: <1277402591.6220.2.camel@localhost> Mime-Version: 1.0 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: 2010-06/txt/msg02491.txt.bz2 On Thu, 2010-06-24 at 09:47 -0700, H.J. Lu wrote: > On Wed, Jun 23, 2010 at 4:50 PM, Paolo Bonzini wrote: > > On 06/24/2010 01:13 AM, H.J. Lu wrote: > >>> > >>> I don't understand exactly what the problem was; clearly it couldn't work > >>> as > >>> long as this pattern was cheating blatantly: > >> > >> Upper 8bit registers aren't real registers. You can't > >> do RA with them. > > > > Please read what other people write. I'm saying that you should have used a > > HI destination just like you did with your new UNSPEC, which is acceptable. > > > > The pattern I quoted below used a QI destination; then magically you > > attempted to extract bit 8..15 of it with an unspec, or something like that. > > For anything like that the optimizers are going to bite back sooner or > > later. And you'd deserve it. > > > >>> (define_insn "*divqi3" > >>> [(set (match_operand:QI 0 "register_operand" "=a") > >>> (any_div:QI > >>> (match_operand:HI 1 "register_operand" "0") > >>> (match_operand:QI 2 "nonimmediate_operand" "qm"))) > >>> > >>> Anyway this patch is IMO much nicer than the first ones, so if Uros is > >>> okay > >>> I don't think it's useful to pursue a more accurate representation. Just > >>> make sure that REG_EQUAL notes are added to the two extractions. > >>> > >> > >> What are REG_EQUAL notes used for? > >> As far as the rest of gcc is concerned, there are no upper 8bit > >> registers. But you can access bits 8-15 of HI, SI, > >> DI registers via XXX_extract. > > > > Understood. Using an unspec is fine for me, even though it's not an > > approval. But that's completely orthogonal to putting a REG_EQUAL note _on > > the two regs that you extract out of AX_. The notes' value should be one of > > > > (subreg:QI (udiv:HI (...) (zero_extend (...)))) > > (subreg:QI (div:HI (...) (sign_extend (...)))) > > (subreg:QI (umod:HI (...) (zero_extend (...)))) > > (subreg:QI (mod:HI (...) (sign_extend (...)))) > > > > But I think that with over ten years of GCC experience you do not need > > anyone to tell you this. In fact, regarding "what are REG_EQUAL notes used > > for?" my first thought was RTFM, but anyway: they are used by CSE, fwprop, > > GCSE and combine to simplify and eliminate redundant expressions. > > I am learning new things all the time. Thanks for the pointer. > > Here is a new patch without UNSPEC. OK for trunk? OK for mainline, the approach in this patch is Really Good (TM). Please just rename operand0 and operand1 internal variables to perhaps tmp0 and tmp1, so they will not be confused with operand[0] and operand[1]. Thanks, Uros.