From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94825 invoked by alias); 21 Jun 2016 22:09:07 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 94582 invoked by uid 89); 21 Jun 2016 22:09:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=unavailable version=3.3.2 spammy=dwarf2out.c, dwarf2outc, UD:dwarf2out.c, recognizing X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 21 Jun 2016 22:09:03 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9817346267; Tue, 21 Jun 2016 22:09:02 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-31.rdu2.redhat.com [10.10.116.31]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5LM91lE011393; Tue, 21 Jun 2016 18:09:01 -0400 Subject: Re: RFA: Generate normal DWARF DW_LOC descriptors for non integer mode pointers To: Nick Clifton , gcc-patches@gcc.gnu.org References: <87h9dyt7m3.fsf@redhat.com> <1c7da1c8-c088-6c35-dbc8-bacebd4ad4d0@redhat.com> <344916c2-c8d0-9a4b-1fc4-0b8035276ea6@redhat.com> <9f8e1f36-5186-67bc-898e-6910e0d041a6@redhat.com> <424fe5c1-a849-6d4d-fdca-ac531e8ee53b@redhat.com> Cc: gdb-patches@sourceware.org From: Jeff Law Message-ID: Date: Tue, 21 Jun 2016 22:09:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <424fe5c1-a849-6d4d-fdca-ac531e8ee53b@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-06/txt/msg00368.txt.bz2 On 05/26/2016 10:16 AM, Nick Clifton wrote: > Hi Jeff, > >>>> I may be missing something, but isn't it the transition to an FP >>>> relative address rather than a SP relative address that's the problem >>>> here? >>> >>> Yes, I believe so. >>> >>>> Where does that happen? > > I think that it happens in dwarf2out.c:based_loc_descr() which > detects the use of the frame pointer and works out that it is going > to be eliminated to the stack pointer: > > /* We only use "frame base" when we're sure we're talking about the > post-prologue local stack frame. We do this by *not* running > register elimination until this point, and recognizing the special > argument pointer and soft frame pointer rtx's. */ > if (reg == arg_pointer_rtx || reg == frame_pointer_rtx) > { > rtx elim = (ira_use_lra_p > ? lra_eliminate_regs (reg, VOIDmode, NULL_RTX) > : eliminate_regs (reg, VOIDmode, NULL_RTX)); > > if (elim != reg) > ..... > > The problem, I believe, is that based_loc_descr() is only called > from mem_loc_descriptor when the mode of the rtl concerned is an > MODE_INT. For example: > > case REG: > if (GET_MODE_CLASS (mode) != MODE_INT > [...] > else > if (REGNO (rtl) < FIRST_PSEUDO_REGISTER) > mem_loc_result = based_loc_descr (rtl, 0, VAR_INIT_STATUS_INITIALIZED); > > or, (this is another one that I found whilst investigating this > problem further): > > case PLUS: > plus: > if (is_based_loc (rtl) > && (GET_MODE_SIZE (mode) <= DWARF2_ADDR_SIZE > || XEXP (rtl, 0) == arg_pointer_rtx > || XEXP (rtl, 0) == frame_pointer_rtx) > && GET_MODE_CLASS (mode) == MODE_INT) > mem_loc_result = based_loc_descr (XEXP (rtl, 0), > INTVAL (XEXP (rtl, 1)), > VAR_INIT_STATUS_INITIALIZED); > else > > > There are quite a few places in mem_loc_descriptor where the code checks > for the mode being in the MODE_INT class. I am not exactly sure why. I > think that it might be that the programmer thought that any expression that > does not involve integer based arithmetic cannot be expressed in DWARF CFA > notation and so would have to be handled specially. If I am correct, > then it seems to me that the proper fix would be to use SCALAR_INT_MODE_P > instead. > > I tried out the extended patch (attached) and it gave even better GDB > results for the MSP430 and still no regressions (GCC or GDB) for MSP430 or > x86_64. > > Is this enough justification ? So the argument is that MODE_INT was likely intended to filter out things like FP modes and such that might somehow be bogusly used as addresses. As written those tests are also filtering out partial integer modes which we can support? And that many (most?) of the things that filter on MODE_INT should really be using MODE_INT || MODE_PARTIAL_INT (aka SCALAR_INT_MODE_P). I can buy that ;-) OK with a suitable ChangeLog entry. jeff