From patchwork Fri Jan 12 10:20:58 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Botcazou X-Patchwork-Id: 859723 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-470960-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="hEfJh7NJ"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3zHzL043WBz9sNw for ; Fri, 12 Jan 2018 21:21:12 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; q=dns; s=default; b=BrAqcdwgpKnJY287 7mseA+T7xmVZ3lssO2G/kYSoNhuVG0WjL5fuJE37O6cHm+FIbSimiLf0xkT4GT59 Zni48ZzibE4ZdG3p6zVYPq6WYRvHz6supr85PIpzzgQ1s5nJP3iygMJeUPsCKeQ/ jwPhZD1ShCyAl6PZcpquQadVqKk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=default; bh=oVRNE1LWtnRtm8yymvul4T Wo9gQ=; b=hEfJh7NJJSndpxnc1fnPEjFDvQ7cEVlsOONXhtezsvMfX9Ou11u6em gnLR6AicCdhIoB+Y7StcYOGQFvX+mXe8VFP10r/ri+EC9aAJ9wbuksE8Z8apfZWR KuCKJ+GCyKOFuTFQ4lenn53Tp1WytML0EKpIfzGGuZv6rmaql89bI= Received: (qmail 64867 invoked by alias); 12 Jan 2018 10:21:04 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 64857 invoked by uid 89); 12 Jan 2018 10:21:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-9.8 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, KAM_ASCII_DIVIDERS, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=D*ru, 475911 X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 12 Jan 2018 10:21:01 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 51F0582355 for ; Fri, 12 Jan 2018 11:20:59 +0100 (CET) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f_2hUA-kqrQZ for ; Fri, 12 Jan 2018 11:20:59 +0100 (CET) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 1976582353 for ; Fri, 12 Jan 2018 11:20:59 +0100 (CET) From: Eric Botcazou To: gcc-patches@gcc.gnu.org Subject: Fix PR rtl-optimization/83565 Date: Fri, 12 Jan 2018 11:20:58 +0100 Message-ID: <15313529.xjM19aB6vx@polaris> MIME-Version: 1.0 This fixes a regression present on the mainline and 7 branch for IA-64 whereby the combiner wrongly infers that some bits are zero after a rotate operation because nonzero_bits says so for WORD_REGISTER_OPERATIONS machines. As discussed in the audit trail, WORD_REGISTER_OPERATIONS is ambiguous because it isn't fully clear which operations are covered. But it seems sensible to say that rotate operations are not, since neither defining nor leveraging what happens for the upper bits of a register when the lower bits are rotated seems straightforward. So the attached patch just implements that. There are two versions of the patch: one for the 7 branch which only does that and one for the mainline which additionally handles ROTATERT in nonzero_bits1 (the RTL operation is already handled in the twin num_sign_bit_copies1). Tested on IA-64/Linux and SPARC64/Linux, applied on mainline and 7 branch. 2018-01-12 Eric Botcazou PR rtl-optimization/83565 * rtlanal.c (nonzero_bits1): On WORD_REGISTER_OPERATIONS machines, do not extend the result to a larger mode for rotate operations. (num_sign_bit_copies1): Likewise. 2018-01-12 Eric Botcazou * gcc.c-torture/execute/20180112-1.c: New test. Index: rtlanal.c =================================================================== --- rtlanal.c (revision 255413) +++ rtlanal.c (working copy) @@ -4312,7 +4312,7 @@ nonzero_bits1 (const_rtx x, machine_mode { unsigned HOST_WIDE_INT nonzero = GET_MODE_MASK (mode); unsigned HOST_WIDE_INT inner_nz; - enum rtx_code code; + enum rtx_code code = GET_CODE (x); machine_mode inner_mode; unsigned int mode_width = GET_MODE_PRECISION (mode); @@ -4335,18 +4335,18 @@ nonzero_bits1 (const_rtx x, machine_mode return nonzero; /* If MODE is wider than X, but both are a single word for both the host - and target machines, we can compute this from which bits of the - object might be nonzero in its own mode, taking into account the fact - that on many CISC machines, accessing an object in a wider mode - causes the high-order bits to become undefined. So they are - not known to be zero. */ - - if (!WORD_REGISTER_OPERATIONS - && GET_MODE (x) != VOIDmode + and target machines, we can compute this from which bits of the object + might be nonzero in its own mode, taking into account the fact that, on + CISC machines, accessing an object in a wider mode generally causes the + high-order bits to become undefined, so they are not known to be zero. + We extend this reasoning to RISC machines for rotate operations since the + semantics of the operations in the larger mode is not well defined. */ + if (GET_MODE (x) != VOIDmode && GET_MODE (x) != mode && GET_MODE_PRECISION (GET_MODE (x)) <= BITS_PER_WORD && GET_MODE_PRECISION (GET_MODE (x)) <= HOST_BITS_PER_WIDE_INT - && GET_MODE_PRECISION (mode) > GET_MODE_PRECISION (GET_MODE (x))) + && GET_MODE_PRECISION (mode) > GET_MODE_PRECISION (GET_MODE (x)) + && (!WORD_REGISTER_OPERATIONS || code == ROTATE)) { nonzero &= cached_nonzero_bits (x, GET_MODE (x), known_x, known_mode, known_ret); @@ -4356,7 +4356,6 @@ nonzero_bits1 (const_rtx x, machine_mode /* Please keep nonzero_bits_binary_arith_p above in sync with the code in the switch below. */ - code = GET_CODE (x); switch (code) { case REG: @@ -4873,8 +4872,10 @@ num_sign_bit_copies1 (const_rtx x, machi { /* If this machine does not do all register operations on the entire register and MODE is wider than the mode of X, we can say nothing - at all about the high-order bits. */ - if (!WORD_REGISTER_OPERATIONS) + at all about the high-order bits. We extend this reasoning to every + machine for rotate operations since the semantics of the operations + in the larger mode is not well defined. */ + if (!WORD_REGISTER_OPERATIONS || code == ROTATE || code == ROTATERT) return 1; /* Likewise on machines that do, if the mode of the object is smaller