|Sequence of passes in a compilation firstname.lastname@example.org (IQ) (2008-06-16)|
|Re: Sequence of passes in a compilation email@example.com (2008-06-17)|
|From:||firstname.lastname@example.org (Torben =?iso-8859-1?Q?=C6gidius?= Mogensen)|
|Date:||Tue, 17 Jun 2008 09:11:01 +0200|
|Organization:||Department of Computer Science, University of Copenhagen|
|Posted-Date:||17 Jun 2008 19:21:55 EDT|
IQ <email@example.com> writes:
> I have a question: Assume S1 and S2 be two sequence of passes which
> are not equal, i.e., S1 is different from S2. Let there are two
> programs P1 and P2. Is it possible that P1 can be compiled
> successfully using S1 but not with S2. Similarly P2 can be compiled
> successfully with S2 but not with S1.
If the passes change the representation format (such as the pass that
translates a syntax tree into intermediate code), you obviously have
such a situation.
> I am getting this when I am changing the sequence of GCC using the
> SPEC benchmark.
So, I'm assuming you are referring to exchanging optimisation passes
that all work on the same representation format. In this case, there
can still be problems: A later phase may rely on the fact that certain
patterns have been eliminated by previous phases and go wrong if they
aren't. This ought to be very clearly documented in both source code
and external documentation if this is the case, but countless examples
of the opposite exist, so you shouldn't be too sure.
Also, an optimisation pass may rely on a later pass to "clean up"
after it, but that usually doesn't make the results wrong -- only less
Additionally, there is the possibility of bugs in the compiler.
Testing a compiler (especially for a language as arcane as C) is a
horrifying task and if you have flags that can turn off or exchange
optimisations, the number of combinations can be astronomical, so it
is a practical impossibility to test all. Hence, you run a large risk
of encountering untested (and, hence, potentially bugridden)
combinations when you play too much with the flags.
Return to the
Search the comp.compilers archives again.