From patchwork Thu May 10 07:44:35 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Biener X-Patchwork-Id: 158214 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]) by ozlabs.org (Postfix) with SMTP id 8E32AB6FA3 for ; Thu, 10 May 2012 17:44:59 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1337240700; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Date: From:To:Cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=/q0YTVCVCrCeFws6R6PenDEdirQ=; b=lvIwGVNZMdeE/l2 kMUV/H+60ki1MlOzXj+xFfpuk1G0hcQD8SQ1dBHm3k0wAcAvFYxbAn+lxCswj6LE HpPadDXQfrDe4yZWkoCpIs2okVG99npBE2ct5JsCcwu9h/UIx622kAboUQoGHA2O IAbb/PJoEkylTj588dfeCMJ1k5Ys= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Date:From:To:Cc:Subject:In-Reply-To:Message-ID:References:MIME-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=m3WTxkRXjP7CEzGO7aHAt2LaISFhY/w9vjAMTa7WA9RwCRqAXbyeXyXiWH1cG6 Fo5dbJ1KtoMpyWdvqxkcAKSQ2la/v4w3CL0jmwwhHRM/73jZJk0aTlCHpvgC2os6 gSYNad39CL0RUpGOZNPL/rg6iV10ip3DakNUsPTR6/eoA=; Received: (qmail 2181 invoked by alias); 10 May 2012 07:44:52 -0000 Received: (qmail 2170 invoked by uid 22791); 10 May 2012 07:44:49 -0000 X-SWARE-Spam-Status: No, hits=-6.0 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_THREADED, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 10 May 2012 07:44:36 +0000 Received: from relay1.suse.de (unknown [195.135.220.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 87D3395D63; Thu, 10 May 2012 09:44:35 +0200 (CEST) Date: Thu, 10 May 2012 09:44:35 +0200 (CEST) From: Richard Guenther To: Eric Botcazou Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Optimize byte_from_pos, pos_from_bit In-Reply-To: <201205092208.09431.ebotcazou@adacore.com> Message-ID: References: <201205092208.09431.ebotcazou@adacore.com> MIME-Version: 1.0 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 On Wed, 9 May 2012, Eric Botcazou wrote: > > This optimizes byte_from_pos and pos_from_bit by noting that we operate > > on sizes whose computations have no intermediate (or final) overflow. > > This is the single patch necessary to get Ada to bootstrap and test > > with TYPE_IS_SIZETYPE removed. Rather than amending size_binop > > (my original plan) I chose to optimize the above two commonly used > > accessors. > > > > Conveniently normalize_offset can be re-written to use pos_from_bit > > instead of inlinig it. I also took the liberty to document the > > functions (sic). > > Nice, thanks. Could you add a blurb, in the head comment of the first function > in which you operate under the no-overflow assumption, stating this fact and > why this is necessary (an explicit mention of Ada isn't forbidden ;-), as well > as a cross-reference to it in the head comment of the other function(s). Like this? Thanks, Richard. 2012-05-10 Richard Guenther * stor-layout.c (byte_from_pos): Amend comment. Index: gcc/stor-layout.c =================================================================== --- gcc/stor-layout.c (revision 187362) +++ gcc/stor-layout.c (working copy) @@ -798,7 +798,11 @@ bit_from_pos (tree offset, tree bitpos) } /* Return the combined truncated byte position for the byte offset OFFSET and - the bit position BITPOS. */ + the bit position BITPOS. + These functions operate on byte and bit positions as present in FIELD_DECLs + and it assumes that expressions result in no (intermediate) overflow. + This assumption is necessary to optimize these values as much as possible, + especially to make Ada happy. */ tree byte_from_pos (tree offset, tree bitpos)