{{ post.title }}
12 |13 | {% if post.extra.authors %} 14 | 19 | {% else %} 20 | 21 | {% endif %} 22 | 25 |
26 |
27 | 
13 |
14 | The [first published algorithm](https://dl.acm.org/doi/pdf/10.1145/75277.75280) for SSA construction, written by Cytron et al., proceeds in two steps. The first places phi functions throughout the program, indicating ambiguities in assignments due to control flow. The second renames variables to ensure SSA’s single assignment property is satisfied.
15 | Importantly, Cytron et al.'s algorithm takes the CFG representation of the program as input. To create phi functions, it relies on calculation of the dominance frontier -- “the set of all CFG nodes Y such that X dominates a predecessor of Y but does not strictly dominate Y”:
16 |
17 | 
18 |
19 | # Contributions of [Braun et al.’s algorithm](https://c9x.me/compile/bib/braun13cc.pdf)
20 |
21 | In “Simple and Efficient Construction of Static Single Assignment Form”, Braun et al. present an alternative algorithm for SSA construction. The main benefit to their algorithm is that it goes straight from the abstract syntax tree (AST) representation of a program to SSA form, and eschews calculation of some auxiliary data structures, like the dominance frontier.
22 |
23 | The algorithm calculates phi nodes lazily using recursion. The main steps are (1) local value numbering to lookup values defined in the same basic block and (2) global value numbering to recursively lookup values defined in the predecessors of a basic block.
24 |
25 |
27 | 
30 | 
38 | 
39 |
40 | To better test the optimization and evaluate the performance, I planned to render the three scenes shown in Fig. 6 of the Dr.Jit paper. However, I noticed that during rendering, the optimization was never invoked. To address this, I modified the renderer code to make it less efficient, ensuring that there will be nodes to which the optimization can be applied. I changed the way the microfacet normal distribution function is evaluated. The expression that should be computed is as follows:
41 | $$D(\mathbf{m}) = \frac{1}{\pi \alpha_x \alpha_y (\sin^2\theta (\frac{\cos^2\phi}{\alpha_x^2} + \frac{\sin^2\phi}{\alpha_y^2}) + \cos^2\theta)^2}, \ (1)$$
42 | where $\mathbf{m}$ is a unit vector: $\mathbf{m} = (\sin\theta \cos\phi, \sin\theta \sin\phi, \cos\theta)^T = (m_x, m_y, m_z)^T$.
43 |
44 | $D(m)$ can be efficiently evaluated without explicitly computing $\theta$ and $\phi$:
45 |
46 | $$D(\mathbf{m}) = \frac{1}{\pi \alpha_x \alpha_y ((\frac{m_x^2}{\alpha_x^2} + \frac{m_y^2}{\alpha_y^2}) + m_z)^2}. \ (2)$$
47 |
48 | This computation, however, does not trigger my optimization. Therefore, I replaced (2) in the Mitsuba 3 code with computation that explicitly evaluates $\theta$ and $\phi$ from the vector $\mathbf{m}$, and then computes expression (1).
49 |
50 |
51 | I performed my experiment on a machine with an Intel(R) Xeon(R) Silver 4214 CPU running Ubuntu 20.04 and an NVIDIA GeForce RTX 3090 GPU. I used Mitsuba 3 (version 3.6.4) and modified v1.0.5 version of Dr.Jit to render all the scenes. Each experiment was run five times to get the average execution times reported below. Each rendering used a relatively large number of samples per pixel (2048 spp) to ensure that the measured time is reliable.
52 |
53 | 
54 |
55 | Well, my optimization did not improve the performance, but at least I know that the trace modification was correct since produced images were identical.
56 |
57 | The second part of the project was much less straightforward, and I was not able to figure it out. As described in [the project proposal](https://github.com/sampsyo/cs6120/issues/514#issue-2958547735), the idea was to trace functions that lack hardware support and cannot be represented by a single node into a separate trace, and then redirect the main AST to that newly created trace. I was unable to find a way to achieve this using the existing tools in the codebase. Implementing this optimization would require introducing a new type of node (e.g., `call`) and writing the corresponding PTX or LLVM IR code to support it.
58 |
--------------------------------------------------------------------------------
/content/blog/2025-05-13-Final_Project/evaluation.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/sampsyo/cs6120/8d343c04f6a6bd3ff783de0abda6b282c96791ae/content/blog/2025-05-13-Final_Project/evaluation.png
--------------------------------------------------------------------------------
/content/blog/2025-05-13-Final_Project/graph_new.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/sampsyo/cs6120/8d343c04f6a6bd3ff783de0abda6b282c96791ae/content/blog/2025-05-13-Final_Project/graph_new.pdf
--------------------------------------------------------------------------------
/content/blog/2025-05-13-Final_Project/graph_new.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/sampsyo/cs6120/8d343c04f6a6bd3ff783de0abda6b282c96791ae/content/blog/2025-05-13-Final_Project/graph_new.png
--------------------------------------------------------------------------------
/content/blog/2025-05-13-Final_Project/graph_old.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/sampsyo/cs6120/8d343c04f6a6bd3ff783de0abda6b282c96791ae/content/blog/2025-05-13-Final_Project/graph_old.pdf
--------------------------------------------------------------------------------
/content/blog/2025-05-13-Final_Project/graph_old.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/sampsyo/cs6120/8d343c04f6a6bd3ff783de0abda6b282c96791ae/content/blog/2025-05-13-Final_Project/graph_old.png
--------------------------------------------------------------------------------
/content/blog/2025-05-13-bril2wasm.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "It's About (wasm)Time: A Bril to Wasm Translator"
3 | [extra]
4 | bio = """
5 | Annabel Baniak is Masters of Science student studying CS at Cornell. In her free time, she enjoys participating in theatre and collecting antique books!
6 |
7 | Serena Duncan is an undergraduate studying CS at Cornell. When she isn't crying over Rust, she can be found taking long walks around campus and performing with the Shakespeare Troupe!
8 |
9 | Michael Xing is a Masters of Science student studying CS at Cornell and a Software Engineer at Microsoft. When not writing code, he enjoys travelling the world, riding roller coasters, and playing the piano. And video games.
10 | """
11 | [[extra.authors]]
12 | name = "Annabel Baniak"
13 |
14 | [[extra.authors]]
15 | name = "Michael Xing"
16 |
17 | [[extra.authors]]
18 | name = "Serena Duncan"
19 | +++
20 |
21 | # Project Goal
22 | Our goal was to build a compiler from Bril to WebAssembly. To do this, we collaborated with another group consisting of Gerardo Teruel and Dev Patel, who worked on the “Brilooped” project; this project took Bril, a CFG-based language with unstructured control flow, and changed it to a structured control flow language by creating a relooper for Bril. This means that all the branch and jump statements in Bril were replaced by while/continue/break statements. After agreeing on a shared syntax for the output of their project as the input of ours, we were able to take their project as finished and compile the Brilooped syntax to WebAssembly, which also uses structured control flow.
23 |
24 | # Implementation
25 | We built a tool to compile Bril programs into wasm, and then executed the resulting program using [Wasmtime](https://docs.Wasmtime.dev/). This allowed us to test our output WebAssembly programs for correctness and performance against the original equivalent Bril programs.
26 |
27 | The bulk of the project was matching across the input JSON Brilooped instruction types, and converting them linearly into WebAssembly instructions. For the most part, we used a simple system of storing all variables in WebAssembly locals and shuttling them onto and off the stack only when needed for each instruction. This may not be as efficient as a more sophisticated register allocation algorithm, but it allowed us to guarantee correctness with high confidence.
28 |
29 | We anticipated that the most difficult instructions to translate would be those involving control flow– namely, `if`, `while`, `break`, and `continue`, as these would have to be translated while keeping in mind the context of the rest of the program; for example, how many nested `while`/`if` statements we were breaking out of. Luckily, we were able to convert Bril `if` into the WebAssembly `if` instruction directly, simply changing the syntax as otherwise the instructions act statically the same. For `while` commands, there was a slight wrinkle to address, which was the fact that WebAssembly only allows code to jump to the top of a loop, and not out of one. This made implementing `break` difficult. To solve this problem, we wrapped an outer WebAssembly `block` with an inner `loop`, since `block` constructs can be arbitrarily exited from. Thus, any `continue` statements could jump back to the top of the inner loop, while `break` could then jump out of the outer block. To implement the proper semantics of nested loops, we maintained a stack of label names at compile-time, one label for each nested loop, so when we needed to break multiple layers back, we could simply pop an appropriate number of entries off our stack to find the proper jump target.
30 |
31 | ## Printing
32 | One thing to note is that we used Gemini to generate a runtime library, which provides functions to print base values– ints and bools– to the terminal. We could then statically link this into our output WebAssembly program that we generated. We made this choice because this process of printing WebAssembly values was highly nontrivial but also extremely non-interesting to the aims of the project, namely the translation between Bril (in Brilooped form) and WebAssembly. However, we found that using Gemini was nearly as much of a struggle as writing the code ourselves; it took nearly 10 back and forth interactions to get something that was even compiled.
33 |
34 | # Challenges
35 | In general, we found that the earliest parts of the project were the most difficult. At first, we had to decide what language to work in, as the three of us had been using different languages for our 6120 homework assignments all semester long; Serena using Rust, Annabel using Python, and Michael using TypeScript. Eventually, we decided TypeScript would be the most natural choice for this project due to its robust type system and ease of learning. However, it was still difficult as Serena and Annabel had limited experience using this language.
36 |
37 | Crucially, no one on our team had substantial prior experience with WebAssembly itself. This made it difficult at the very start of the project to know how to even begin– we went crawling through the WebAssembly documentation, but unfortunately most of the examples and documentation we found online did not match the kind of thing we needed from the documentation; the general use case for WebAssembly is compiling into it using someone else’s compiler program, so much of the documentation is geared toward this use-case rather than encoding in WebAssembly itself. Much of the first half of the time we spent working on the project was simply sitting with the WebAssembly documentation, trying to understand the way the system worked (we spent, for example, a good amount of time pursuing an implementation to emit the bytecode format of WebAssembly code rather than the text format, before deciding not to continue with this direction, nullifying a good deal of work).
38 |
39 | Another challenge was working with code created by another group in the class, who were working toward the same deadline we were. Throughout the course of their Brilooped project, they naturally ran into adjustments to the Brilooped format, which then cascaded into affecting our project as well; as the two were developing concurrently, we did not have a well of extensive Briloop documentation to refer back to when developing our programs. However, we did have the advantage of being able to talk to Dev and Gerardo in real time. We could, and did, ask for help directly whenever we ran into trouble, and they were really really helpful in helping us get our input from Briloop working. We’re incredibly grateful for their help throughout this process.
40 |
41 | One more challenging aspect of the project was, for the limited capacity in which we used Gemini, wrangling the LLM to produce actually correct (or even executable) code; though it still probably saved us the time it would take to do the uninteresting bit ourselves, it was certainly not an effortless “get out of jail free” card.
42 |
43 | # Analysis
44 |
45 | ## Testing methodology
46 | We tested our code thoroughly on small examples as we implemented core functionality. This allowed us to catch errors before our code became too complex to fix. After completing our implementation, we tested on the Bril benchmarks core test suite. To do this, we first took [Briloop core benchmark translations](https://github.com/gerardogtn/cs6120-compilers/tree/main/project/core), provided by the Briloop group, and translated them into JSON files using their Briloop2JSON command. After, we ran the files through our code to output the WebAssembly translation, then ran this translation using Wasmtime. We compared the output of our WebAssembly files to the output from the original Bril files. With this method, we were able to confirm correctness, in the sense that the WebAssembly output program behaved identically on our test cases to the original Bril programs (1 test per benchmark).
47 |
48 | Note that our WebAssembly runtime prints all arguments one per line, instead of multiple arguments on the same line. Thus, our test cases ignored whitespace differences.
49 |
50 | ## Performance
51 | Fortunately (and perhaps unsurprisingly), the WebAssembly executed significantly faster in Wasmtime than the original Bril interpreter could run Bril files. Using a script that runs all of the core benchmarks in sequence using the provided arguments, we benchmarked performance using [Hyperfine](https://github.com/sharkdp/hyperfine) on a Windows machine with an AMD Ryzen 9 6900HS processor with Deno 2.3.1 and Wasmtime 34.0.0. The original Bril interpreter took a mean of 3.883 seconds with a standard deviation of 0.106 seconds to run through the entire folder. The WebAssembly versions took only 1.043 seconds with a standard deviation of 0.044 seconds. This is an observed speed increase of over 73.1%.
52 |
53 | ## Notes and Future Work
54 | There is some future work to explore. For example, we currently do not support Bril programs that have variables change types after declaration and during execution; this kind of instruction is available in both Bril and WebAssembly syntax.
55 |
56 | Also, to replace our Gemini-generated runtime library that we used to print test cases, we could, instead of writing print functions directly in WebAssembly S-expressions, write them in some other language and then compile them to wasm, using Clang or some similar process. This would be a perhaps more efficient way to complete this step of execution.
57 |
58 | As we noted above, our WebAssembly output prints arguments each on their own line, rather than on the same line. To make our project work with arguments printed on the same line, using the method of compiling our printing functions using Clang or something similar, we could simply take in a command like ‘print a b c’ and compile it to print commands which thread in spaces between each argument.
59 |
60 | We currently only support core Bril instructions. Implementing floats proved to be rather tricky as we would have needed to write our own float printing function in WebAssembly. Since the WebAssembly documentation is rather sparse for how to actually code in the language, we decided to leave this as work for the future. For memory, the way WebAssembly handles memory is very different from how Bril handles it. Support for memory would require digging much further into the WebAssembly (and Bril) internals than we had time for, so this was also left for the future.
61 |
--------------------------------------------------------------------------------
/content/blog/2025-05-13-brilooped/log_scale_comparison.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/sampsyo/cs6120/8d343c04f6a6bd3ff783de0abda6b282c96791ae/content/blog/2025-05-13-brilooped/log_scale_comparison.png
--------------------------------------------------------------------------------
/content/blog/2025-05-13-brilooped/merge-nodes.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/sampsyo/cs6120/8d343c04f6a6bd3ff783de0abda6b282c96791ae/content/blog/2025-05-13-brilooped/merge-nodes.png
--------------------------------------------------------------------------------
/content/blog/2025-05-13-brilooped/relative_change.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/sampsyo/cs6120/8d343c04f6a6bd3ff783de0abda6b282c96791ae/content/blog/2025-05-13-brilooped/relative_change.png
--------------------------------------------------------------------------------
/content/blog/2025-05-13-brilooped/size_vs_change.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/sampsyo/cs6120/8d343c04f6a6bd3ff783de0abda6b282c96791ae/content/blog/2025-05-13-brilooped/size_vs_change.png
--------------------------------------------------------------------------------
/content/blog/2025-05-13-brilooped/speedup_comparison.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/sampsyo/cs6120/8d343c04f6a6bd3ff783de0abda6b282c96791ae/content/blog/2025-05-13-brilooped/speedup_comparison.png
--------------------------------------------------------------------------------
/content/blog/2025-05-13-brilooped/top_improvements.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/sampsyo/cs6120/8d343c04f6a6bd3ff783de0abda6b282c96791ae/content/blog/2025-05-13-brilooped/top_improvements.png
--------------------------------------------------------------------------------
/content/blog/2025-05-13-brilooped/top_regressions.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/sampsyo/cs6120/8d343c04f6a6bd3ff783de0abda6b282c96791ae/content/blog/2025-05-13-brilooped/top_regressions.png
--------------------------------------------------------------------------------
/content/blog/2025-05-13-flat-bril/bench_results.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/sampsyo/cs6120/8d343c04f6a6bd3ff783de0abda6b282c96791ae/content/blog/2025-05-13-flat-bril/bench_results.png
--------------------------------------------------------------------------------
/content/blog/2025-05-13-flat-bril/heap_figure1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/sampsyo/cs6120/8d343c04f6a6bd3ff783de0abda6b282c96791ae/content/blog/2025-05-13-flat-bril/heap_figure1.png
--------------------------------------------------------------------------------
/content/blog/2025-05-13-flat-bril/heap_figure2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/sampsyo/cs6120/8d343c04f6a6bd3ff783de0abda6b282c96791ae/content/blog/2025-05-13-flat-bril/heap_figure2.png
--------------------------------------------------------------------------------
/content/blog/2025-05-13-flat-bril/stack_chart1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/sampsyo/cs6120/8d343c04f6a6bd3ff783de0abda6b282c96791ae/content/blog/2025-05-13-flat-bril/stack_chart1.png
--------------------------------------------------------------------------------
/content/blog/2025-05-13-flat-bril/stack_chart2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/sampsyo/cs6120/8d343c04f6a6bd3ff783de0abda6b282c96791ae/content/blog/2025-05-13-flat-bril/stack_chart2.png
--------------------------------------------------------------------------------
/content/blog/2025-05-13-global-value-numbering/index.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Global Value Numbering for Bril"
3 | [extra]
4 | bio = """
5 | Allen Wang is a CS M.Eng student at Cornell University. He's pretty tired right now.
6 | """
7 | [[extra.authors]]
8 | name = "Allen Wang"
9 | +++
10 |
11 | ### Overview
12 |
13 | The goal of this project was to implement global value numbering for Bril programs using value partitioning. I then used this to perform redundancy elimination using available expressions and benchmarked the performance impact.
14 |
15 | ### Value Numbering
16 |
17 | Value numbering is a family of program analysis techniques that involve assigning an identifying (value) number to each expression, where expressions that are guaranteed to evaluate to the same value have the same identifying number. By separating values from expressions, we can find duplicate expressions that are syntactically different but evaluate to the same value as already-existing expressions, then remove them. For example, we can use value numbering on this program:
18 | ```
19 | sum1 : int = add a b;
20 | sum2 : int = add b a;
21 | prod: int = mul sum1 sum2;
22 | ```
23 | To find out that sum1 and sum2 evaluate to the same value, then optimize it to:
24 | ```
25 | sum1 : int = add a b;
26 | prod: int = mul sum1 sum1;
27 | ```
28 | We went over one value numbering algorithm [here](https://www.cs.cornell.edu/courses/cs6120/2025sp/lesson/3/). However, this algorithm assumes a single linear control flow, which means it's only suitable for local value numbering within blocks.
29 |
30 | ### Global Value Numbering
31 |
32 | Global value numbering is a set of techniques which perform value numbering at the level of a function, rather than a single block. [This paper](https://www.cs.tufts.edu/~nr/cs257/archive/keith-cooper/value-numbering.pdf) goes over hash-based and partitioning implementations of global value numbering. There's already a hash-based implementation for Bril [here](https://www.cs.cornell.edu/courses/cs6120/2019fa/blog/global-value-numbering/) and it's very conceptually similar to local value numbering, so I decided to implement value partitioning instead.
33 |
34 | ### Value partitioning
35 |
36 | Instead of hashing expressions to values like local value numbering, value partitioning works by directly computing congruence classes of expressions, where two expressions are congruent if they have the same opcode and all their arguments are congruent with each other. To perform value partitioning, we first put a program into SSA to ensure that each value has a unique variable associated with it. We assume that all operations of a type are in the same congruence class, then repeatedly partition congruence classes where this cannot be true until we obtain a maximum fixed point.
37 |
38 | We implemented this algorithm for value partitioning, which was given in the paper:
39 | ```
40 | Initial partition: all values computed by the same opcode are in the same congruence classes
41 |
42 | worklist = classes in initial partitio
43 | while worklist is not empty:
44 | select a class c from worklist
45 | for each possible arg position p:
46 | touched = ∅
47 | for each value v:
48 | if arg p of v is in c, add v to touched
49 | for each class s where some but not all members are touched:
50 | n = s & touched
51 | s = s - n
52 | if s in worklist:
53 | add n to worklist
54 | else:
55 | add smaller of n and s to worklist
56 | ```
57 | After this, we pick a representative for each congruence class, then replace every operation of that type with the representative.
58 |
59 | ### Redundancy Elimination
60 | After standardizing our program to use values instead of expressions, we still need to convert this into a performance improvement. To do this, we use an available expressions dataflow analysis to calculate which values are available at each point in the program. Fortunately, the properties of the renaming algorithm make it very easy to define the analysis for calculating available expressions.
61 |
62 | - The initial input is the empty set.
63 | - The transfer function takes the union of a block's input and every expression in the block. If an expression already exists, it's redundant and can be removed.
64 | - The merge function takes the intersection of all the outputs of a block's predecessors.
65 |
66 | I also tried implementing partial redundancy elimination, which moves computations that are redundant along some execution paths back through the control graph to turn them fully redundant and optimize them away. This can be accomplished by performing global analyses to determine where computations can be safely moved and where moving them would save time, but I didn't have time to fully wrap my head around this and fix the bugs.
67 |
68 |
69 |
70 | #### Implementation Notes
71 |
72 | Getting GVN right was very finicky and required reading the text very carefully. My biggest struggles in the end were first understanding the processing algorithm, then figuring out and debugging all the edge cases that arose from not reading the paper carefully enough. The most annoying edge case I ran into was handling phi statements. I kept getting differences in code execution, and after going through the source code and a log of instructions executed, I discovered that phi statements were mysteriously being removed. After this, I managed to pinpoint that the problem was that the phi statements could not be congruent with phi statements in other blocks and fixed this. Immediately after, I read through the paper again and found that it mentioned this in an aside ... I also had a lot of trouble implementing copy propagation to match the hash-based implementation, then discovered that the paper explicitly used this as an example of an optimization that couldn't be done using value partitioning in a later section.
73 |
74 | ### evaluation
75 |
76 | For correctness, I ran my optimizations on the core benchmarks with different inputs to test whether they would cause problems. I also wrote a series of test cases for various edge cases and optimizations GVN should be able to identify. Each of the benchmarks and hand-written test cases produced the same outputs before and after optimization. I also verified that the benchmarks were able to catch incorrect implementations while fixing bugs.
77 |
78 | For performance, I tested against the core benchmarks, using the same inputs as the correctness tests. I found that using only the AVAIL-based removal resulted in a minimum improvement of 0% less instructions executed (as global value numbering doesn't add any operations to a program), a median improvement of 1.5% less instructions executed compared to base SSA, and a maximum improvement around 58% less instructions executed. Most of the benchmarks were written directly in Bril, so they were relatively optimized and there were few opportunities to identify congruence classes across blocks.
79 |
80 | 
81 |
--------------------------------------------------------------------------------
/content/blog/2025-05-13-global-value-numbering/plot.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/sampsyo/cs6120/8d343c04f6a6bd3ff783de0abda6b282c96791ae/content/blog/2025-05-13-global-value-numbering/plot.png
--------------------------------------------------------------------------------
/content/blog/2025-05-13-polyhedral.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "A Simplified Polyhedral IR for Bril"
3 | [[extra.authors]]
4 | name = "Mark Barbone"
5 | +++
6 |
7 | In [this project][github], I set out to build a polyhedral IR for Bril
8 | programs. My original goal was to implement polyhedral optimizations on it;
9 | however, simply constructing and going out of a polyhedral IR ended up being
10 | complex enough that it filled my budget.
11 |
12 | [github]: https://github.com/mb64/cs6120-work/tree/main/poly
13 |
14 | ## Background
15 |
16 | Here's an example program:
17 |
18 | ```c
19 | for (i = 0; i < N; i++) {
20 | for (j = i; j < N; j++) {
21 | foo(i, j);
22 | }
23 | }
24 | ```
25 |
26 | This program has a pretty complex control flow graph -- each `for` loop is
27 | hiding whole host of basic blocks that it compiles to. Often, this is great
28 | for a compiler, as breaking up the control flow into small but regular pieces
29 | means that general-purpose optimizations can handle all kinds of programs
30 | uniformly.
31 |
32 | However, sometimes we want to do more high-level optimizations. For example, it
33 | may be possible to interchange the two loops:
34 |
35 | ```c
36 | for (j = 0; j < N; j++) {
37 | for (i = 0; i <= j; i++) {
38 | foo(i, j);
39 | }
40 | }
41 | ```
42 |
43 | Figuring out how to do this interchange correctly is extremely non-trivial,
44 | even on the high-level `for`-loop-containing program text! For this, it would
45 | be very convenient to have some intermediate language that explicitly accounts
46 | for iteration spaces like `{ [i, j] : 0 <= i and i <= j and j < N }`, so that
47 | these transformations would be possible. This is precisely the goal of the
48 | _polyhedral model_. In my IR, this is represented as:
49 |
50 | ```c
51 | for (i ∈ { [i] : 0 <= i < N }) {
52 | for (j ∈ { [i, j] : 0 <= i <= j < N }) {
53 | foo(i, j);
54 | }
55 | }
56 | ```
57 |
58 | Here, the iteration domain appears as a first-class entity in the IR's looping
59 | constructs. I don't exactly use the classic polyhedral framework, but rather a
60 | simplified form inspired by [MLIR's simplified form][mlir], and I'll explain
61 | the details in the next section.
62 |
63 |
64 | ## The intermediate representation
65 |
66 | A classic polyhedral IR has a bag of ordered statements, each with an
67 | associated domain of points on which it's run, and an associated schedule of
68 | when to run it, in the form of an affine function outputting a timestamp.
69 |
70 | With this classical representation, turning it all back to code in the end is
71 | very hard: you need to come up with an optimal set of loops and `if` statements
72 | that correctly implements the ordering requested by the schedule, all without
73 | incurring too much blow-up or obscuring hot loops with too many conditionals.
74 | Here are a few papers I found on how to do this, roughly ordered by how complex
75 | their algorithms are: [IJPP'00][ijpp-00], [PACT'04][pact-04], [TOPLAS'15][toplas-15].
76 |
77 | [ijpp-00]: https://link.springer.com/article/10.1023/A:1007554627716
78 | [pact-04]: https://icps.u-strasbg.fr/~bastoul/research/papers/Bas04-PACT.pdf
79 | [toplas-15]: https://lirias.kuleuven.be/retrieve/319112
80 |
81 | Because of this (and other reasons), [MLIR introduced][mlir] a _simplified_
82 | polyhedral representation, which has an explicit representation of iteration
83 | domains, and the analysis / transformation benefits that affords, but also a
84 | preferred way of iterating over it.
85 |
86 | I copied their ideas to design my own IR, which has iteration domains
87 | represented as integer sets (using ISL, the Integer Set Library), but also has
88 | a relatively straightforward interpretation as code:
89 |
90 | ```
91 | s ::= for (i ∈ affine domain) { ss } (single-variable for loop)
92 | | if (affine condition) { ss } (conditionals)
93 | | instr_1; ...; instr_N (basic blocks)
94 |
95 | ss ::= s_1; ...; s_N
96 | ```
97 |
98 | Here, both `affine domain` and `affine condition` are integer sets; the only
99 | difference is that `affine domain` introduces a new variable, while `affine
100 | condition` does not.
101 |
102 | A core insight is that we have _static control flow_: there is a subset of
103 | variables, which I'll call "affine variables", which are only transformed in
104 | very easy-to-reason-about ways, and moreover, control flow only depends on
105 | these variables. Of course, not every program has this format, but we still
106 | want to be able to optimize the programs that do, while leaving those that
107 | don't.
108 |
109 | ## To `affine`-ity, and beyond!
110 |
111 | We've made the process of emitting code out of our IR easier, with the
112 | simplified polyhedral representation. But how do we get it there in the first
113 | place? This is still fairly tricky!
114 |
115 | Static control flow is a subset of structured control flow, so it makes sense
116 | to start with a program with structured control flow. Bril doesn't have
117 | structured control flow, but we know that it's possible to construct if you
118 | have reducible control flow. So the first step is to reconstruct the structured
119 | control flow of the input Bril program. This is the job of the relooper.
120 |
121 | Given a Bril function as input, the relooper either:
122 |
123 | * raises an exception, if it has irreducible control flow, or
124 | * returns a Bril AST with structured control flow.
125 |
126 | Here's what this structured control flow IR looks like:
127 |
128 | ```
129 | c ::= block .l { c1 } c2 (l is in scope for c1 but not c2)
130 | | loop .l { c } (l is in scope for c)
131 | | instr_1; ...; instr_N; c
132 | | if b then c else c
133 | | jmp .l
134 | | ret v
135 | ```
136 |
137 | A jump to label `.l` is only allowed when `.l` is in scope (this is what makes
138 | it structured!). Jumping to a `block` label is like a `break`, escaping to the
139 | end of the block, while jumping to a `loop` label is like a `continue`, going
140 | back to the loop header for the next iteration.
141 |
142 | I mostly follow the algorithm from [Beyond Relooper (PLDI'22 functional
143 | pearl)][beyond-relooper], though my structured IR looks a little different, and
144 | I don't make any effort to do anything with irreducible CFGs.
145 |
146 | [beyond-relooper]: https://dl.acm.org/doi/abs/10.1145/3547621
147 |
148 | This is far more structured than a sea of basic blocks, but still a far cry
149 | from our nice static control flow! The next step is to recursively process the
150 | structured IR, eventually getting to the simplified polyhedral representation.
151 | This step is by far the most complex, accounting for a large portion of the
152 | code, and with many tricky cases to consider. The biggest difference between
153 | the structured IR and the polyhedral IR, other than that the polyhedral IR has
154 | static control flow, is that code in the structured IR can have multiple exits:
155 | you can branch to any label that's in scope, depending on whatever conditions
156 | you want. By contrast, the polyhedral IR can only go on to the next statement.
157 | The combination of both multiple exits and recovering static control flow makes
158 | this a complex implementation task.
159 |
160 | [mlir]: https://mlir.llvm.org/docs/Rationale/RationaleSimplifiedPolyhedralForm/
161 |
162 | ## Evaluation
163 |
164 | I evaluated the code in three different ways:
165 |
166 | 1. Correctness
167 | 2. Performance overhead incurred by round-tripping through the IR
168 | 3. Applicability of potential polyhedral optimizations
169 |
170 | For all three, I used both the core Bril benchmark suite and the memory
171 | benchmark suite. Sadly, as I didn't get to implement any real polyhedral
172 | optimizations, I don't have speed-ups to measure (yet?).
173 |
174 | **Correctness.** I tested correctness of round-tripping just through the
175 | relooper, and then also through the polyhedral IR, by comparing against
176 | interpreting the original code.
177 |
178 | **Performance.** On the combined mem and core benchmarks, round-tripping
179 | through the polyhedral IR gives a mean 0.78x speedup. However, my compiler at
180 | the moment does zero backend optimizations, which would be quite useful to
181 | clean up the code. I expect this to go back to close to 1x with simple backend
182 | clean-up optimizations.
183 |
184 | **Applicability.** Not every program has static control flow, so only some
185 | could potentially benefit from future polyhedral optimizations. In the combined
186 | mem and core benchmarks, 176 out of 272 functions had fully static control
187 | flow, or around 65%. Considering just the relooper, interestingly, all 272
188 | functions in these combined test suites exhibit reducible control flow, and
189 | successfully round-trip through just the structured control flow IR.
190 |
191 |
--------------------------------------------------------------------------------
/content/blog/2025-05-13-superopt/canonical-example-after.svg:
--------------------------------------------------------------------------------
1 |
2 |
4 |
6 |
7 |
156 |
--------------------------------------------------------------------------------
/content/blog/2025-05-13-superopt/canonical-example-before.svg:
--------------------------------------------------------------------------------
1 |
2 |
4 |
6 |
7 |
105 |
--------------------------------------------------------------------------------
/content/blog/2025-05-13-superopt/simple_2_output_before.svg:
--------------------------------------------------------------------------------
1 |
2 |
4 |
6 |
7 |
134 |
--------------------------------------------------------------------------------
/content/blog/2025-05-14-bril-to-x86.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "A Bril to x86 Compiler"
3 | [[extra.authors]]
4 | name = "Tean Lai"
5 | +++
6 |
7 | ## Goal
8 | The goal of [the project](https://github.com/tean-lai/bril-to-x86) was to build a Bril compiler targeting x86_64. The priority of the project was to implement something working, and not necessarily something optimal. So for this project, things like register allocation were out of scope.
9 |
10 | ## Design and Implementation
11 | The current implementation was done in Python and it supports all the core features of Bril. I decided to go with Python despite its slowness because it's fast to iterate with, but I would expect the process of converting it to another language to be extremely smooth.
12 |
13 | The overall design of the compiler at a high-level is relatively simple. The design of Bril resembles assembly, so the compiler just needs to do linera passes converting each instruction at a time to the relevant code. The program does two main passes: first it converts all the Bril instructions into another intermediate representation that is a one-to-one correspondence to an x86 instruction. Then the second pass will actually produce the assembly program and format it. The reason I decided to go with splitting it into two passes as opposed to printing the program directly was because there are multiple different syntaxes for x86, so the intention was if different syntax styles were to be supported, the changes would be more isolated. For the project, I implemented support for Intel syntax.
14 |
15 |
16 | ## The Tricky Parts
17 | Although at a high level, things were simple, the details were tricky to get right. The first big hurdle was actually getting a compiled program to run. This required support for several Bril instructions, you would need to support constants, and either printing or returning in order to observe that some changes had happened. But it also required support for some calling conventions to be supported, otherwise the program wouldn't terminate. What helped got me over this hurdle proved to be quite useful in general for developing this compiler, which was modeling Bril programs as C programs and comparing my Bril -> x86 results with Clang's C -> x86 results. This helped me find stuff like the following snippet of text, which I would include at the beginning of every file for generating code targeting MacOS:
18 |
19 | ```
20 | .section __TEXT,__text,regular,pure_instructions
21 | .build_version macos, 15, 0 sdk_version 15, 2
22 | ```
23 |
24 | These directives seemed to vary quite a bit device-to-device; but I found comparing with a reference compiler was a reliable way of finding out what directives are necessary. Online sources often lack the specific things you need for your own device.
25 |
26 | It was also quite tricky to get printing right. I implemented Prof. Sampson's suggestion of linking the printing with a helper [rt.c file](https://github.com/sampsyo/bril/blob/main/brilift/rt.c) to avoid printing Booleans by hand. To get linking right, again it helped a lot to model the behavior I would expect in an equivalent C program, and guide my implementation to match that output.
27 |
28 | Another tricky part was getting command line arguments handled correctly. A particularly trick case is the following Bril program:
29 | ```
30 | @main(x: int) {
31 | n: int = const 10;
32 | b: bool = lt x n;
33 | br b .loop .done;
34 | .loop:
35 | one: int = const 1;
36 | print x;
37 | y: int = add x one;
38 | call @main y;
39 | .done:
40 | ret;
41 | }
42 | ```
43 | This program takes in a single int as a command line argument, and keeps printing its value and incrementing it until it hits 10. The tricky part comes from the fact that this function also calls itself. So this means the assembly code for this function must somehow handle both command line parsing and support proper calling conventions when it's called as a normal function. More concretely, in x86, it's expected that the main function's first and second parameters are `argc` and `argv` respectively. But we also want the main function's first function to be `x`.
44 |
45 | The solution to this problem was to wrap the main function with a separate function that first handles command line arguments, and then calls the real main function with the proper arguments. However, the current implementation for this might cause bugs for 0.1% of Bril programs because it creates another function called "main_main", so any Bril programs with such a function name might run into some issues.
46 |
47 | However, one big downside of this compiler is that it doesn't work for plenty of devices. There are more cases that need to be hard-coded differently for different devices. For example, MacOS starts their program with the _main label, but for Linux it looks for a _start label. Since I primarily developed this on a Mac, it was hard to get support for more devices working. Extending support to different devices doesn't seem too hard, it seems like a matter of adding different formatting and wrapping the program with different assembly programs, but this is seems hard to do without multiple devices.
48 |
49 | ## What wasn't tricky
50 | It was nice to see how smooth most instructions were to convert to x86. Most instructions were a very close correspondence, with the only exception being the boolean comparison operators. But that seemed to be because x86 doesn't have instructions for things like less than, unlike RISC-V, but this wasn't too bad overall to implement.
51 |
52 | ## Evaluation
53 | I had wanted to evaluate on several things, like comparing this compiler to other aot compilers like [Brilift](https://capra.cs.cornell.edu/bril/tools/brilift.html), but I didn't end up with enough time for that.
54 |
55 | To test for correctness, I have an automated script that interprets every core benchmark against brili and uses that as a reference. And fortunately, every output matches! It checks for both matching standard outs and matching exit codes. I can confidently say this compiler preserves correctness in 95% of programs, the estimated missing 5% being from programs that start have a "main_main" function and functions with more than 6 arguments. The current implementation does not support more than 6 arguments since calling conventions only reserve 6 registers for function calls.
56 |
57 | Overall, this was a pretty fun project and I definitely learned a lot about x86 and am glad I don't normally program at such a low level.
--------------------------------------------------------------------------------
/content/blog/2025-05-bril2c.md:
--------------------------------------------------------------------------------
1 |
2 | +++
3 | title = "Bril2C"
4 | [extra]
5 | bio = """
6 | Mahmoud is an MEng student enrolled in CS6120 as of Spring 2025.
7 | """
8 | [[extra.authors]]
9 | name = "Mahmoud Elsharawy"
10 | +++
11 |
12 | This project is intended to translate code from [Bril](https://capra.cs.cornell.edu/bril/) (Big Red Intermediate Language) to C. Bril is an educational intermediate language used in the CS6120 course at Cornell University. As an intermediate language, it is low-level, which would make it difficult to translate to a high-level language. However, C, with features such as manual memory management and goto statements, makes it a natural choice. In my initial proposal, I thought creating a complete and correct translation from Bril to C would be trivial, but indeed quite a bit of hacking was needed, due to limitations of C not placed on Bril.
13 |
14 | ## Implementation
15 | Bril2C is written in Rust, using the "bril-rs" package. Most of the actual translation work happens in a single trait, `Crep`, which contains a single function `crep(self) -> String`. Each piece of Bril implements this function with how it translates itself to C, calling `crep` on smaller pieces, effectively inducting on the structure of the program. For example, `crep` for a program will, along with other things, call `crep` for each function in that program, which will call `crep` for each instruction, which will call `crep` for each operation and variable. In this way, adding additional features of Bril into C becomes as easy as implementing a single function for a specific type.
16 |
17 | As it turns out, quite some fiddling is required to get even a majority of Bril code working. Almost all of the benchmarks have `main` function which takes in arguments, something not possible in C. We get around this by creating our own `main` function in C, which parses arguments from the command line, and passes them into a copy that's supposed to represent the Bril's main function, called `main_f`. Taking an example, `sum-bits.bril`, with a main function that takes in a single integer argument, this is represented as:
18 | ```C
19 | int main(int argc, char *argv[]) {
20 | int64_t input = atoi(argv[1]);
21 | main_f(input);
22 | return 0;
23 | }
24 | ```
25 | This way the resulting program can take in arguments from the command line for the main function in the same way as `brili`.
26 |
27 | Additionally, Bril's print statement isn't type-annotated, meaning some form of polymorphism is needed in C. We accomplish this by creating our own generic print macro, allowing us to call `print` as easily as it is called in Bril:
28 | ```C
29 | #define print(x)
30 | _Generic((x),
31 | int64_t: printf("%" PRId64 " ", x),
32 | uint8_t: printf("%s ", (x) ? "true" : "false"),
33 | double: printf("%.17f ", x))
34 | ```
35 | For ease of programming, each function declares all of the variables used in it at the beginning of the function. After that, it's a "simple" translation from Bril instructions to C statements. Therefore, the following function in Bril:
36 | ```
37 | @mod(dividend : int, divisor : int) : int {
38 | quotient : int = div dividend divisor;
39 | two : int = const 2;
40 | prod : int = mul two quotient;
41 | diff : int = sub dividend prod;
42 | ret diff;
43 | }
44 | ```
45 | becomes this C function:
46 | ```C
47 | int64_t mod_f(int64_t dividend_, int64_t divisor_) {
48 | int64_t quotient_;
49 | int64_t two_;
50 | int64_t prod_;
51 | int64_t diff_;
52 | quotient_ = dividend_ / divisor_;
53 | two_ = 2;
54 | prod_ = two_ * quotient_;
55 | diff_ = dividend_ - prod_;
56 | return diff_;
57 | }
58 | ```
59 | At this point, you may have noticed the additional characters in each variable name and suffix name. These are inserted to prevent Bril registers from being confused with C keywords, which is surprisingly popular in Bril code, especially for words like `if` and `continue`.
60 |
61 | In order to capture the maximum subset of Bril, we also implemented the `memory` and `float` extensions to Bril. Adding these were surprisingly simple, as Bril's `alloc`, `free`, `load`, and `store` map rather painlessly to C's `malloc`, `free`, and referencing/dereferencing. To show a full example, `Bril2C` successfully translated this Bril code:
62 | ```
63 | # ARGS: 42
64 | @main(input : int) {
65 | sum : int = const 0;
66 | two : int = const 2;
67 | zero : int = const 0;
68 | .loop:
69 | cond : bool = eq input zero;
70 | br cond .done .body;
71 | .body:
72 | bit : int = call @mod input two;
73 | input : int = div input two;
74 | sum : int = add sum bit;
75 | jmp .loop;
76 | .done:
77 | print sum;
78 | ret;
79 | }
80 |
81 | @mod(dividend : int, divisor : int) : int {
82 | quotient : int = div dividend divisor;
83 | two : int = const 2;
84 | prod : int = mul two quotient;
85 | diff : int = sub dividend prod;
86 | ret diff;
87 | }
88 | ```
89 | into this C code:
90 | ```C
91 | #include 
7 |
8 | 13 | {% if post.extra.authors %} 14 | 19 | {% else %} 20 | 21 | {% endif %} 22 | 25 |
26 |
10 |
11 | 23 | See all posts on the course blog. 24 |
25 | 26 |28 | Many thanks to Zulip for sponsoring a free hosting plan for us. Zulip is a wonderful, open-source communication tool that works great for discussion-focused classes like ours. 29 |
30 | {% endblock main %} 31 | -------------------------------------------------------------------------------- /templates/index.html: -------------------------------------------------------------------------------- 1 | {% extends "base.html" %} 2 | {% block main %} 3 | {{ section.content | safe }} 4 | {% endblock main %} 5 | -------------------------------------------------------------------------------- /templates/lesson.html: -------------------------------------------------------------------------------- 1 | {% extends "base.html" %} 2 | {% block main %} 3 |26 | {% if page.extra.authors %} 27 |
39 | {{ page.content | safe }} 40 | 46 || 20 | 21 | {{ day.date | split(pat=" ") | nth(n=0) }} 22 | 23 | 24 | {{ day.date | split(pat=" ") | nth(n=1) }} 25 | 26 | | 27 |
28 | {% if day.event %}
29 | {{ day.event | markdown(inline=true) | safe }}
30 | {% else %}
31 | {% if class_idx < class_count %}
32 | {% set collapse = day.collapse | default(value=1) %}
33 | {% for collapse_idx in range(end=collapse) %}
34 | {% set class = content.classes[class_idx] %}
35 | {% set_global class_idx = class_idx + 1 %}
36 |
37 | {% if class.lesson %}
38 | {{ macros::lesson_link(id=class.lesson, title=true) }}
39 | {% endif %}
40 | {{ class.title | default(value='') }}
41 | {% if class.leader %}({{class.leader}}){% endif %}
42 | {% if class.readings %}
43 |
56 | {% endfor %}
57 | {% endif %}
58 | {% endif %}
59 |
|
60 |
61 |
|
74 |
|---|