[PATCH 18/20] MIPS/GAS: Simplify sign-extension tests

[PATCH 18/20] MIPS/GAS: Simplify sign-extension tests

[Maciej W. Rozycki]

Hi,

 This change simplifies sign-extension tests to use fewer operations as 
already done elsewhere.  Note that IS_ZEXT_32BIT_NUM(), despite its name 
(I was unfortunate enough to come up with once ;) ), merely checks whether 
its argument is a signed 33-bit number.  I have refrained from renaming it 
to IS_SEXT_33BIT_NUM() though, but I can do this if you think it would be 
less confusing than the current name.

2010-12-02  Maciej W. Rozycki  <macro@codesourcery.com>

	gas/
	* config/tc-mips.c (IS_SEXT_32BIT_NUM): Simplify.
	(IS_SEXT_16BIT_NUM, IS_ZEXT_32BIT_NUM): Likewise.

 OK to apply?

  Maciej

binutils-gas-mips-ext.diff
Index: binutils-fsf-trunk-quilt/gas/config/tc-mips.c
===================================================================
--- binutils-fsf-trunk-quilt.orig/gas/config/tc-mips.c	2010-12-01 21:05:58.000000000 +0000
+++ binutils-fsf-trunk-quilt/gas/config/tc-mips.c	2010-12-01 21:05:58.000000000 +0000
@@ -974,18 +974,15 @@ static int mips_relax_branch;
 
 /* Is the given value a sign-extended 32-bit value?  */
 #define IS_SEXT_32BIT_NUM(x)						\
-  (((x) &~ (offsetT) 0x7fffffff) == 0					\
-   || (((x) &~ (offsetT) 0x7fffffff) == ~ (offsetT) 0x7fffffff))
+  (((((x) & 0xffffffffLL) ^ 0x80000000LL) - 0x80000000LL) == (x))
 
 /* Is the given value a sign-extended 16-bit value?  */
 #define IS_SEXT_16BIT_NUM(x)						\
-  (((x) &~ (offsetT) 0x7fff) == 0					\
-   || (((x) &~ (offsetT) 0x7fff) == ~ (offsetT) 0x7fff))
+  (((((x) & 0xffffLL) ^ 0x8000LL) - 0x8000LL) == (x))
 
 /* Is the given value a zero-extended 32-bit value?  Or a negated one?  */
 #define IS_ZEXT_32BIT_NUM(x)						\
-  (((x) &~ (offsetT) 0xffffffff) == 0					\
-   || (((x) &~ (offsetT) 0xffffffff) == ~ (offsetT) 0xffffffff))
+  (((((x) & 0x1ffffffffLL) ^ 0x100000000LL) - 0x100000000LL) == (x))
 
 /* Replace bits MASK << SHIFT of STRUCT with the equivalent bits in
    VALUE << SHIFT.  VALUE is evaluated exactly once.  */

Re: [PATCH 18/20] MIPS/GAS: Simplify sign-extension tests

[Richard Sandiford]

Patches 14-17 are OK.

"Maciej W. Rozycki" <macro@codesourcery.com> writes:
>  /* Is the given value a sign-extended 32-bit value?  */
>  #define IS_SEXT_32BIT_NUM(x)						\
> -  (((x) &~ (offsetT) 0x7fffffff) == 0					\
> -   || (((x) &~ (offsetT) 0x7fffffff) == ~ (offsetT) 0x7fffffff))
> +  (((((x) & 0xffffffffLL) ^ 0x80000000LL) - 0x80000000LL) == (x))
>  
>  /* Is the given value a sign-extended 16-bit value?  */
>  #define IS_SEXT_16BIT_NUM(x)						\
> -  (((x) &~ (offsetT) 0x7fff) == 0					\
> -   || (((x) &~ (offsetT) 0x7fff) == ~ (offsetT) 0x7fff))
> +  (((((x) & 0xffffLL) ^ 0x8000LL) - 0x8000LL) == (x))
>  
>  /* Is the given value a zero-extended 32-bit value?  Or a negated one?  */
>  #define IS_ZEXT_32BIT_NUM(x)						\
> -  (((x) &~ (offsetT) 0xffffffff) == 0					\
> -   || (((x) &~ (offsetT) 0xffffffff) == ~ (offsetT) 0xffffffff))
> +  (((((x) & 0x1ffffffffLL) ^ 0x100000000LL) - 0x100000000LL) == (x))

Although I realise some ports have transgressed (ia64 for one), we shouldn't
use LL.

Richard

Re: [PATCH 18/20] MIPS/GAS: Simplify sign-extension tests

[Maciej W. Rozycki]

On Tue, 7 Dec 2010, Richard Sandiford wrote:

> "Maciej W. Rozycki" <macro@codesourcery.com> writes:
> >  /* Is the given value a sign-extended 32-bit value?  */
> >  #define IS_SEXT_32BIT_NUM(x)						\
> > -  (((x) &~ (offsetT) 0x7fffffff) == 0					\
> > -   || (((x) &~ (offsetT) 0x7fffffff) == ~ (offsetT) 0x7fffffff))
> > +  (((((x) & 0xffffffffLL) ^ 0x80000000LL) - 0x80000000LL) == (x))
> >  
> >  /* Is the given value a sign-extended 16-bit value?  */
> >  #define IS_SEXT_16BIT_NUM(x)						\
> > -  (((x) &~ (offsetT) 0x7fff) == 0					\
> > -   || (((x) &~ (offsetT) 0x7fff) == ~ (offsetT) 0x7fff))
> > +  (((((x) & 0xffffLL) ^ 0x8000LL) - 0x8000LL) == (x))
> >  
> >  /* Is the given value a zero-extended 32-bit value?  Or a negated one?  */
> >  #define IS_ZEXT_32BIT_NUM(x)						\
> > -  (((x) &~ (offsetT) 0xffffffff) == 0					\
> > -   || (((x) &~ (offsetT) 0xffffffff) == ~ (offsetT) 0xffffffff))
> > +  (((((x) & 0x1ffffffffLL) ^ 0x100000000LL) - 0x100000000LL) == (x))
> 
> Although I realise some ports have transgressed (ia64 for one), we shouldn't
> use LL.

 How is the above any worse than e.g. 0x800080008000ull we already have in 
append_insn()?  C9x has been out for over 10 years now and GCC had had the 
"long long" type for another decade or so -- rather than avoiding the type 
all the sane world has supported for years now we should be thinking how 
to make numbers be printed in messages correctly -- right now we cast e.g. 
->X_add_number to a type like "unsigned long" losing the upper bits on 
some hosts and producing misleading errors, etc.

 I don't say we should rush dropping support for legacy hosts, but they 
shouldn't be our primary concern and shouldn't make us cripple 
functionality IMO.  So e.g. I'd be fine with using stuff like UINTMAX_C() 
and autoconf'ing those that don't have it.  But frankly I fail to see the 
point given we've had the other literals for a while now and nobody 
complained.

 I've checked and 0x800080008000ull was already in 2.16 five years ago.  
Possibly earlier, but I can't be bothered to dig out any older releases, 
sorry.

  Maciej