This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
RE: [PATCH] MIPS SIMD Architecture (MSA) patch
- From: Chao-Ying Fu <Chao-Ying dot Fu at imgtec dot com>
- To: "'Maciej W. Rozycki'" <macro at codesourcery dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Tue, 8 Oct 2013 20:25:44 +0000
- 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> <alpine dot DEB dot 1 dot 10 dot 1310082010400 dot 12843 at tp dot orcam dot me dot uk>
Maciej W. Rozycki wrote:
>
> > > 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.
Yes. I will add a new abi_msa_bfd variable. Thanks!
>
> > > 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.
I will try to add the branch relaxation support. Thanks!
Regards,
Chao-ying