{"id":{"repo_id":"uiuc","oai_identifier":"oai:www.ideals.illinois.edu:2142/32076"},"canonical_url":"https://search.dev.ndltd.org/etd/uiuc/oai:www.ideals.illinois.edu:2142/32076","repository":{"repo_id":"uiuc","name":"University of Illinois - Urbana-Champaign","base_url":"https://www.ideals.illinois.edu/oai-pmh"},"display":{"title":"Software and architecture support for the bulk multicore","abstract":"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 conﬂicts 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 conﬂicts in transactions, or atomic regions. More recently, new uses for transactional execution were proposed where, not only were user speciﬁed 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 modiﬁcations to the compiler necessary to enable the beneﬁts in programmability, speciﬁcally 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 conﬂict 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 conﬂict 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.","abstract_html":"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 conﬂicts 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 conﬂicts in transactions, or atomic regions. More recently, new uses for transactional execution were proposed where, not only were user speciﬁed 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 modiﬁcations to the compiler necessary to enable the beneﬁts in programmability, speciﬁcally 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 conﬂict 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 conﬂict 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.","abstract_has_math":false,"creators":["Ahn, Daniel"],"institution":"University of Illinois at Urbana-Champaign","degree_name":"Ph.D.","degree_level":"Dissertation","degree_discipline":"Computer Science","degree_department":null,"school":null,"contributors":["Torrellas, Josep","Cascaval, Calin","Midkiff, Samuel","Hwu, Wen-Mei W.","Adve, Vikram S.","King, Samuel T."],"advisors":[],"committee_chairs":[],"committee_members":[],"year":2012,"date_issued":"2012-06-27T21:31:50Z","date_published":"2012-06-27T21:31:50Z","updated_at":"2026-07-22T22:25:30Z","subjects":["Computer Architecture","Compiler","Transactional Memory","Transactional Execution","Speculative Optimization","Bloomfilter","Signature","Memory Model","Sequential Consistency","Function Memoization","Alias Analysis"],"languages":["en"],"rights":["Copyright 2012 Daniel Ahn"],"rights_urls":[],"identifier_entries":[]},"links":{"outbound_url":"http://hdl.handle.net/2142/32076","outbound_label":"Handle","outbound_source":"dc:identifier"},"metadata_groups":[{"id":"people","label":"People","entries":[{"key":"dc:contributor","label":"Contributor","values":["Torrellas, Josep","Cascaval, Calin","Midkiff, Samuel","Hwu, Wen-Mei W.","Adve, Vikram S.","King, Samuel T."]},{"key":"dc:creator","label":"Author","values":["Ahn, Daniel"]}]},{"id":"academic_context","label":"Academic Context","entries":[{"key":"dc:date","label":"Dc Date","values":["2012-06-27T21:31:50Z","2014-06-28T10:00:29Z","2012-05"]},{"key":"dc:type","label":"Dc Type","values":["text"]},{"key":"thesis:degree_discipline","label":"Discipline","values":["Computer Science"]},{"key":"thesis:degree_level","label":"Degree Level","values":["Dissertation"]},{"key":"thesis:degree_name","label":"Degree Name","values":["Ph.D."]},{"key":"thesis:institution_name","label":"Thesis Institution Name","values":["University of Illinois at Urbana-Champaign"]}]},{"id":"subjects_keywords","label":"Subjects and Keywords","entries":[{"key":"dc:subject","label":"Dc Subject","values":["Computer Architecture","Compiler","Transactional Memory","Transactional Execution","Speculative Optimization","Bloomfilter","Signature","Memory Model","Sequential Consistency","Function Memoization","Alias Analysis"]}]},{"id":"language_rights","label":"Language and Rights","entries":[{"key":"dc:language","label":"Dc Language","values":["en"]},{"key":"dc:rights","label":"Dc Rights","values":["Copyright 2012 Daniel Ahn"]}]},{"id":"identifiers","label":"Identifiers","entries":[{"key":"dc:identifier","label":"Identifier","values":["http://hdl.handle.net/2142/32076"]}]},{"id":"additional","label":"Additional Metadata","entries":[{"key":"dc:description","label":"Description","values":["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 conﬂicts 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 conﬂicts in transactions, or atomic regions. More recently, new uses for transactional execution were proposed where, not only were user speciﬁed 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 modiﬁcations to the compiler necessary to enable the beneﬁts in programmability, speciﬁcally 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 conﬂict 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 conﬂict 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.","Item withdrawn by Mark Zulauf (zulauf@illinois.edu) on 2012-04-12T19:42:08Z Item was in collections: University of Illinois Theses & Dissertations (ID: 1) No. of bitstreams: 2 Ahn_Daniel.pdf: 878372 bytes, checksum: 44ff419d4790dced4116a69d24316fd4 (MD5) Ahn_Daniel.pdf: 879004 bytes, checksum: 652d367c6764291ed8345cf197009016 (MD5)","Made available in DSpace on 2012-06-27T21:31:50Z (GMT). No. of bitstreams: 2 Ahn_Daniel.pdf: 879004 bytes, checksum: 652d367c6764291ed8345cf197009016 (MD5) license.txt: 4057 bytes, checksum: 7c98963a4276f12f996bdc5585aec7df (MD5)","Item marked as restricted to the 'Administrator' Group (id=1) by William Ingram (wingram2@illinois.edu) on 2012-06-27T21:32:50Z Item is restricted until 2014-06-27T21:32:23Z","Item reinstated by Sarah Shreeves (sshreeve@illinois.edu) on 2014-06-28T10:00:29Z Item was in collections: Graduate Theses and Dissertations at Illinois (ID: 204) Dissertations and Theses - Computer Science (ID: 587) No. of bitstreams: 2 Ahn_Daniel.pdf: 879004 bytes, checksum: 652d367c6764291ed8345cf197009016 (MD5) license.txt: 4057 bytes, checksum: 7c98963a4276f12f996bdc5585aec7df (MD5)","Item released from any restrictions by Sarah Shreeves (sshreeve@illinois.edu) on 2014-06-28T10:00:29Z"]},{"key":"dc:title","label":"Title","values":["Software and architecture support for the bulk multicore"]}]}],"canonical_facts":{"dc:contributor":["Torrellas, Josep","Cascaval, Calin","Midkiff, Samuel","Hwu, Wen-Mei W.","Adve, Vikram S.","King, Samuel T."],"dc:creator":["Ahn, Daniel"],"dc:date":["2012-06-27T21:31:50Z","2014-06-28T10:00:29Z","2012-05"],"dc:description":["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 conﬂicts 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 conﬂicts in transactions, or atomic regions. More recently, new uses for transactional execution were proposed where, not only were user speciﬁed 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 modiﬁcations to the compiler necessary to enable the beneﬁts in programmability, speciﬁcally 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 conﬂict 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 conﬂict 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.","Item withdrawn by Mark Zulauf (zulauf@illinois.edu) on 2012-04-12T19:42:08Z Item was in collections: University of Illinois Theses & Dissertations (ID: 1) No. of bitstreams: 2 Ahn_Daniel.pdf: 878372 bytes, checksum: 44ff419d4790dced4116a69d24316fd4 (MD5) Ahn_Daniel.pdf: 879004 bytes, checksum: 652d367c6764291ed8345cf197009016 (MD5)","Made available in DSpace on 2012-06-27T21:31:50Z (GMT). No. of bitstreams: 2 Ahn_Daniel.pdf: 879004 bytes, checksum: 652d367c6764291ed8345cf197009016 (MD5) license.txt: 4057 bytes, checksum: 7c98963a4276f12f996bdc5585aec7df (MD5)","Item marked as restricted to the 'Administrator' Group (id=1) by William Ingram (wingram2@illinois.edu) on 2012-06-27T21:32:50Z Item is restricted until 2014-06-27T21:32:23Z","Item reinstated by Sarah Shreeves (sshreeve@illinois.edu) on 2014-06-28T10:00:29Z Item was in collections: Graduate Theses and Dissertations at Illinois (ID: 204) Dissertations and Theses - Computer Science (ID: 587) No. of bitstreams: 2 Ahn_Daniel.pdf: 879004 bytes, checksum: 652d367c6764291ed8345cf197009016 (MD5) license.txt: 4057 bytes, checksum: 7c98963a4276f12f996bdc5585aec7df (MD5)","Item released from any restrictions by Sarah Shreeves (sshreeve@illinois.edu) on 2014-06-28T10:00:29Z"],"dc:identifier":["http://hdl.handle.net/2142/32076"],"dc:language":["en"],"dc:rights":["Copyright 2012 Daniel Ahn"],"dc:subject":["Computer Architecture","Compiler","Transactional Memory","Transactional Execution","Speculative Optimization","Bloomfilter","Signature","Memory Model","Sequential Consistency","Function Memoization","Alias Analysis"],"dc:title":["Software and architecture support for the bulk multicore"],"dc:type":["text"],"thesis:degree_discipline":["Computer Science"],"thesis:degree_level":["Dissertation"],"thesis:degree_name":["Ph.D."],"thesis:institution_name":["University of Illinois at Urbana-Champaign"]},"updated_at":"2026-07-22T22:25:30Z"}