From patchwork Wed Nov 23 10:45:37 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Preudhomme X-Patchwork-Id: 83629 Delivered-To: patch@linaro.org Received: by 10.140.97.165 with SMTP id m34csp2565633qge; Wed, 23 Nov 2016 02:46:06 -0800 (PST) X-Received: by 10.99.119.71 with SMTP id s68mr4066879pgc.11.1479897966031; Wed, 23 Nov 2016 02:46:06 -0800 (PST) Return-Path: Received: from sourceware.org (server1.sourceware.org. [209.132.180.131]) by mx.google.com with ESMTPS id k5si33157614pgn.247.2016.11.23.02.46.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Nov 2016 02:46:06 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-return-442352-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) client-ip=209.132.180.131; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org; spf=pass (google.com: domain of gcc-patches-return-442352-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=gcc-patches-return-442352-patch=linaro.org@gcc.gnu.org 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=IXJ1Q4l09a801IQAM6jKKRewFR6HMsY3FaJF0fplMuHoXd1F7d v798SZtkXO/rkr7XHEGoz62SLIwGSDxRjnSqi/nfVYY3V42Ea2OfRYbX4po512TQ 0bMmqUatLiqQzitpNWpkzqsoGlWS0sSSFiddB1JZNrJev2giVWdKi9Dyc= 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=rPitH7oEu/sEkOE/6E/sMEFTJ1U=; b=mcxrYL6DcIWcGGFcl74x DVbZI0OBrGrOMaofcA6VAKxdAc3Uk51Jl3Cc94kZ1H28fa/QD8z5ycbeo3XVvl3t KErfV7t/4nk4cG9+aycH691Lt4LV4p2tCfOw8/4qMrOJra55huhWAeEnhq2dKBQ8 5LPoGck8q7JHxOvCu692/CE= Received: (qmail 63015 invoked by alias); 23 Nov 2016 10:45:52 -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 62975 invoked by uid 89); 23 Nov 2016 10:45:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=BAYES_00, KAM_LAZY_DOMAIN_SECURITY, RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=permutation, reflects 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; Wed, 23 Nov 2016 10:45:40 +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 DF7F8AD7; Wed, 23 Nov 2016 02:45:38 -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 4BC543F24D; Wed, 23 Nov 2016 02:45:38 -0800 (PST) To: Richard Biener , Jakub Jelinek , "gcc-patches@gcc.gnu.org" From: Thomas Preudhomme Subject: [PATCH, GCC] Improve comment for struct symbolic_number in bswap pass Message-ID: Date: Wed, 23 Nov 2016 10:45:37 +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, The current comment for struct symbolic_number in the bswap pass code (tree-ssa-math-opts.c) does not explain all of the fields in the structure. It is also a bit unclear at times. This patch rewrites the comment to fix those. Note: it depends on the fix for PR77673 to be installed first. ChangeLog entry is as follows: *** gcc/ChangeLog *** 2016-11-22 Thomas Preud'homme * tree-ssa-math-opts.c (struct symbolic_number): Improve comment. Is this ok for trunk? Best regards, Thomas diff --git a/gcc/tree-ssa-math-opts.c b/gcc/tree-ssa-math-opts.c index b0b0c2440aec025c551da76ea637f7b9a50acc43..4a47254d223e24caf1cd611f434a578729ba205d 100644 --- a/gcc/tree-ssa-math-opts.c +++ b/gcc/tree-ssa-math-opts.c @@ -1931,25 +1931,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;