On Thu, 2005-02-17 at 10:47, H. J. Lu wrote:
> On Wed, Feb 16, 2005 at 08:43:11PM -0800, H. J. Lu wrote:
> > Unfortunately, it is trickier than I thought. With 2.6 kernel, my
> > old change works OK. My new change doesn't work. Jim, do you have
> > any suggestions?

An option here is to make it a warning by default, which I mentioned in
my earlier message, and which is what we have done with almost all of
the other new diagnostics.

> I think it is OK to change unit when manual bundling is off there is no
> user template. I am testing 2.4 and 2.6 kernel build now.

Yes, this is true.  However, I see other problems here.

Forcing the hint to an I unit doesn't do what it appears to do.  Since B
slots are always at the end or followed by another B slot, the
instruction will not fit into the current bundle.  So we will fill the
current bundle with nops, and then come back to this loop again, at
which point we will have a different template, and the hint could very
well end up in a M or F slot, even though we tried to force it into an I
slot earlier.  This is potentially confusing.  There should at least be
a comment here saying that the purpose of this is to prevent the
instruction from going into the current slot.  It will go into a later
slot, at which point we may choose a different unit for it.

The asm source specifies a MIB template, but there is no MIB template in
the output.  I believe this is an assembler bug.  The problem arises
because the bundle before the MIB template is incomplete.  We should pad
it with nops, but instead we steal instructions from the MIB template,
and that causes us to lose track of the MIB template which is attached
to the nop.m instruction.  The result is a BBB template.  This is a
problem, because BBB templates use different less efficient branch
prediction.  That is presumably why the MIB template was specified in
the first place.  This needs to be fixed.

With that problem fixed, this problem goes away, as we are no longer
trying to force the hint instruction into a B slot.

Anyways, your patch is OK with the comment added that explains that we
are using insn_unit to force the hint insn to the next slot, instead of
forcing it into an I slot.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com