sd:llvm_backend_for_sd-8516
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| sd:llvm_backend_for_sd-8516 [2026/06/18 05:22] – appledog | sd:llvm_backend_for_sd-8516 [2026/06/18 05:31] (current) – appledog | ||
|---|---|---|---|
| Line 46: | Line 46: | ||
| === Marking things SR | === 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? | + | 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? |
| + | == Meeting LLVM halfway | ||
| + | There are a lot of 'easy fixes' such as adding a LEA style instruction, | ||
| + | |||
| + | 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. | ||
sd/llvm_backend_for_sd-8516.1781760166.txt.gz · Last modified: by appledog
