Re: multi-word operations

["David S. Miller" <davem at dm dot cobaltmicro dot com>]

There are even more horrible cases, particularly to do with when the
compiler internally emits RTL to perform a conversion that the port
has not indicated it knows how to do explicitly.

For example, on a 32-bit target try the following in the MD file.

1) Don't provide a pattern for zero_extendsidi2

2) Indicate you know how to do the following:

   (set (match_operand:DI 0 "register_operand" "r")
        (minus:DI (match_operand:DI 1 "register_operand" "r")
                  (zero_extend:DI
                   (match_operand:SI 2 "register_operand" "r"))))

It will never match.  Add the explicit zero_extendsidi2 pattern, and
it will match. :-(  I ran into this during the sparc backend rewrite.

The compiler emits RTL in the former case which surrounds the
conversion by a libcall sequence.  It tacks on a set of the
destination to itself in the end, and also adds a clobber of the input
operands.

Furthermore it adds a REG_EQUAL note which matches the pattern in #2!!
But due to all the gook now surrounding the RTL it never has a chance
to "see" what is going on.  So the REG_EQUAL note does not help the
compiler at all, I think it should.

If someone has some time they may want to experiment with not emitting
the clobber in certain cases, most of the time the RTL emitted
suggests the data flow just fine and the compiler won't muck it up.
I believe the clobber is what is preventing the optimizations.

There are also some peculiar cases wrt. moving multi-register
arguments into place for a function call.  But I'll get into that
another time when I understand it better.  (for the curious what I see
is:

	(set (reg:DI pseudo) (some_op:DI (x) (y)))
        (set (reg:DI arg0) (reg:DI pseudo))

and the pseudo does not get substituted with arg0 even if there are no
input dependencies in the first SET).

Later,
David S. Miller
davem@dm.cobaltmicro.com