Re: Heads up

[Jeffrey A Law <law at cygnus dot com>]

  In message <9906171504.AA49806@marc.watson.ibm.com>you write:
  > cared that I knew (:^).  I was trying a number of ways to fix it.  One way
  > to look at the problem is that there is no way to fail in
  > GO_IF_LEGITIMATE_ADDRESS if the pseudo is assigned to a GPR versus an FPR.
Right.  This is highly unlikely to change in the near future.  I've always
claimed this was a losing behavior (it causes huge problems on the PA), but
fixing it is a fairly complex problem.

  > The predicate also is irrelevant by this point.
Yup.

  >  Basically there does not
  > seem to be any hook to tell the backend not to create an indexed address
  > mode RTL in this particular case.
Well, stop accepting reg+reg in GO_IF_LEGITIMATE_ADDRESS for DFmode memory
references.  But that's rather drastic.

If we continue to accept such addresses, then we have to support them
in the DFmode patterns.  No ifs ands or buts about it.  That's just life.


  > 	It looked to me like the only solution is breaking these type of
  > instructions using splitters.  That probably is a better idea all around
  > as these instruction pairs hide information from the scheduler and end up
  > with worse performance.  These types of patterns always have been and not
  > a good method for implementing this functionality.
Possibly.  Or do what every other port does.  When faced with an unoffsettable
address adjust one of the two registers, perform the ops, the anti-adjust
the base register.

You only have to do this when the address is not offsettable, so the 
performance
impact is relatively small.

You can do this either in the pattern itself or with a special splitter that
emits the memref #1, adjust base, memref #2, anti-adjust base or something
similar.

We know that we can get reg+reg in this case.  Is it possible to get auto-inc
addresses too?  Are there any others we can get that are not offsettable?

jeff