Bad optimization in PCC?

Chris Torek chris at mimsy.UUCP
Mon Apr 25 22:14:36 AEST 1988


In article <793 at amnesix.liu.se> mikpe at amnesix.liu.se (Mikael Pettersson)
writes:
>While hacking a piece of code the other day, I came across what
>looks like a case of bad optimization in PCC-derivated compilers.

[Note that Mikael means `poor', not `incorrect', optimisation]

[Sun version, trimmed:]
>L18:	tstb	a3@
>    (+)jeq	L19
	...
>L19:	tstb	a3@
>    (*)jne	L20
>	movl	a6@(12),a5@
>L20:
>
>It seems to me that a *good* peep-hole optimizer should be able to
>recognize that if the jump at line (+) is taken then the jump at line
>(*) will not be taken.

As long as a3@ is not `volatile', or local equivalent.

>So why didn't they generate something like:
>L18:	tstb	a3@
>    (+)jeq	L19
	...
>L19:	movl	a6@(12),a5@
>L20:

The peephole optimisers we have are simply not that ambitious.  The Vax
c2 comes close; it carries ccodes around (sort of) and notices branches
to tests whose result is already known (see my recent bug fix for
branches to tests whose result is discarded).  But it is a bit scared
of tests on memory locations, lest it break code that depends on
variables being volatile:

	register char *cp;
	...
	while (*cp == 0) /*void*/;	/* wait for signal */

compiles to (Vax)

	L17:	tstb	(r11)
		jeql	Ln

The result is `obvious', so c2 `ought' to change this to

	L17:	tstb	(r11)
	L2000000:jeql	L2000000

which is *really* an infinite loop.  Instead it just leaves memory
references alone.

I do not know why GCC, which *does* have volatile, does not catch
that one.

Incidentally, if you rewrite the original code

>	while(*np && (*np++ == *ep++))
>		/* empty */ ;
>	if(!*np)
>		*envp = val;

as

	do {
		if (*np == 0) {
			*envp = val;
			break;
		}
	} while (*np++ == *ep++);

it compiles to (again, Vax)

	L18:	tstb	(r11)
		jneq	L17
		movl	-4(fp),(r9)
		jbr	L16
	L17:	cmpb	(r11)+,(r10)+
		jeql	L18
	L16:

(although why you would care that much about a microsecond in `setenv' I
am not sure...).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris



More information about the Comp.lang.c mailing list