Differences

This shows you the differences between two versions of the page.

--- sd:llvm_backend_for_sd-8516 [2026/06/11 02:53] – appledog
+++ sd:llvm_backend_for_sd-8516 [2026/06/18 05:31] (current) – appledog
@@ Line 36: / Line 36: @@
 * [[Notes to Self from June]]
+* [[Runtime Library Notes]]
+=== Truncating i8 stores
+Truncating stores for i8-- STAL for char.
+"If it's legal, keep it legal" says reflect what the hardware actually does and skip the legalizer's splitting work. The reason it's wrong here isn't decisive here specifically is that the Legal path's matcher re-expresses the i8 trunc pattern at line ~278 (which is what byte-arithmetic narrowing relies on) and the GR8 at ~286 (ordinary char stores). So in this one case Legal means maintaining a third pattern that does what two existing ones already do.
+In the end it emits STAL [ptr] either way.
+=== Marking things SR
+Marking things SR does not protect against all stages of LLVM lowering. Sometimes disparate parts try to insert things between CMP and Bcc/Jcc. The solution is to fuse them in the backend. Ask yourself, does a branch instruction that relies on a CMP EVER //need// anything between the CMP and the branch? If so, since the branch is guaranteed, why not move the code into the branch?
+== Meeting LLVM halfway
+There are a lot of 'easy fixes' such as adding a LEA style instruction, that make it easier to write the backend. That's because LLVM, or at least the Lanai I was copying, use LEA. The fact is, it's a kludge to add an instruction solely to fix something in the backend. But we have that luxury. In the case of LEA, I could have added LD_IDXI16 or LEA and it would have masked the problem, likely for a long time. But the actual fix makes things bulletproof. That is the correct solution. Make LLVM work for the ISA, then change it later for optimization only. And, only if you want to. The more you optimize, the more you shift away from your own vision of the CPU/ISA and towards something generic.
+This is a hidden issue regarding C, compilers, and CPUs. The CPU has, for a long time, adapted to C. As C has adapted to the CPU. It's a symbiosis. But C won't last forever and maybe there are better ways to do things. If VAX can ship an __insque() maybe insque should be standard?
+Not everything is a lowest common denominator. That's bland. C, or some language else, should be able to reflect upon what makes a CPU special and unique. That's part of the joy of assembly; exploring truly new mindscapes of architecture. Realizing why certain ideas work better than others considering the hardware.