This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: flow patch for condexec
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