Re: flow patch for condexec

[Michael Meissner <meissner at cygnus dot com>]

On Wed, Feb 21, 2001 at 05:08:15PM -0800, Richard Henderson wrote:
> On Wed, Feb 21, 2001 at 03:44:37PM -0400, Aldy Hernandez wrote:
> > ... so if-conversion might compare a and 5 on one ccr and a and 10 on
> > another ccr ....  Now, if we have a chip in which comparisons between
> > ccrs may yield undefined values...
> 
> One might ask why if-conversion would generate stuff that might yield
> undefined values.
> 
> I havn't studdied this chip in detail, but as I understand things, the
> situation is that if we avoid situations that might yield undefined
> values, we can't do much at all.  So we have target-specific code do
> some transformations, the result of which isn't quite representable
> with the predication infrastructure that we had before Aldy's patch.
> 
> At least that's the basis on which I approved the patch...

Obviously, I don't have insight to the designers of the chips, but having
undefined makes nested IF-THEN statements easier.  Consider, if you have code
like:

	if (TEST1)
	  {
	    a = b + c;
	    if (TEST2)
	      d = e + f;
	    else
	      g = h + i;
	  }
	else
	  j = k + l;

then the expected code is:

   1)	CR1 = TEST1
   2)	ADD A,B,C	if (CR1)
   3)	CR2 = TEST2	if (CR1)
   4)	CR2 = CR2 & CR1
   5)	ADD D,E,F	if (CR2)
   6)	ADD G,H,I	if (! CR2)
   7)	ADD J,K,L	if (! CR1)

In instruction #3, CR2 gets undefined if CR1 is false or undefined.  This means
that in instruction #5, the add is only done if TEST1 && TEST, and in
instruction #6, the add is only done if TEST1 && !TEST2.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482