Re: How to clean up i386 machine description?

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

  In message <19981030103233.05281@horac.ta.jcu.cz>you write:
  > OK, this seems to be good idea and one of thinks I plan to do :)
And you should see an example of how to use splitting to more accurately
describe how some of the more complex instructions work (see my message about
the SIGN_EXTEND patterns).

  > (BTW yesterday I've sent small patch modifing some predicates. It generally
  > don't split just uses correct predicates IMO (like nonimmediate_operand
  > instead of general_operand where possible, so it is more readable and
  > surprisingly seems to improve output code)
Thanks.  I haven't had a chance to look at it in any detail yet.

It's not a suprise -- this is precisely the problem we're talking about.  When
the predicates accept things which the processor can not actually do, we will
rely on reload to move values around in/out of registers, memory, etc.

It is generally better to tighten the predicates and force the RTL generation
phase to do all this data movement.  By exposing all this data movement
earlier, we give the various optimizers a chance to improve the code.  It
also exposes more of what code really needs to be generated to the schedulers.

Furthermore, the tighter predicates prevent combine and other passes from
un-doing expansions made by the tree->rtl generation.

ie, given this

	match_operand:SI 0 "general_operand" "ri"

it is better to write:

	match_operand:SI 0 "nonmemory_operand" "ri"


  > I've already split some patterns in way you describe, but I was unsure if
  > it is good idea. .info says it isn't, because reload can change register
  > to constant but keep the register version. So it says it is generally
  > better  to use general addition pattern instead of inc pattern.
  > Is this still relevant? 
Most of the time tightening the predicates to more closely match the machine
is going to win.  That's become a rule of thumb for most new ports.  There
are sometimes exceptions, but they're becoming rare.


  > Can you explain me the problem in some detail?
It's difficult to explain.  Again, the general rule of thumb is to make the
predicate match the hardware more closely.  Exceptions exist, but they are
analyzed on a case by case basis.


  > I've for example made the incrementation pattern, since it has different
  > scheduling parameters, but I've kept the incrementation code in original
  > pattern too to be sure. May I remove it?
I'd have to see exactly what you've done.

If you have a more specific pattern, then you should put it first.  Your
general pattern may (or may not) still need to handle the case that is
in the specific pattern -- it depends on a variety of factors.

jeff