From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19745 invoked by alias); 16 Dec 2010 11:16:54 -0000 Received: (qmail 19736 invoked by uid 22791); 16 Dec 2010 11:16:53 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 16 Dec 2010 11:16:49 +0000 Received: (qmail 25581 invoked from network); 16 Dec 2010 11:16:45 -0000 Received: from unknown (HELO pl.orcam.me.uk) (macro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 16 Dec 2010 11:16:45 -0000 Date: Thu, 16 Dec 2010 11:54:00 -0000 From: "Maciej W. Rozycki" To: Richard Sandiford cc: Ilie Garbacea , Joseph Myers , binutils@sourceware.org, Chao-ying Fu , Rich Fuhler , David Lau , Kevin Mills , Catherine Moore , Nathan Sidwell , Nathan Froyd Subject: Re: [PATCH] MIPS: microMIPS ASE support In-Reply-To: Message-ID: References: <87y6fa9u3t.fsf@firetop.home> <876302kqvu.fsf@firetop.home> <871v5n9m7e.fsf@firetop.home> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 X-SW-Source: 2010-12/txt/msg00506.txt.bz2 On Tue, 14 Dec 2010, Richard Sandiford wrote: > > Yes, I think it will make it easier for us both to keep track of what has > > been addressed and what not. I have no technical problem with including > > further changes in a separate patch. > > Thanks. For avoidance of doubt, please make any updates (with the FIXMEs > fixed, for instance), relative to the original. Yes, this is what I assumed too. > > Undefined weak symbols are, well, undefined, so they have resolved to nil > > and are meant never to be jumped to, so we don't want to error out on them > > just because they do not have the ISA bit set and a JALX therefore > > required could not be used for some reason, like the invocation being a > > sibling call or because it would not satisfy the fixed delay slot > > dependency. > > OK, makes sense. Please update the comment to something like: > > /* Calls from 16-bit code to 32-bit code and vice versa require the > mode change. However, we can ignore calls to undefined weak symbols, > which should never be executed at runtime. This exception is important > because the assembly writer may have "known" that any definition of the > symbol would be 16-bit code, and that direct jumps were therefore > acceptable. */ Done, thanks. > > Only link variations of branches and jumps have a fixed-size delay slot > > -- that's because the link register is set to a fixed offset from the > > delay-slot instruction (either four as with JAL or two as with JALS). Of > > all such jumps and branches only JALX does not have a JALXS counterpart > > (regrettably, as it would have made life of software much, much easier). > > > > I've explained the meaning of 0 below -- it's unsafe to return this value > > for a variable-size delay slot. > > Hmm, I was thinking of the case where there was no branch _after_ > the LUI, and where the instruction after the LUI could then become > the delay slot for a variable-length branch before the (deleted) LUI. > But yeah, I can see that 0 isn't correct if there is a branch immediately > after the LUI. Well, if we have code like this: branch ... LUI ... insn [...] (where for the purpose of this consideration BRANCH may also be a jump) then LUI cannot be entirely deleted and INSN moved into the slot of BRANCH no matter if INSN is a branch or an computational instruction. All we can do in this case is to see if there is a corresponding BRANCHC instruction and use it to swap BRANCH with and then delete the LUI if so, or otherwise shrink the LUI to a 16-bit NOP if BRANCH permits or can be swapped with BRANCHS to permit a 16-bit delay-slot instruction. If neither is possible, then the LUI is merely substituted with a 32-bit NOP (although the effect is purely cosmetical in this case; perhaps we should just back out). Also with the recent update to LUI relaxation code I think we should simply disallow the optimisation if a LUI is in a delay slot of an unconditional branch -- we have no way to verify the corresponding LO16 reloc really belongs to this LUI instruction in that case. This will let us simplify code (which has become a little bit hairy by now IMO) a little bit I would guess. [FIXME] > > Hmm, we could do this in two passes over the reloc table (still O(n)) and > > first make a fast auxiliary data structure (e.g. a hash) to keep addresses > > of branch and jump relocations. Given linker relaxation is off by default > > I'd vote for this as a future improvement. > > Yeah, I'd wondered about that, but then we'd need to measure whether that > made things better or not. I'm OK with leaving it. The breaking point may be high -- we'd have to benchmark a program with a suitably high number of relocations to decide whether to go for that at all. And then perhaps only enable the optimisation selectively at the run time, based on the size of the reloc table and the expected density of HI16/LO16 reloc pairs within. And even then, in a typical compilation there are relatively few final links, so shaving a couple of seconds off a compilation that otherwise takes half a dozen of minutes may be missing the point. Maciej