This is the mail archive of the
mailing list for the binutils project.
RE: [PATCH] MIPS SIMD Architecture (MSA) patch
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Chao-Ying Fu <Chao-Ying dot Fu at imgtec dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Tue, 8 Oct 2013 20:18:12 +0100
- Subject: RE: [PATCH] MIPS SIMD Architecture (MSA) patch
- Authentication-results: sourceware.org; auth=none
- References: <81D57523CB07B24881D63DE650C6ED82019034B4 at BADAG02 dot ba dot imgtec dot org> <alpine dot DEB dot 1 dot 10 dot 1310081252290 dot 6696 at tp dot orcam dot me dot uk> <81D57523CB07B24881D63DE650C6ED8201903803 at BADAG02 dot ba dot imgtec dot org>
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.
> > 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
> > 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.