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

Adam Nemet anemet@caviumnetworks.com
Fri Jul 31 23:33:00 GMT 2009


Richard Henderson writes:
> On 07/30/2009 06:28 PM, Adam Nemet wrote:
> > JTBS, as I pointed out in the patch 4 thread, we still need to explicitly
> > exclude 0xffff_ffff in the predicate.  Hence this question is still open, I
> > believe.  Do we want an extra check there or just rely on the order in which
> > case these patterns need to move up?
> 
> How about merging all the patterns?  E.g.

It certainly seems doable (of course there are bunch details still to be
worked out in your example).  In fact it brings in the memory loads for 0xff
and 0xffff which makes things more consistent, IMHO; I was mentioning this
earlier.  TBH, some of this seems stylistic because again I couldn't trigger
the memory loads alternatives with and 0xff and 0xffff so it's probably best
left to RichardS to decide.

> PS: It appears that there's a big-endian error in all of these
> loads, and the existing loads in the zero_extend patterns.  I
> don't see where we're adjusting the memory address to get to
> the low part of the access...

For the extend patterns the memory operand is already in the narrower mode so
we don't need to adjust, AFAICT.  For the clear_upper32 patterns we call
gen_lowpart (SI, on the memory operand.

Adam



More information about the Gcc-patches mailing list