From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1985 invoked by alias); 8 Oct 2013 19:18:26 -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 1968 invoked by uid 89); 8 Oct 2013 19:18:26 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 08 Oct 2013 19:18:25 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1VTcnV-0005yU-Rb from Maciej_Rozycki@mentor.com ; Tue, 08 Oct 2013 12:18:21 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Oct 2013 12:18:21 -0700 Received: from [172.30.64.107] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Tue, 8 Oct 2013 20:18:19 +0100 Date: Tue, 08 Oct 2013 19:18:00 -0000 From: "Maciej W. Rozycki" To: Chao-Ying Fu CC: "binutils@sourceware.org" Subject: RE: [PATCH] MIPS SIMD Architecture (MSA) patch In-Reply-To: <81D57523CB07B24881D63DE650C6ED8201903803@BADAG02.ba.imgtec.org> Message-ID: References: <81D57523CB07B24881D63DE650C6ED82019034B4@BADAG02.ba.imgtec.org> <81D57523CB07B24881D63DE650C6ED8201903803@BADAG02.ba.imgtec.org> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-10/txt/msg00091.txt.bz2 On Tue, 8 Oct 2013, Chao-Ying Fu wrote: > > Do you plan to release microMIPS instruction encoding > > documentation as > > well? > > We will need probably two weeks to revise and publish the microMIPS MSA spec > to the imgtec website. Please wait. Great! > > Is the use of MSA and FP operations in a single binary mutually > > exclusive? If so, then you need to check for conflicting > > use. If not, > > then you need to use a separate variable/struct member to > > remember and > > report the first significant MSA BFD; abi_msa_bfd seems the > > likely name > > candidate. > > MSA and FP instructions can co-exist in a single binary. > Or, only MSA instructions exist in a single binary, theoretically. > Ex: We only use the integer SIMD instructions, and move data > between MSA registers and integer registers. > I want to keep the FP gnu attribute code as-is, and don't check > if the MSA gnu attribute may conflict with the FP gnu attribute. > My intention is that the only usage of MSA gnu attribute is to tell if this > binary uses 128-bit MSA. OK, so you do need that separate abi_msa_bfd variable/struct member to keep the two sets of attributes separate. The reason is the first BFD that sets the FP attribute may not be the same one that sets the MSA attribute. > > Also I've noticed the MSA module adds new branch > > instructions -- have you > > wired them into our branch relaxation support (GAS's --relax-branch > > option) -- if it's at all possible? Assuming that it is, > > then it's OK, at > > least initially, as far as I am concerned, if you did not, > > but either way > > please add some test coverage, following either relax.? or > > relax-bc1any.? > > from gas/testsuite/gas/mips/ as applicable. > > I haven't added branch relaxation support. I think all possible MSA branches are there, > so it should be ok to support branch relaxation. Need to work on it. Great! -- if you can do it shortly, then I think it would be a wasted effort to make a test case to cover the current semantics and providing a test case with a follow-up patch will be fine. If you think however, that you may not be able to implement branch relaxation soon, then please cook up a quick test case to have current code covered. Maciej