forked from OSchip/llvm-project
32 lines
1.5 KiB
Plaintext
32 lines
1.5 KiB
Plaintext
|
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
|
||
|
|
|