From patchwork Tue Apr 17 20:11:37 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 153306 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 9A3C7B707D for ; Wed, 18 Apr 2012 06:12:43 +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=1335298364; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:From:To:Mail-Followup-To:Cc:Subject:References:Date: In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type: Content-Transfer-Encoding:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=B0oPiyIZCfs4NFXVItGX/w2rvYU=; b=G8ZtMaei3TG0kVf TzMPlN5jjvlnET8BlhgedyQ7aLRn/3TeGh0YpDxZ3mx/puXuTCKy/TND0QlYBB1+ loYw3KCq+SZmt6PWI5k59wEQGWCv83lpifKtew/2kZnTqfi4FLiq5YeVT49uGGif xcHxq6c9BNa6au7irEykLqnz5qXk= 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:Received:Received:From:To:Mail-Followup-To:Cc:Subject:References:Date:In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=swmNR1TMF+0IS48TH1/xz1680uHO9fPHgavvppNM1LLKKxk+U6Vw1meHYkOVMs aJyhxDEn5tPnzAQTmc04qFdVIb2DDXwJbXDrlP47GT5uTKq+BmZXd34FIgMz2Nzw iX5WUc4dMahjxwD29FCopAs3/Aeb3o/RhLuP2TDt520GA=; Received: (qmail 23527 invoked by alias); 17 Apr 2012 20:12:22 -0000 Received: (qmail 23502 invoked by uid 22791); 17 Apr 2012 20:12:19 -0000 X-SWARE-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, KHOP_RCVD_TRUST, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com) (209.85.212.179) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Apr 2012 20:11:41 +0000 Received: by wibhn6 with SMTP id hn6so866490wib.8 for ; Tue, 17 Apr 2012 13:11:39 -0700 (PDT) Received: by 10.180.107.132 with SMTP id hc4mr31392426wib.21.1334693499646; Tue, 17 Apr 2012 13:11:39 -0700 (PDT) Received: from localhost (rsandifo.gotadsl.co.uk. [82.133.89.107]) by mx.google.com with ESMTPS id 6sm29202742wiz.1.2012.04.17.13.11.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Apr 2012 13:11:38 -0700 (PDT) From: Richard Sandiford To: "H.J. Lu" Mail-Followup-To: "H.J. Lu" , gcc-patches@gcc.gnu.org, rdsandiford@googlemail.com Cc: gcc-patches@gcc.gnu.org Subject: Re: RFA: Clean up ADDRESS handling in alias.c References: <87y5pxxc6e.fsf@talisman.home> Date: Tue, 17 Apr 2012 21:11:37 +0100 In-Reply-To: (H. J. Lu's message of "Tue, 17 Apr 2012 11:27:42 -0700") Message-ID: <878vhuktja.fsf@talisman.home> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) 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 "H.J. Lu" writes: > On Sun, Apr 15, 2012 at 8:11 AM, Richard Sandiford > wrote: >> The comment in alias.c says: >> >>   The contents of an ADDRESS is not normally used, the mode of the >>   ADDRESS determines whether the ADDRESS is a function argument or some >>   other special value.  Pointer equality, not rtx_equal_p, determines whether >>   two ADDRESS expressions refer to the same base address. >> >>   The only use of the contents of an ADDRESS is for determining if the >>   current function performs nonlocal memory memory references for the >>   purposes of marking the function as a constant function.  */ >> >> The first paragraph is a bit misleading IMO.  AFAICT, rtx_equal_p has >> always given ADDRESS the full recursive treatment, rather than saying >> that pointer equality determines ADDRESS equality.  (This is in contrast >> to something like VALUE, where pointer equality is used.)  And AFAICT >> we've always had: >> >> static int >> base_alias_check (rtx x, rtx y, enum machine_mode x_mode, >>                  enum machine_mode y_mode) >> { >>  ... >>  /* If the base addresses are equal nothing is known about aliasing.  */ >>  if (rtx_equal_p (x_base, y_base)) >>    return 1; >>  ... >> } >> >> So I think the contents of an ADDRESS _are_ used to distinguish >> between different bases. >> >> The second paragraph ceased to be true in 2005 when the pure/const >> analysis moved to its own IPA pass.  Nothing now looks at the contents >> beyond rtx_equal_p. >> >> Also, base_alias_check effectively treats all arguments as a single base. >> That makes conceptual sense, because this analysis isn't strong enough >> to determine whether arguments are base values at all, never mind whether >> accesses based on different arguments conflict.  But the fact that we have >> a single base isn't obvious from the way the code is written, because we >> create several separate, non-rtx_equal_p, ADDRESSes to represent arguments. >> See: >> >>  for (i = 0; i < FIRST_PSEUDO_REGISTER; i++) >>    /* Check whether this register can hold an incoming pointer >>       argument.  FUNCTION_ARG_REGNO_P tests outgoing register >>       numbers, so translate if necessary due to register windows.  */ >>    if (FUNCTION_ARG_REGNO_P (OUTGOING_REGNO (i)) >>        && HARD_REGNO_MODE_OK (i, Pmode)) >>      static_reg_base_value[i] >>        = gen_rtx_ADDRESS (VOIDmode, gen_rtx_REG (Pmode, i)); >> >> and: >> >>      /* Check for an argument passed in memory.  Only record in the >>         copying-arguments block; it is too hard to track changes >>         otherwise.  */ >>      if (copying_arguments >>          && (XEXP (src, 0) == arg_pointer_rtx >>              || (GET_CODE (XEXP (src, 0)) == PLUS >>                  && XEXP (XEXP (src, 0), 0) == arg_pointer_rtx))) >>        return gen_rtx_ADDRESS (VOIDmode, src); >> >> I think it would be cleaner and less wasteful to use a single rtx for >> the single "base" (really "potential base"). >> >> So if we wanted to, we could now remove the operand from ADDRESS and >> simply rely on pointer equality.  I'm a bit reluctant to do that though. >> It would make debugging harder, and it would mean either adding knowledge >> of this alias-specific code to other files (specifically rtl.c:rtx_equal_p), >> or adding special ADDRESS shortcuts to alias.c.  But I think the code >> would be more obvious if we replaced the rtx operand with a unique id, >> which is what we already use for the REG_NOALIAS case: >> >>      new_reg_base_value[regno] = gen_rtx_ADDRESS (Pmode, >>                                                   GEN_INT (unique_id++)); >> >> And if we do that, we can make the id a direct operand of the ADDRESS, >> rather than a CONST_INT subrtx[*].  That should make rtx_equal_p cheaper too. >> >>  [*] I'm trying to get rid of CONST_INTs like these that have >>      no obvious mode. >> >> All of which led to the patch below.  I checked that it didn't change >> the code generated at -O2 for a recent set of cc1 .ii files.  Also >> bootstrapped & regression-tested on x86_64-linux-gnu.  OK to install? >> >> To cover my back: I'm just trying to rewrite the current code according >> to its current assumptions.  Whether those assumptions are correct or not >> is always open to debate... >> >> Richard >> >> >> gcc/ >>        * rtl.def (ADDRESS): Turn operand into a HOST_WIDE_INT. >>        * alias.c (reg_base_value): Expand and update comment. >>        (arg_base_value): New variable. >>        (unique_id): Move up file. >>        (unique_base_value, unique_base_value_p, known_base_value_p): New. >>        (find_base_value): Use arg_base_value and known_base_value_p. >>        (record_set): Document REG_NOALIAS handling.  Use unique_base_value. >>        (find_base_term): Use known_base_value_p. >>        (base_alias_check): Use unique_base_value_p. >>        (init_alias_target): Initialize arg_base_value.  Use unique_base_value. >>        (init_alias_analysis): Use 1 as the first id for REG_NOALIAS bases. >> > > This breaks bootstrap on Linux/x86: > > > home/regress/tbox/native/build/./gcc/xgcc > -B/home/regress/tbox/native/build/./gcc/ > -B/home/regress/tbox/objs/i686-pc-linux-gnu/bin/ > -B/home/regress/tbox/objs/i686-pc-linux-gnu/lib/ -isystem > /home/regress/tbox/objs/i686-pc-linux-gnu/include -isystem > /home/regress/tbox/objs/i686-pc-linux-gnu/sys-include -g -O2 -O2 > -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual > -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition > -isystem ./include -fpic -g -DIN_LIBGCC2 -fbuilding-libgcc > -fno-stack-protector -fpic -I. -I. -I../.././gcc > -I/home/regress/tbox/svn-gcc/libgcc > -I/home/regress/tbox/svn-gcc/libgcc/. > -I/home/regress/tbox/svn-gcc/libgcc/../gcc > -I/home/regress/tbox/svn-gcc/libgcc/../include > -I/home/regress/tbox/svn-gcc/libgcc/config/libbid > -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o __main_s.o -MT > __main_s.o -MD -MP -MF __main_s.dep -DSHARED -DL__main -c > /home/regress/tbox/svn-gcc/libgcc/libgcc2.c > In file included from > /home/regress/tbox/svn-gcc/libgcc/unwind-dw2-fde-dip.c:79:0: > /home/regress/tbox/svn-gcc/libgcc/unwind-dw2-fde.c: In function 'search_object': > /home/regress/tbox/svn-gcc/libgcc/unwind-dw2-fde.c:997:1: internal > compiler error: Segmentation fault > } > ^ > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > make[3]: *** [unwind-dw2-fde-dip.o] Error 1 > make[3]: *** Waiting for unfinished jobs.... > make[3]: Leaving directory > `/home/regress/tbox/native/build/i686-pc-linux-gnu/libgcc' > make[2]: *** [all-stage1-target-libgcc] Error 2 > make[2]: Leaving directory `/home/regress/tbox/native/build' > make[1]: *** [stage1-bubble] Error 2 > make[1]: Leaving directory `/home/regress/tbox/native/build' > make: *** [bootstrap] Error 2 Gah, sorry, the perils of testing on a 64-bit host. This patch seems to fix it. Applied after getting past the stage 1 failure. Richard gcc/ PR bootstrap/53021 * rtl.c (rtx_code_size): Handle ADDRESS. Index: gcc/rtl.c =================================================================== --- gcc/rtl.c 2012-04-17 21:07:55.000000000 +0100 +++ gcc/rtl.c 2012-04-17 21:07:55.524619837 +0100 @@ -110,7 +110,8 @@ #define DEF_RTL_EXPR(ENUM, NAME, FORMAT, const unsigned char rtx_code_size[NUM_RTX_CODE] = { #define DEF_RTL_EXPR(ENUM, NAME, FORMAT, CLASS) \ - ((ENUM) == CONST_INT || (ENUM) == CONST_DOUBLE || (ENUM) == CONST_FIXED\ + (((ENUM) == CONST_INT || (ENUM) == CONST_DOUBLE \ + || (ENUM) == CONST_FIXED || (ENUM) == ADDRESS) \ ? RTX_HDR_SIZE + (sizeof FORMAT - 1) * sizeof (HOST_WIDE_INT) \ : RTX_HDR_SIZE + (sizeof FORMAT - 1) * sizeof (rtunion)),