Re: Patch to implement rotates by zero

[Richard Sandiford <rsandifo at redhat dot com>]

cgd@broadcom.com writes:
> At Sat, 17 Aug 2002 17:10:55 +0000 (UTC), "Richard Sandiford" wrote:
> > This patch implements double-rotates by zero using "dsll", so that they
> > trap in the same circumstances that non-zero rotates would.
> [snip]
> This seems in one way desirable, but in another ... not.  if you're
> generating a macro, why generate one which is in fact a no-op?

I thought implementing it as a standard move would be too suprising.

> > Likewise
> > "rol" and "ror" will use "sll" to give the correct sign extension
> > on 64-bit targets.
> 
> Uh, this one makes less sense to me.
> 
> AFAIK, 'sll' w/ a shift of 0 is only guaranteed to sign-extend by
> MIPS64.  I've seen no previous documentation that defined that it must
> work that way.

Damn.  Really?  Showing my ignorance here. ;)

The non-MIPS64 processors I'm working with guarantee it too, but
looking back at the manuals, it does seem that they go out of
their way to say so.  Hmm...

How about srl?

> So, I really don't see much point in this except from a "code
> generation is the same" POV, and since you're emitting special-case
> code there it's still not "code generation is the same".
>
> I dunno, from a consistency standpoint, it would make sense to simply
> remove the check for the count being non-zero.  i.e. if you ask for
> rol/rot/etc. and get the macro, you always end up with a 3-instruction
> sequence being generated.

Wouldn't the effect be the same?  The sequence would still include
a sll of zero.  Like you say, if shifts by zero aren't always
well-defined, it does seem consistent from one POV.

But I've nothing really against removing the check.  I just don't
think we should silently drop the instruction.

Richard