This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH] MIPS SIMD Architecture (MSA) patch

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!


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]