From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83982 invoked by alias); 17 Apr 2019 01:32:27 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 83974 invoked by uid 89); 17 Apr 2019 01:32:27 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-14.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=chase, H*f:sk:orftqiw, H*i:sk:orftqiw, HX-Spam-Relays-External:209.85.210.194 X-HELO: mail-pf1-f194.google.com Received: from mail-pf1-f194.google.com (HELO mail-pf1-f194.google.com) (209.85.210.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 17 Apr 2019 01:32:25 +0000 Received: by mail-pf1-f194.google.com with SMTP id i17so11278324pfo.6 for ; Tue, 16 Apr 2019 18:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=emApIutxCPd84KfiqX1MaLUrIR09yuOJ97mPu9qeLvI=; b=KvKuuG0sN9pR+63OGNWxocHr4TLtObideWtXwnvsAa80fn41XiIeZxYl+PfTia3lLx r0Ca46TvSeaoCHzQjTl1X/UnGq3qkO8GfcH7qZDmyntHpbC0JgXZb+TMKkDP9lIofzhL xCYZF/nNR8/4m17rpJtzOLmSaSV67csTE11zhnQnvx5jd+nPu8rM7LXHdxfgKTLpAkfE ZZ7qt+8QtwmhdeJpx/+71fqi7sGIlRGIrXFGr/uU5AM6nXsamc0wX+yiOMX7EVKpawjs xDF5nQA3FFYxaktBkMPq98xv1gMoAMHw3HvRp4keIka6T7FqknY8VYrGTbAYATNaCc5W du3g== Return-Path: Received: from bubble.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id z21sm75081020pfn.139.2019.04.16.18.32.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 16 Apr 2019 18:32:22 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 61FF782E5B; Wed, 17 Apr 2019 11:02:18 +0930 (ACST) Date: Wed, 17 Apr 2019 01:32:00 -0000 From: Alan Modra To: Alexandre Oliva Cc: binutils@sourceware.org Subject: Re: [PR24444] speed up locview resolution wiht relaxable frags Message-ID: <20190417013218.GA14424@bubble.grove.modra.org> References: <20190414132247.GO14424@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00196.txt.bz2 On Tue, Apr 16, 2019 at 10:24:04AM -0300, Alexandre Oliva wrote: > On Apr 14, 2019, Alan Modra wrote: > > > Yes, I believe so. In fact, fr_fix is really unsigned. Also, it is > > an error for rs_org frags to go backwards. > > Nice, that makes things simpler. > > >> Tested on x86_64-linux-gnu, native and cross to xtensa-elf. No new > >> testcase; the issue was just performance, not output correctness. Ok to > >> install? > > > Um, the testcase object file after this patch differs from the > > original. First readelf -wi difference shown below. > > Which testcase was that? I didn't catch that one. The https://sourceware.org/bugzilla/show_bug.cgi?id=24444 reproducer attachment. I see differences in DW_AT_GNU_entry_view, in all cases substituting 3 for 10, or 2 for 9 (lower number after your patch). I don't know enough to say whether this is a reasonable result. > > >> + /* If any frag from frag2, inclusive, to frag1, exclusive, has a > >> + nonzero fixed length, the addresses won't be the same as long as > >> + we reach frag1. */ > >> + bfd_boolean maybe_same_addr = off1 == 0 && off2 == (valueT)frag2->fr_fix; > > > Ins't it true that if the symbol offsets are not at exactly the above > > values, then you already know the result and there's no need to > > traverse the frags? This is assuming you can't .org backwards, which > > is the case. > > Not entirely, no. Although the comments state we assume a certain > ordering of frags, the assumption is only valid for O_gt operations > arising from the location view machinery. It doesn't hurt if we resolve > other O_gt operations if we can find the result, but those could have > frags in the opposite order. Thanks for reminding me. I wrote that comment before writing the simplification of your patch, and there you'll note I did chase down the second frag.. > Now, O_gt is not exactly the operation the location view machinery > needs; O_ne (or, after negation, O_eq) would be more like it. IIRC the > reason I went for O_gt was just that it was resolved early in a lot more > cases than O_eq. Now, with this kind of fallback, we could actually > introduce another operation kind that (i) resolves to zero if frags are > not in the same (sub)section, and (ii) can safely make the optimization > you suggested for frags in the same (sub)section, with the extra benefit > that we know we won't ever search all the way to the end of the frag > linked list without finding the other frag: we could assert-check that, > and stop the search at the first nonzero-fr_fix. > > Would a new op with this semantics (O_incview?, vs reset view) be > preferred? No, if O_gt works let's go with that. > > The following makes the changes I'm suggesting, and simplifies a few > > more things. > > Thanks, I'll wait for a response to the question above before taking > further action on this, but I'll likely integrate your change (credited > in the ChangeLog) in the patch regardless. -- Alan Modra Australia Development Lab, IBM