The week 3 lab

What you're building

• Two new ops. range n is a loop counter named by its statement, and end x1 ... xk r repeats its effects for every value of r. See spec/uir-week3.md.
• Open ranges on every node, and the checks that use them. Asserts, calls and range bounds have none. An end must close a range its effects use. Each range is closed by exactly one end, which is what makes the loop nesting well defined. Every range a store uses is closed before its output. A buffer's output version sits outside every loop.
• Bounds through ranges. A range's interval is [0, n-1], so your week 1 analysis proves i*K + k in range with no new code beyond that one case.
• Placement and linearization. Each value at the depth of its deepest range, loads by the placement rule, each end as a block. One structure that both run and render walk.
• Loop-carried memory in run. Week 2's "a version is a value" interpreter can't express an accumulator. Executing the linearized blocks against mutable arrays can.
• Nested for loops in render, with loop-invariant values hoisted.

The command-line contract

Nothing new on the command line. run, simplify and render keep their contracts from weeks 1 and 2; what changes is which programs they accept and what render may print.

How render tests are graded

Exactly as in week 2, with one change to the loop check. For each # render test the grader:

1. runs your.exe render FILE and fails the test on a nonzero exit;
2. parses the program with the oracle and checks whether it contains a range. It then strips comments and string literals from your C and fails the test if it finds while, do or goto, or, when the program has no range, for;
3. writes its own main: one array per buffer filled with the data values (f32 from exact bits), a call to kernel in slot order, then one line per element;
4. compiles both files with clang -std=c11 -O2 -ffp-contract=off -fsanitize=undefined -fsanitize-trap=undefined ... -lm;
5. runs it and compares every element with the oracle: i32 and bool exactly, f32 bit for bit, any NaN matching any NaN.

Two new ways to fail. A loop bound or offset that overflows int32_t in your C is undefined behavior, so keep loop counters int32_t and do index arithmetic through the same uint32_t wrap as every other add and mul. And an accumulator loaded once outside its loop gives the wrong sum, not a crash: it shows up as a wrong value in the buffer.

Running the suite

From the course repo root, and keep the earlier weeks green while you work:

python tools/test.py --compiler "C:/path/to/your.exe" --week 3
python tools/test.py --compiler "C:/path/to/your.exe" --week 3 -k render -v   # just the render tests, with details
python tools/test.py --compiler "C:/path/to/your.exe" --week 2
python tools/test.py --compiler "C:/path/to/your.exe" --week 1

Pass the built executable, not dune exec: the grader runs tests in parallel. Tests live in tests/week3/run/ and tests/week3/render/.

Write your 10 tests

Ten tests in <your compiler repo>/tests/week3/, each aimed at a rule someone will get wrong. Check them against the oracle:

python tools/test.py --check-tests <your compiler repo>/tests/week3

Good targets: an accumulator whose load has to run inside the loop, a reset store indexed by the outer ranges, and a range bound of 0 (the loop runs zero times). Invalid cases make good targets too, such as an end that closes a range its effect doesn't use, or a range closed by two ends. Also try one end with two effects writing two buffers, and a padded convolution whose raw index is invalid but whose masked index passes.

%b  = buffer 4 dtype=i32 slot=0
%c  = buffer 4 dtype=i32 slot=1
%i  = range 4
%v  = shrink %b %i shape=[]
%s  = store %v 7
%e  = end %s %i
%b1 = after %b %e
%w  = shrink %c %i shape=[]
%s2 = store %w 8
%e2 = end %s2 %i
%c1 = after %c %e2