Re: [PATCH 3/4, MIPS] Move clear_upper32* patterns to the and patterns

[Adam Nemet <anemet at caviumnetworks dot com>]

Richard Sandiford writes:
> Thanks for the patch, but I'm afraid this isn't complete.  It needs to
> handle shift_shift alternatives for TARGET_MIPS16 && !GENERATE_MIPS16E
> (as a replacement for ZEB and ZEH).

Hey, but this is a new feature :).  Even before the patch I get this for "i
& 0xffff" with -mips16 -march=mips4:

        li      $2,65535
        and     $2,$4

> E.g. having the 2-op and 3-op ANDs into one pattern will probably
> cause it to try to bind the destination and first source operand
> for !TARGET_MIPS16, even though that isn't needed.  Likewise,
> having the 3-op alternative might lead IRA to think that 3 operands
> are cheaper than they really are.  I can just see this putting more
> pressure on reload proper, which is the opposite of the direction
> we want to go in.  Maybe I'm wrong though.

I need to think about this but there is of course also the option of keeping
mips16 and regular mips separate.  I only merged it because I thought
"enabled" was doing what it claimed :(.

The real difference between the previous approach and the patch is not so much
these extra alternatives that have not been handled even before or whether we
merge mips16 or not.  The real difference is whether we fully figure out the
actual alternative

 * in the "and" pattern (patch) or 

 * between the clear_upper32 and "and" pattern by mutually excluding each
 other during matching (previous approach).

It seems to me that the former is better.

Also with your above ZEB/ZEH example, it seems we need another splitter and
the new structure seems better suited for this.  We determine the "#"
alternative in the main pattern and have a post-reload define_split.  This
seems better than a new define_insn_and_split repeating some of the
alternatives from the main pattern.

Adam