PATCH: pa8000-specific changes

[Jeffrey A Law]

  In message <199903261418.GAA04096@cygnus.com>you write:
  > I forgot a changelog entry for my patch.  Here it is:
  > 
  > Fri Mar 26 09:12:38 EST 1999  Jerry Quinn <jquinn@nortelnetworks.com>
  > 
  > 	* pa.c (pa_adjust_cost): Don't do cost adjustments on pa8000.
  > 		(pa_reorg): Don't call pa_combine_instructions on pa8000.
I've installed this patch.


  > 	* pa.h (HAVE_PRE_INCREMENT, HAVE_PRE_DECREMENT, HAVE_POST_INCREMENT,
  > 		HAVE_POST_DECREMENT):  turn off for pa8000.
Hmmm.  This is probably OK, but I want to look at it a little more closely.

The concern is that GO_IF_LEGITIMATE_ADDRESS still accepts auto-inc addresses
and that our prologue/epilogue code will still generate auto-inc addresses.

I'm pretty sure the HAVE_* will do what we initially want (stop the machine
independent parts of the compiler from generating autoincs), but I want a
little time to think it through.


  > 	* pa.md (pa7100LCshiftmem, pa7100LCalu): Change simultaneity.  Use
  > 		shift/mem ops in pa7100LCalu.
I'm hoping to get this evaluated today.  I had to fix the Fortan compiler
first so that I could actually run spec :-)  It seems like the right thing
to do, so even if it's performance neutral, we'll go with it.


A few more thoughts on PA8000 codegen issues:

  Our prologue/epilogue code still generates autoincrement addresses when
  setting up a frame pointer and when storing FP values.  We may want to
  tweak PA8000 code generation in the prologues/epilogues slightly to avoid
  these sequences.

  The jump-in-call-delay slot optimization is rather unfriendly to the branch
  prediction scheme found on the PA8000 cpus.  We may want to disable it when
  scheduling for a PA8000.

  The branch penality on a PA8000 is quite a bit higher than previous chips.
  We may want to experiment with increasing BRANCH_COST.

  The code we generate for switch tables is rather unfriendly to the branch
  predictors.  We may want to revamp it.


jeff