Usage of goto's

[Peter Klausler]

In article <201 at smds.UUCP> rh at smds.UUCP (Richard Harter) writes:
>...  Many optimizing compilers don't deal well with goto's.  As I understand
>it, they make the register assignment task messy and their presence
>invalidates many assumptions used in optimizing code in blocks.  Switches
>for contiguous integer ranges typically optimize out to a range check and
>a branch from a jump table.  The 3-4 instructions that you pay for a range
>check and two jumps will be outweighed by extra instructions induced by
>less efficient optimization.  In any case the potential gain is negligible
>unless the state execution code is mostly one liners.

Within a basic-block flow graph built by an "optimizing" compiler, everything's
a "goto", regardless of whether it was coded as "break", "continue", "if", or
whatever. The messiness that can come from a "goto" is that they can be used
to construct so-called irreducible flow graphs, which are admittedly tougher
to analyze.

Irreducible flow graphs arise from loops with multiple entries. Example:

		if (...) goto A;
	B:	...
	A:	if (...) goto B;

In real life C code, you're going to produce irreducible graphs only when you
use "goto" to jump into a "for"/"while"/"do" loop, which is bad practise for
other, more obvious, reasons.

Irreducibility would be the only excuse for "less efficient [sic] optimization"
in a real compiler. Further, the "3-4 instructions that you pay for a range
check and two jumps" cost different amounts on different platforms. On a Cray,
a "switch" involves falling through the two range check jumps, a load from the
switch table, and an indirect jump; none of these are cheap, especially the
load.

I personally use "goto" most often in search loops like this:

		for (...; ...; ...)
			if (...)
				goto found;

		fprintf (stderr, "didn't find it!\n");
		abort ();

	found:	...

Fast, clear, and often vectorizable.

-Peter Klausler, Cray Computer Corp. compiler development (pmk at craycos.com)