This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Patch to implement rotates by zero
- From: cgd at broadcom dot com
- To: rsandifo at redhat dot com
- Cc: binutils at sources dot redhat dot com,echristo at redhat dot com
- Date: 17 Aug 2002 14:15:01 -0700
- Subject: Re: Patch to implement rotates by zero
- References: <wvnit29if6w.fsf@talisman.cambridge.redhat.com><mailpost.1029604255.8780@news-sj1-1>
At Sat, 17 Aug 2002 17:10:55 +0000 (UTC), "Richard Sandiford" wrote:
> Noticed while reading the code that:
>
> ror $2,$4,0
>
> expands to nothing at all. And the testsuite actually requires this
> behaviour ;).
>
> This patch implements double-rotates by zero using "dsll", so that they
> trap in the same circumstances that non-zero rotates would.
specifically, you mean, so they trap when 64-bit operations aren't
enabled?
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?
(of course, then, why emit the no-op instruction to begin with. 8-)
> 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.
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.
cgd