This is a perfect benchmark. Having the exact source file and the resulting
generated C code gives us a clear "gold standard" to diff against.

Looking closely at the generated C code for `tests/string.c`, we can see
exactly how the GD LPC compiler deconstructs the source before doing any
AST/precedence resolution. Here is the anatomical breakdown of what we need to
replicate first:

### The Literal Extraction Pipeline (Target Analysis)

1. **Variable Hoisting (`_tmp_*` generation):**
Every single string literal (e.g., `"abcd123<XYZ>"`, `"Str: %s
"`) and integer literal (e.g., `-2`, `1`, `50`) in the source code is stripped
out during the initial pass and replaced with an internal reference
(`_tmp_string0`, `_tmp_int32`, etc.).
2. **Allocation Generation (`gd_allocate_vars`):**
These hoisted literals are dumped into the `gd_allocate_vars` block using
`new_variable_internal` and `variable_add_str`/`variable_add_int`.
3. **Operator Desugaring:**
* `str [-2..-1]` becomes `gd_range(str, _tmp_int32, TMP_INT(-_tmp_int33->i))`
* `str [1 .. 2] = ".b.c."` becomes `gd_range_set(...)`
* `str += str[0]` becomes `var_add(...)`


4. **Function Call Resolution:**
Standard calls become `void_call_2`, `call_1`, `call_3`, etc., referencing
dynamically generated function pointers like `&f_ptr_printf`.

---