From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31657 invoked by alias); 13 Aug 2007 19:11:06 -0000 Received: (qmail 31503 invoked by uid 22791); 13 Aug 2007 19:11:05 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 13 Aug 2007 19:10:59 +0000 Received: from zps38.corp.google.com (zps38.corp.google.com [172.25.146.38]) by smtp-out.google.com with ESMTP id l7DJAp9R023382; Mon, 13 Aug 2007 20:10:52 +0100 Received: from smtp.corp.google.com (spacemonkey2.corp.google.com [192.168.120.114]) by zps38.corp.google.com with ESMTP id l7DJAcjI022933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 Aug 2007 12:10:40 -0700 Received: from localhost.localdomain.google.com (adsl-71-133-8-30.dsl.pltn13.pacbell.net [71.133.8.30]) (authenticated bits=0) by smtp.corp.google.com (8.13.8/8.13.8) with ESMTP id l7DJAbVO030361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 Aug 2007 12:10:37 -0700 To: Rask Ingemann Lambertsen Cc: gcc@gcc.gnu.org Subject: Re: Sign extension by expr.c convert_move() References: <20070812151338.GB25795@sygehus.dk> From: Ian Lance Taylor Date: Mon, 13 Aug 2007 21:50:00 -0000 In-Reply-To: <20070812151338.GB25795@sygehus.dk> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2007-08/txt/msg00226.txt.bz2 Rask Ingemann Lambertsen writes: > In expr.c, convert_move() tries to synthesize sign extension in modes > larger than those directly supported by the target. There are two strategies > for generating the sign bit copies: > > 1) Compare with 0 and use "slt" if STORE_FLAG_VALUE == -1. > 2) Use a signed right shift of one bit less than the operand width. > > /* Compute the value to put in each remaining word. */ > if (unsignedp) > fill_value = const0_rtx; > else > { > #ifdef HAVE_slt > if (HAVE_slt > && insn_data[(int) CODE_FOR_slt].operand[0].mode == word_mode > && STORE_FLAG_VALUE == -1) > { > emit_cmp_insn (lowfrom, const0_rtx, NE, NULL_RTX, > lowpart_mode, 0); > fill_value = gen_reg_rtx (word_mode); > emit_insn (gen_slt (fill_value)); > } > else > #endif > { > fill_value > = expand_shift (RSHIFT_EXPR, lowpart_mode, lowfrom, > size_int (GET_MODE_BITSIZE (lowpart_mode) - 1), > NULL_RTX, 0); > fill_value = convert_to_mode (word_mode, fill_value, 1); > } > } > > My questions center around the first aproach: > > 1) Shouldn't it check that the comparison is directly supported by the > target rather than implemented by a library call? The condition code handling in gcc is more complex than it needs to be. The way to generate an slt instruction is what you see above: emit_cmp_insn followed by gen_slt. The gen_slt needs to figure out which operands to compare. If you have a gen_slt which works in word_mode, then the comparison instruction is presumed to exist. There is probably a bug here when lowpart_mode != word_mode. For most targets that case can never arise, because there are not two different sizes of signed integers both of which are larger than word_mode. > 2) How does it handle failure of gen_slt? It clearly doesn't. That is a different bug. Ian