Re: my EGCS status (really Fortran patches)

[Jeffrey A Law <law@cygnus.com>]

  In message < 9710230552.AA21715@moene.indiv.nluug.nl >you write:
  > [ I once saw HP-PA assembler before, about a year ago, because  
  > someone complained to the g77-bug list that he couldn't get Fortran  
  > code with assigned goto's to assemble - turned out the HP assembler  
  > can't cope with forward labels in instructions other than jumps.  So  
  > take this with a grain of salt ]
Almost -- it can't deal with temporary labels in non-jump instructions :-)

  > I gather, from looking at this code that instructions ending in .ma  
  > do (implicit) post-increment addressing ?
",ma" is a postmodify (can be an increment or decrement)
",mb" is a premodify (can be an increment or decrement)

  > lot: The instructions normally associated with updating address  
  > registers can be interspersed between the floating point ops, which  
  > is a win on a CPU that has separate integer and floating point  
  > units.
Exactly.  However, on this model PA the inner loop should run no
slower if we use autoincrement insns to update the pointers instead
of explcit address computation instructions.  This is true for.
PAs except PA8000 based systems.

And, having thought of this already, I've already tested it on
tomcatv (which is where that sample code came from).

autoinc !use	  autoinc use	!autoinc !use	  !autoinc use

  11.5		     12.5	     11.5	      12.5

ie, use of autoinc makes no difference for this code, which isn't
a suprise.

  > aren't explicit.  On the m68k post-increment addressing is a real  
  > win, because you're actually saving instructions.
It's really a win most of the time on HPs too -- but this code is
so FP intensive that the explicit insns to increment the pointers
are completely hidden in pipeline bubbles waiting on memory and
the FP unit.

  > I don't see a simple way out of this.
We haven't necessarily hit the root of the problem yet, so this
conclusion is premature.

The more I think about it the more I bet the poor giv combination
code is the culprit.

Take the example I gave -- we've added 14 insns in the outer loop.
At best they will execute in 7 cycles on this machine.  Furthermore,
let's assume the inner loops gains are somewhere between minimal
and none because they're dominated by FP/memory latency -- which
means we've burned 7 cycles in the outer loop for almost no gain
in the inner loop.

jeff