Re: [PATCH] ia64: fix regression from fix for PR/803

["Jan Beulich" <JBeulich at novell dot com>]

>We will get a lot more M nops this way, but that is probably a good
>thing since we have 4 M issue slots and only 2 I issue slots.  I
suspect
>this would result in more dual issued bundles.  Hard to say without
>doing an experiment though.

Doing an experiment wouldn't necessarily help, since the 'best choice'
depends on more aspects. Generally, I don't think looking ahead just
three instructions here is sufficient, the choice should really be based
on the entire remaining issue group (or as much of it as can be issued,
that is at most 6 instructions at present, without knowing whether
Madison or Montecito have a wider window) and the units the subsequent
insns can be issued to (so to neither needlessly use I-unit nops when
further down there are I-type insns, nor use M-unit nops when further
down there are insns that cannot issue to M2/M3).
The question thus only is whether preferring M-nops over I-nops is
going to do any good meanwhile. H.J., do you have a particular
preference here?

>While looking at this, I noticed that the comment before
extra_goodness
>is out-of-date.  HJ forgot to update it when he changed the code. 
Also,
>I wanted to double check that the result was OK, so I added some
>debugging code to print out the best_template array, so I could make
>sure it was OK after this change.  I've attached the patch I wrote
for
>this.  I plan to check this in after you check in your patch.

I don't think this

>+   /* For debugging changes to the best_template calculations.  We
don't care
>+      about combinations with invalid instructions, so start the
loops at 1.  */

is correct. We *do* care for them when at the end, we don't care for
them only when followed by valid instructions. I had added similar code
temporarily; I didn't offer it with the patch because there seems to be
a policy of having no #if-0-framed code (there was some cleanup done
recently to that respect; I personally don't agree to such a policy, in
various occasions such code may prove useful).

Jan