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

["Maciej W. Rozycki" <macro at codesourcery dot com>]

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