Software and architecture support for the bulk multicore

Research on transactional memory began as a tool to improve the experience of programmers working on parallel code. Just as transactions in databases, it was the job of the runtime to detect any conflicts between parallel transactions and rollback the ones that needed to be re-executed, leaving the programmers blissfully unaware of the communication and synchronization that needs to happen. The programmer only needed to cover the sections of code that might generate conflicts in transactions, or atomic regions. More recently, new uses for transactional execution were proposed where, not only were user specified sections of code executed transactionally but the entire program was executed using transactions. In this environment, the hardware is in charge of generating the transactions, also called chunks, unbeknownst to the user. This simple idea led to many improvements in programmability such as providing a sequentially consistent(SC) memory model, aiding atomicity violation detection, enabling deterministic reply, and even enabling deterministic execution. However, the implications of this chunking hardware on the compiler layer has not been studied before, which is the subject of this Thesis. The Thesis makes three contributions. First, it describes the modifications to the compiler necessary to enable the benefits in programmability, specifically SC memory model, to percolate up to the programmer language level from the hardware level. The already present hardware support for chunked execution is exposed to the compiler and used extensively for this purpose. Surprisingly, the ability to speculate using chunks leads to speedups over traditional compilers in many cases. Second, it describes how to expose hardware signatures, present in chunking hardware for the purposes of conflict detection and memory disambiguation, to the compiler to enable further novel optimizations. An example is given where hardware signatures are used to summarize the side-effects of functions to perform function memoization at a large scale. Third, it describes how to use atomic regions and conflict detection hardware to improve alias analysis for general compiler optimizations using speculation. Loop Invariant Code Motion, a widely used traditional compiler pass, is run as an example client pass to test the potential of the new alias analysis