Re: SHIFT_COUNT_TRUNCATED

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

  In message <19981001161741.05689@atrey.karlin.mff.cuni.cz>you write:
  > Hi
  > I was fiddling a bit with instruction patterns for removing unnecesary
  > and at a<<(b&31) constructions at i386. Implementing this in machine
  > description (as suggested in info file) should require quite a lot
  > patterns (I have them all in md file). problem is that other common
  > case like a<<(32-b) should be simplified to a<<(-b), wich should not
  > be IMO handled nicely by md files and so on.
I believe this would normally be handled by defining SHIFT_COUNT_TRUNCATED.
Several ports do this to achieve those exact results.

Apparently we can't define it on the x86 -- based on this comment in i386.md.

;; On i386, the register count for a bit operation is *not* truncated,
;; so SHIFT_COUNT_TRUNCATED must not be defined.


One possible alternative would be to rewrite the bit patterns to truncate
the shift count, then define SHIFT_COUNT_TRUNCATED for the x86.

  > So I've been looking a bit at SHIFT_COUNT_TRUNCATED feature and I think
  > it should be extended to make macro that has two parameters (code and mode)
  > code should be ASHIFT etc amd mode shoud be DImode and so on.
I'm not sure this is completely necessary at this point.  I also suspect it'll
be difficult to get right.  Remember, it's not a cost, and if you miss a case,
then the compiler may generate incorrect code.

  > It should return mask, that target use to truncate (since i386.md actually
  > truncates all modes by &31).
I can see the value in this if we end up defining SHIFT_COUNT_TRUNCATED for
the x86.  

  > There don't seems to be much use for SHIFT_COUNT_TRUNCATED in gcc, so it
  > should not be much work and I should do that, if it is good thing to do.
I don't understand this statement.  SHIFT_COUNT_TRUNCATED is certainly used
and is a valueable optimization for some architectures.

While I would recommend following up on this work, I would suggest doing so
*after* we wrap up your existing changes.  Otherwise the outstanding changes
just get larger and larger and more difficult to untangle.

  > BTW whats are the limitation of combiner. Will pattern like:
  > (set reg0
  >  (ior (ashift reg1 reg2)
  >       (lshiftrt reg3 (neg reg2))))
  > ever match? (there is limitation to three instruction or so, if I remember
  > correctly)
The combiner can directly combine 3 instructions.  However, the result of one
combination can be used in a later combination, so it is possible to combine
more than 3 instructions.

As to that specific pattern -- I don't know.  combine may try to canonicalize
it in some way or another before trying to recognize it.  The best way to see
what patterns the combiner tries is to put a breakpoint in recog_for_combine
and look at its arguments.

  > so why not to make it matching something :). I've actually made constant
  > parameter version of it and it seems to match about four times in gcc and
  > kernel. Is that worthwhile? :))
Probably not.  

jeff