[PATCH v3] powerpc/64: Fix memcmp reading past the end of src/dest

[Segher Boessenkool]

On Tue, Mar 26, 2019 at 08:18:07PM +1100, Michael Ellerman wrote:
> Segher Boessenkool <segher at kernel.crashing.org> writes:
> > On Mon, Mar 25, 2019 at 11:33:56PM +1100, Michael Ellerman wrote:
> >> Segher Boessenkool <segher at kernel.crashing.org> writes:
> >> > On Fri, Mar 22, 2019 at 11:37:24PM +1100, Michael Ellerman wrote:
> >> >> +	clrldi	r6,r4,(64-12)	// r6 = r4 & 0xfff
> >> >
> >> > You can just write
> >> >   rlwinm r6,r4,0,0x0fff
> >> 
> >> > if that is clearer?  Or do you still want a comment with that :-)
> >> 
> >> I don't think it's clearer doing a rotate of zero bits :)
> >> 
> >> And yeah I'd probably still leave the comment, so I'm inclined to stick
> >> with the clrldi?
> >
> > I always have to think what the clrldi etc. do exactly, while with rlwinm
> > it is obvious.  But yeah this may be different for other people who are
> > used to different idiom.
> 
> Interesting, I'm the opposite. You know ppc assembler better than me so
> I guess I just need to spend more time on it and embrace the zen of the
> rotate instructions.

There is only one rlwinm instruction, but there are 9 extended mnemonics
for it.  (And similarly for the 64-bit ops, where there are 3 basic
mnemonics but 9 extended mnemonics).  Of course I use {s,rot}{l,r}{w,d}i,
those are actually *simpler* than rlwinm / rldic{,l,r}, but not the other
stuff.

It may also be because the disassembler doesn't show these things.  Dunno.

> I'm not sure it's vastly more hostile though than `andi. 6,4,0xffff`
> being valid but `andi. 6,4,0x1ffff` being not valid.

But that is the same for *all* UIMM insns.

> Yeah, I guess a new `andi` instruction is the only real answer :)

Too bad there is no space in the opcode map for it, already not in the
original POWER architecture (where this is "andil.") :-/


Segher