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