| Age | Commit message (Collapse) | Author |
|---|
|
This is possible because we know that they are
represented by different integers.
|
|
I've been septic since I introduced it, this commit
proves that it costs more than it helps. I've also fixed
a bad bug in rega() where I alloc'ed the wrong size for
internal arrays. Enums now have names so I can use them
to cast in gdb to get the name corresponding to a constant.
|
|
|
|
This gives a more uniform use of the registers.
|
|
|
|
The substraction contrained the register allocator
to allocate a different register for the result and
the second operand, now, we use a neg trick to compile
it down. The machinery that was setup is, regardless,
interesting and will have to be used for floating
point computations (division).
The first bug in rega made broke the explicited loop
invariant: we were using register allocation unavailable
information from other blocks. It's still unclear
how we got wrong results from that considering mappings
are all 0-initialized.
The second bug is a stupid one, one sizeof operator was
missing from a memcpy...
|
|
|
|
This might not be a good idea, the problem was that
many spurious registers would be added to the Bits
data-structures during compilation (and would
always remain 0). However, doing the above
modification de-uniformizes the handling of temps
and regs, this makes the code longer and not
really nicer. Also, additional Bits structures
are required to track the registers independently.
Overall this might be a bad idea to revert.
|
|
|
|
The commutativity information only makes sense for
arithmetic expressions. To account for that, I introduced
a new tri-valued boolean type B3. Memory operations, for
example, will receive an undefined commutativity trit.
The code emitter was buggy when rega emitted instructions
like 'rax = add 1, rax', this is now fixed using the
commutativity information (we rewrite it in 'rax = add
rax, 1').
|
|
|
|
|
|
|
|
|
|
|
