| Chris Lattner | 6475bdf | 2001-07-06 22:00:42 +0000 | [diff] [blame] | 1 | Date: Fri, 6 Jul 2001 16:56:56 -0500 |
| 2 | From: Vikram S. Adve <vadve@cs.uiuc.edu> |
| 3 | To: Chris Lattner <lattner@cs.uiuc.edu> |
| 4 | Subject: lowering the IR |
| 5 | |
| 6 | BTW, I do think that we should consider lowering the IR as you said. I |
| 7 | didn't get time to raise it today, but it comes up with the SPARC |
| 8 | move-conditional instruction. I don't think we want to put that in the core |
| 9 | VM -- it is a little too specialized. But without a corresponding |
| 10 | conditional move instruction in the VM, it is pretty difficult to maintain a |
| 11 | close mapping between VM and machine code. Other architectures may have |
| 12 | other such instructions. |
| 13 | |
| 14 | What I was going to suggest was that for a particular processor, we define |
| 15 | additional VM instructions that match some of the unusual opcodes on the |
| 16 | processor but have VM semantics otherwise, i.e., all operands are in SSA |
| 17 | form and typed. This means that we can re-generate core VM code from the |
| 18 | more specialized code any time we want (so that portability is not lost). |
| 19 | |
| 20 | Typically, a static compiler like gcc would generate just the core VM, which |
| 21 | is relatively portable. Anyone (an offline tool, the linker, etc., or even |
| 22 | the static compiler itself if it chooses) can transform that into more |
| 23 | specialized target-specific VM code for a particular architecture. If the |
| 24 | linker does it, it can do it after all machine-independent optimizations. |
| 25 | This would be the most convenient, but not necessary. |
| 26 | |
| 27 | The main benefit of lowering will be that we will be able to retain a close |
| 28 | mapping between VM and machine code. |
| 29 | |
| 30 | --Vikram |
| 31 | |