Path: utzoo!utgpu!water!watmath!clyde!burl!codas!killer!jfh
From: jfh@killer.UUCP (The Beach Bum)
Newsgroups: comp.lang.c
Subject: Re: bitwise short-circuiting
Summary: Logical extension of other compile-time optimizations.
Keywords: bitwise optimize open-eyes
Message-ID: <3378@killer.UUCP>
Date: 17 Feb 88 20:26:43 GMT
References: <4224@june.cs.washington.edu> <2303@umd5.umd.edu>
Reply-To: jfh@killer.UUCP (The Beach Bum)
Organization: Big "D" Home for Wayward Hackers
Lines: 46

In article <2303@umd5.umd.edu> chris@trantor.umd.edu (Chris Torek) writes:
>Without further supporting evidence, I will claim that any optimiser
>could convert
>
>	a = 0 & f();
>
>into
>
>	(void) f(), a = 0
>
>and
[ more examples deleted for brievity ]
>-- 
>In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163
>(hiding out on trantor.umd.edu until mimsy is reassembled in its new home)

These are extensions to the common (e) + 0, (e) * 1, etc. optimizations that
many compilers already implement.  Replacing '+' with '|' and '*' with
'&' gives the same results, excect all bits must be considered when 
performing the optimization, thus:

	if (0100 | f())
		s2;

can be optimized to

	(void) f();
	s2;

(Well, really similiar only different since if (0100 + f()) can't be
optimized, BUT, if (0 * f()) and if (0 & f()) both can)

A suggested method to handle this would be to rewrite the tree to
become 'if (f(), 0)' when handed 'if (0 & f())' as input, then let
some other part of the optimizer handle removing the 'then' part of
the statement.

[ This belongs in comp.compilers, but that is a moderated newsgroup
  and I'm not in a mood to cross-post over there. ]

- John.
-- 
John F. Haugh II                  SNAIL:  HECI Exploration Co. Inc.
UUCP: ...!ihnp4!killer!jfh                11910 Greenville Ave, Suite 600
"You can't threaten us, we're             Dallas, TX. 75243
  the Oil Company!"                       (214) 231-0993 Ext 260