Re: Fix for parallel_ok in d10v assembler

[Michael Meissner <meissner at cygnus dot com>]

On Mon, Dec 04, 2000 at 05:27:21PM -0800, Matthew Hiller wrote:
> On Mon, 4 Dec 2000, Nick Clifton wrote:
> 
> > This does not look right.  If the brf0t.s instruction cannot be
> > parallelized then it should have the ALONE attribute set (in
> > opcodes/d10v-opc.c).  That is the point of that attribute.  It should
> > not be necessary to add tests for the BRANCH attribute in parallel_ok.
> 
> 	Not precisely. It's perfectly okay for brf0t.s to be in a
> sequenced packed instruction, which ALONE doesn't allow for. e.g., in the
> testcase that I'm working with,
> 
> brf0t.s 14 <func_a+0x4> ->      mv      r0, r2
> 
> 	It's just not okay for it to appear in a in a parallel packed
> instruction, e.g.,
> 
> brf0t.s 14 <func_a+0x4> ||      mv      r0, r2
> 
> 	Without the check for the BRANCH attribute, when the assembler is
> run with -O, it will wrongly decide that the sequence can be put in a
> parallel packed instruction rather than a sequential.

What are the instructions given to the assembler, is it:

	brf0t.s <xx>
	mv r0, r2

or

	mv r0, r2
	brf0t.s <xx>

If it were the later, it should be ok to pack the instructions as:

	brf0t.s <xx> || mv r0, r2

It is not ok to pack the former instructions in that order, unless you can
guarantee that r0 is not live at <xx>.  If that is the case, then your patch
should just check op1 for being a branch, and not check op2.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482