From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25117 invoked by alias); 23 Jun 2010 18:13:23 -0000 Received: (qmail 25109 invoked by uid 22791); 23 Jun 2010 18:13:23 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM X-Spam-Check-By: sourceware.org Received: from mail-ww0-f47.google.com (HELO mail-ww0-f47.google.com) (74.125.82.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 Jun 2010 18:13:16 +0000 Received: by wwb22 with SMTP id 22so989946wwb.20 for ; Wed, 23 Jun 2010 11:13:14 -0700 (PDT) Received: by 10.227.156.16 with SMTP id u16mr7839509wbw.74.1277316793958; Wed, 23 Jun 2010 11:13:13 -0700 (PDT) Received: from yakj.usersys.redhat.com ([209.132.186.34]) by mx.google.com with ESMTPS id k33sm13425043wbn.6.2010.06.23.11.13.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 23 Jun 2010 11:13:13 -0700 (PDT) Message-ID: <4C224EB7.8090900@gnu.org> Date: Wed, 23 Jun 2010 19:00:00 -0000 From: Paolo Bonzini User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Lightning/1.0b2pre Thunderbird/3.0.5 MIME-Version: 1.0 To: "H.J. Lu" CC: Uros Bizjak , gcc-patches@gcc.gnu.org Subject: Re: PATCH: PR target/44588: Very inefficient 8bit mod/div References: <20100621193321.GA13780@intel.com> <1277229955.2613.1.camel@localhost> <1277232299.2613.13.camel@localhost> <4C224592.5090100@gnu.org> In-Reply-To: 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: 2010-06/txt/msg02361.txt.bz2 On 06/23/2010 07:48 PM, H.J. Lu wrote: >> Well, sure you can: >> >> (set (reg:HI r) >> (ior:HI (lshift:HI >> (zero_extend:HI (umod:QI ...) (const_int 8))) >> (zero_extend:HI (udiv:QI ...) (const_int 8)))) >> >> (set (reg:QI s) ;; remainder >> (zero_extract (reg:HI r) (const_int 8) (const_int 8))) >> >> (set (reg:QI t) ;; quotient >> (subreg (reg:HI r) 0)) >> >> The question is only whether fwprop, combine and regalloc are smart enough >> to reason about it. >> > > That is what I meant by "We can only access them via sign_extract > and zero_extract." The rest of gcc will see the same hard register > number for both lower and upper 8bit registers. They aren't prepared > to deal with it. Do you mean that GCC will miscompile or pessimize a "mov %ah, %al" for the zero-extract in the second set above? Otherwise, it seems like a false problem. Paolo