Pat Gavlin

> LCC gets in an infinite loop of spilling and reloading vAC. Initially it spills vAC at some point, which is fine and understandable. Later it reloads, but at that...

What does the full tree look like post-canonicalization?

Ah, I always forget that the post-canon trees aren't that helpful for diagnosing RA issues. Immediately prior to the register allocator, we should see `INDIRI2(ADDRLP2(a))` replaced by either `LOAD(INDIRI2(ADDRLP2(a)))` or...

`inset` is all my doing, so that's my bug. Thanks for fixing it :)

Ahh, now this is starting to make more sense. Here's the output of `dumpcover` from the debug logs: ``` RETI2(MULI2(LOAD(INDIRI2(ADDRLP2(a))), DIVI2(LOAD(INDIRI2(ADDRLP2(b))), INDIRI2(ADDRLP2(c))))) dumpcover(f080cdf8) = stmt: RETI2(reg) / (action) dumpcover(f080cd68) =...

We may want to try adding a `RELOAD` node to the `lcc` IR. We could then pattern-match against this node and use the additional information to generate appropriate code that...

From the logs, I think that the RA is creating this sequence when it spills r1: ``` 1. INDIRI2(ADDRLP2(a)) ; load local a into vAC (req'd due to the ldloc...

Here is `reprune`, which is called to refill the contents of `kids` with the appropriate entries from `x.kids`: ``` static int reprune(Node *pp, int k, int n, Node p) {...

A set of changes that fixes this specific instance is here: https://github.com/kervinck/gigatron-rom/compare/master...pgavlin:pgavlin/spill I am not terribly confident in these changes, however. I think that the result of `target` needs to...

The `lburg` changes are pretty innocuous. I had already made some target-independent changes to make it possible to generate code from callbacks based on a pattern match; the changes in...