This is the mail archive of the
mailing list for the GCC project.
Re: [JAVA PATCH] Implement RSHIFT_EXPR of unsigned types with iushr
- From: Andrew Haley <aph at redhat dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: java-patches at gcc dot gnu dot org, <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 1 Feb 2005 18:14:55 +0000
- Subject: Re: [JAVA PATCH] Implement RSHIFT_EXPR of unsigned types with iushr
- References: <Pine.LNX.email@example.com>
Roger Sayle writes:
> The following patch is the second and lesser part of my solution for PR
> java/19295, see http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01669.html
> The source of the "useless" NOP_EXPRs in the bugzilla PR is the result
> of the middle-end attempting to synthesize a logical right shift. On
> some platforms logical right shift is cheaper than arithmetic right
> shift, so "fold" prefers this form if there's no preference. Hence
> when converting "(x & C) != 0" into "(x >> C') & 1", it actually creates
> the "(int)((unsigned int)x >> C') & 1". Notice that either form of
> right shift will do, as we ultimately mask out just a single bit.
> This follow-up patch tweaks jcf-write.c to actually honor the
> UNSIGNED_TYPE semantics of the RSHIFT_EXPR tree code. This one-liner
> just selects either iushr (logical right shift) or ishr (arithmetic
> right shift) depending the signedness of the underlying integer type.
Sorry for the delay. My brain only parsed the "Implement RSHIFT_EXPR
of unsigned types with iushr". Yeah, you did put "JAVA PATCH". In
I suppose this is OK, but the Java language doesn't have unsigned int
types so they should not really be generated when we are compiling to
bytecode. However, if this is necessary for some fold() optimization,
I'm happy with the patch.