From patchwork Thu Jul 13 01:18:55 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Pinski X-Patchwork-Id: 787486 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org 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 3x7Hz5294Lz9s0Z for ; Thu, 13 Jul 2017 11:19:12 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="G2OvzFFe"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:from:date:message-id:subject:to:content-type; q= dns; s=default; b=F5J1W2VXkYJ33QhtxSMC8MAtEZ2mMiAnMWujd0NuVf5vjw M2R+nePDST9wIe6vz8ZO64z+jyTPEsw/qgrHM19F7fMgXw0CqXlzUMbGEvq6d0zJ lJd6WX7ecUKje4O48iU2qd/a9Tah0+bqvLp1AEkwCAPSCUkteuBpaW2i7zkvA= 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 :mime-version:from:date:message-id:subject:to:content-type; s= default; bh=1NeueD0dOdpbYlgTf48QZZW6+F4=; b=G2OvzFFeOJmKDacm/lJF qxEwYzuzdtIyBx0asewvedBiOVF9TuKdP+CBE+1qNNlbSrdOrc0m6A7WPFy6PKwj WIeBE9eI07AlJlOug+RI23CiRdbDrsvyKhUtfFyI9UF0A5beRB8ygSiSFz8BkwfV 6R11o2kXxYOPaiFNRcUqWEc= Received: (qmail 23751 invoked by alias); 13 Jul 2017 01:19:00 -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 23736 invoked by uid 89); 13 Jul 2017 01:18:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-10.5 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM, SPF_PASS autolearn=ham version=3.3.2 spammy=1s, Hx-languages-length:1729 X-HELO: mail-yw0-f178.google.com Received: from mail-yw0-f178.google.com (HELO mail-yw0-f178.google.com) (209.85.161.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Jul 2017 01:18:58 +0000 Received: by mail-yw0-f178.google.com with SMTP id x125so16913872ywa.0 for ; Wed, 12 Jul 2017 18:18:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OsUmevH7L0uvJFqDrMuonwZi8PTp1N017l9WGofZ1ZE=; b=f0YFasNR9/bg5fKFmeaej5CKu/uEQ6LYlvARep32SZhbFIOup9Ig6RrbKdsSutPTJ0 jrqyrV+mhOFM9GFFCFvjkcONNIqLnsHwu952+wQ1aBSEAJobjMp8rdojmIw1c1xk/Cn8 dEpY8EM/v4lHjf8gzOTNKgIO0x3YH6djGAR5H8mizFy8qvOSL356eWSZxI5QXmQLqzLZ 4FqNeOjDYX7ZbqxqTooCwu18VdFWeSStYxKTXutFP1xVTJ40iP/CHsjYzVsZeWXKhX0m IxgDl1ciMkyRkThUZumhmWSXRK5yHEL1mAcw2BpNVkAVIx8tdMHhT8r+bLNSZvIj5yIH zsgQ== X-Gm-Message-State: AIVw111S2ckeqQRCFPGJdX33JoXnDl2uSUchzshPMNbtd7fD4QEyPnsd 5pgu9z9rcuH/oxG8dw+0k7cGkumS8OFA X-Received: by 10.13.242.66 with SMTP id b63mr97201ywf.320.1499908736326; Wed, 12 Jul 2017 18:18:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.223.197 with HTTP; Wed, 12 Jul 2017 18:18:55 -0700 (PDT) From: Andrew Pinski Date: Wed, 12 Jul 2017 18:18:55 -0700 Message-ID: Subject: [RFC/SCCVN] Handle BIT_INSERT_EXPR in vn_nary_op_eq To: GCC Patches X-IsSubscribed: yes Hi, Unlike most other expressions, BIT_INSERT_EXPR has an implicit operand of the precision/size of the second operand. This means if we have an integer constant for the second operand and that compares to the same constant value, vn_nary_op_eq would return that these two expressions are the same. But in the case I was looking into the integer constants had different types, one with 1 bit precision and the other with 2 bit precision which means the BIT_INSERT_EXPR were not equal at all. This patches the problem by checking to see if BIT_INSERT_EXPR's operand 1's (second operand) type has different precision to return false. Is this the correct location or should we be checking for this differently? If this is the correct location, is the patch ok? Bootstrapped and tested on aarch64-linux-gnu with no regressions (and also tested with a few extra patches to expose BIT_INSERT_EXPR). Thanks, Andrew Pinski ChangeLog: * tree-ssa-sccvn.c (vn_nary_op_eq): Check BIT_INSERT_EXPR's operand 1 to see if the types precision matches. Index: tree-ssa-sccvn.c =================================================================== --- tree-ssa-sccvn.c (revision 250159) +++ tree-ssa-sccvn.c (working copy) @@ -2636,6 +2636,14 @@ vn_nary_op_eq (const_vn_nary_op_t const if (!expressions_equal_p (vno1->op[i], vno2->op[i])) return false; + /* BIT_INSERT_EXPR has an implict operand as the type precision + of op1. Need to check to make sure they are the same. */ + if (vno1->opcode == BIT_INSERT_EXPR) + if (INTEGRAL_TYPE_P (TREE_TYPE (vno1->op[0])) + && TYPE_PRECISION (TREE_TYPE (vno1->op[1])) + != TYPE_PRECISION (TREE_TYPE (vno2->op[1]))) + return false; + return true; }