From patchwork Tue Dec 13 11:44:11 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Preudhomme X-Patchwork-Id: 705381 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 3tdHtW1vRTz9t0X for ; Tue, 13 Dec 2016 22:44:35 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="Yw+Q6kMB"; 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:to :from:subject:message-id:date:mime-version:content-type; q=dns; s=default; b=wMqZi/xrzPeS7RuYebFDnDZGXMGI7nKk/+Mr3eEXNV0S/jDQn+ cYDdDGsfkU8YLnvh28SuMLFPynA5OZVzIV/e3bsf0ERBXwCt+dvmtc3UEH72fZlU 9RvzBZOu1CKMSf6QZUnlktPfg5Oe5OEbX4bmfl4/No1S3MOYTEHSB7DW8= 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:to :from:subject:message-id:date:mime-version:content-type; s= default; bh=Hc1nq0qfIb6SDyNhVyYWBm6KlOo=; b=Yw+Q6kMBqE9MYN2ZP5vW o19He7BOdR1l8fHZvuOs/hirjD8rTbICNHqGW10zA4p5tAUY2N2gU4DcJGcc8laF iMicXbplPMJuzO7ghGuZxaVkynOPIU+G/cYelGwJl8fQhgGrRN5ZizUCoLJQX2G4 mzA8gWiLCd0puy34Y0sz9+k= Received: (qmail 121032 invoked by alias); 13 Dec 2016 11:44:27 -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 120989 invoked by uid 89); 13 Dec 2016 11:44:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=BAYES_00, KAM_LAZY_DOMAIN_SECURITY, RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=accompanied, consisting X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 13 Dec 2016 11:44:14 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 68944F; Tue, 13 Dec 2016 03:44:13 -0800 (PST) Received: from [10.2.206.52] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C93D73F220; Tue, 13 Dec 2016 03:44:12 -0800 (PST) To: Richard Biener , Jakub Jelinek , "gcc-patches@gcc.gnu.org" From: Thomas Preudhomme Subject: [PATCH, GCC, gcc-5/6-branch] Improve comment for struct symbolic_number in bswap pass Message-ID: <36d5b24a-3d9d-213c-6755-ffd898763a3a@foss.arm.com> Date: Tue, 13 Dec 2016 11:44:11 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 X-IsSubscribed: yes Hi, Fix in r242869 for PR77673 was accompanied with r242870 which updated the description of the struct symbolic_number modified by the previous patch. It did so by rewriting the comment completely but I believe this patch should be still backported to make the comment match the code. ChangeLog entry is as follows: *** gcc/ChangeLog *** 2016-12-12 Thomas Preud'homme Backport from mainline 2016-11-25 Thomas Preud'homme * tree-ssa-math-opts.c (struct symbolic_number): Improve comment. Is this ok for gcc-5-branch and gcc-6-branch? Best regards, Thomas diff --git a/gcc/tree-ssa-math-opts.c b/gcc/tree-ssa-math-opts.c index ac15e8179a3257d1e190086c8089bc85ed8552bf..6413bd6d1ae17d04e276d97c088497d6d334823c 100644 --- a/gcc/tree-ssa-math-opts.c +++ b/gcc/tree-ssa-math-opts.c @@ -1925,25 +1925,32 @@ make_pass_cse_sincos (gcc::context *ctxt) return new pass_cse_sincos (ctxt); } -/* A symbolic number is used to detect byte permutation and selection - patterns. Therefore the field N contains an artificial number - consisting of octet sized markers: +/* A symbolic number structure is used to detect byte permutation and selection + patterns of a source. To achieve that, its field N contains an artificial + number consisting of BITS_PER_MARKER sized markers tracking where does each + byte come from in the source: - 0 - target byte has the value 0 - FF - target byte has an unknown value (eg. due to sign extension) - 1..size - marker value is the target byte index minus one. + 0 - target byte has the value 0 + FF - target byte has an unknown value (eg. due to sign extension) + 1..size - marker value is the byte index in the source (0 for lsb). To detect permutations on memory sources (arrays and structures), a symbolic - number is also associated a base address (the array or structure the load is - made from), an offset from the base address and a range which gives the - difference between the highest and lowest accessed memory location to make - such a symbolic number. The range is thus different from size which reflects - the size of the type of current expression. Note that for non memory source, - range holds the same value as size. - - For instance, for an array char a[], (short) a[0] | (short) a[3] would have - a size of 2 but a range of 4 while (short) a[0] | ((short) a[0] << 1) would - still have a size of 2 but this time a range of 1. */ + number is also associated: + - a base address BASE_ADDR and an OFFSET giving the address of the source; + - a range which gives the difference between the highest and lowest accessed + memory location to make such a symbolic number; + - the address SRC of the source element of lowest address as a convenience + to easily get BASE_ADDR + offset + lowest bytepos. + + Note 1: the range is different from size as size reflects the size of the + type of the current expression. For instance, for an array char a[], + (short) a[0] | (short) a[3] would have a size of 2 but a range of 4 while + (short) a[0] | ((short) a[0] << 1) would still have a size of 2 but this + time a range of 1. + + Note 2: for non-memory sources, range holds the same value as size. + + Note 3: SRC points to the SSA_NAME in case of non-memory source. */ struct symbolic_number { uint64_t n;