U. Glaeser

multithreaded hardware, possibly by making it part of the ISA (at the expense of incompatibility
for existing binaries). Parallelizing compilers have been successful in parallelizing many numeric
applications for the parallel threads model. As pointed out earlier, their success has not been
spectacular when it comes to non-numeric applications and the parallel threads model. Several
researchers are currently working on parallelizing compilers that parallelize such applications for
the sequential threads model.
• Hardware: It is also possible to let the run-time hardware do the program partitioning. If partitioning
decisions are taken by the hardware, the multithreaded processor provides object code
compatibility to existing sequential code. Furthermore, it has the ability to adapt to run-time
behavior. Hardware-based partitioning is typically done only if the thread granularity is small,
and if sequential control flow is used. The main limitation is the significant impact it may have
on clock cycle time. In order to simplify the dynamic partitioning hardware and to reduce the
impact on clock cycle time, the partitioning job is often split into two parts—a static part (which
is done by pre-processing hardware) and a dynamic part. The static part collects information that
is static in nature (such as register dependences in a straightline piece of code) and stores it in a
special i-cache structure, often after performing some additional processing. The dynamic part
uses this information while deciding the final partitioning at run-time. Examples of multithreaded
processors that use hardware-based partitioning are trace processor [28,36], speculative multithreading
processor [22], and dynamic multithreading processor [1].
Compiling for Multithreading
Most of the multithreading approaches perform partitioning at compile time, possibly with some help
from the programmer; it is somewhat unrealistic at this time to expect programmers to write only parallel
programs. The hardware is also limited in its program partitioning capability. Therefore, the compiler
has the potential to play a significant role in multithreading. Besides program partitioning, it can schedule
threads as well as the instructions within threads.
The task of the compiler is to identify sufficient parallelism to keep the processors busy, while minimizing
the effects of synchronization and communication latencies on the execution time of the program.
To accomplish this objective, a parallelizing compiler typically performs the following functions:
1. Identify the parallelism inherent in the program. This phase has received the most attention in
parallel compiler research to date [25,26]. Many varied program transformations have been developed
to unearth parallelism buried in the semantics of sequential programs.
2. Partition the program into multiple threads for parallel execution. This is perhaps the most crucial
phase. Many factors must be considered, such as inter-thread dependences, intra-thread locality,
thread size, critical path, and deadlock avoidance.
3. Schedule the concurrent execution of threads; the final scheduling is often determined by the runtime
environment. The compiler must assign threads to processors in a way that maximizes
processor utilization without severely restricting the amount of parallelism to be exploited.
4. After program partitioning, the compiler can schedule the instructions in a thread so as to reduce
inter-thread wait times. For instance, if a shared value is produced very late in one thread, but is
needed very early in another thread, very little parallelism will be exploited by the hardware. This
problem is likely to surface frequently, if the compiler assumed a single-threaded processor in the
code generation phase. In such situations, post-partitioning scheduling can help minimize the
waiting time of instructions by ensuring that shared values required in other threads are produced
as early as possible. Post-partitioning scheduling is especially beneficial if PEs execute their instructions
in strict serial order.
Object Code Compatibility
Another important issue, especially from the commercial point of view, is the level of compatibility that
the multithreaded processor provides. We can think of three levels of compatibility in the context of
multithreaded processors: full compatibility, family-wide compatibility, and no compatibility.
© 2002 by CRC Press LLC