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

[Adam Nemet]

Richard Sandiford writes:
> Adam Nemet <anemet@caviumnetworks.com> writes:
> > Richard Sandiford writes:
> >> Hmm.  If we do this, we should do it for all combinations (i.e. have
> >> patterns for TARGET_MIPS16 || !ISA_HAS_EXT_DEXT too).  And MIPS16 has
> >> the added complication that ZEB and ZEH are only for GENERATE_MIPS16E;
> >> shifts are needed otherwise.  All in all, I don't take back what I said
> >> about it not being easy to do this cleanly. ;)
> >
> > How is ZEB and ZEH are relevant here?  We can't use them with DI-mode values.
> 
> Not sure I follow.  If we're providing LBU and LHU, we ought to provide
> the register alternatives too.  And those register alternatives are ZEB
> and ZEH for MIPS16e.

Well as I said I was thinking DI mode where only LBU and LHU are valid:

(and:DI (mem:DI) (const_int 0xff/0xffff))

IOW, you can't generate ZEB and ZEH for:

(and:DI (reg:DI) (const_int 0xff/0xffff))

but you're right in SI mode we can also do ZEB and ZEH in addition to LBU and
LHU.

> > I think however that this would be a good point to stop; I don't think it a
> > good idea to merge the clear_upper32 !ISA_HAS_EXT_INS pattern into this.  This
> > works much better than the clear_upper32_ext case because we don't need to
> > special-case the predicates to fall through to the clear_upper32 case since
> > low-order bitmask values are not valid for !ISA_HAS_EXT_INS.
> 
> I disagree.  If we do this, we should do it for the usual reason of giving
> reload more freedom.  Otherwise I'd have no problem excluding 0xFFFFFFFF
> from the and predicate, as you suggested earlier.

OK, I see where you're coming from.  You mean that *clear_upper32 is
problematic because it does not match a superset of the alternatives of the
"and" pattern.

Can't we address this by making the regular "and" pattern always
match 0xffff_ffff and have a post-reload define_split with !ISA_HAS_EXT_INS
for (and:DI (reg:DI) (0xffff_ffff)) to generate the shifts?  IOW, let the
constraints be managed by the regular "and" pattern.

> (TBH, I still like the idea of adding an extra ext-based alternative to the
> current and pattern, with that != 0xFFFFFFFF condition.)

Depending on what you think about the above, it would be really good to have
some incremental patch to go in.  Your approach addresses the problem with my
patch so unless we can come up with a more integrated approach I can
definitely go and finish that up.

Adam