[LLVMdev] Targeting a platform with virtual instruction set andunlimited virtual registers

Villmow, Micah Micah.Villmow at amd.com
Tue Oct 28 11:51:26 PDT 2008


Sanjay, I am working on backend with similar constraints using Method #1. You can use createVirtualRegister for all your register allocation needs. The only issue is that it currently resets the virtual register count at the beginning of each function call.  Look at the thread, "Virtual Register allocation across functions" to see possible solutions for this issue.

 

________________________________

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Sanjay Soman
Sent: Tuesday, October 28, 2008 11:41 AM
To: llvmdev at cs.uiuc.edu
Subject: [LLVMdev] Targeting a platform with virtual instruction set andunlimited virtual registers

 

I am working on a LLVM backend for a new platform. The target has a virtual instruction set and unlimited virtual registers. After going through LLVM documentation and source code, it looks like there are two possible ways to implement it with LLVM:

1) Method #1: follow common code generator path (TableGen, LLVMTargetMachine, etc), similarly as the Sparc and x86 targets. Since the target has unlimited number of virtual registers, register allocation is no use here. I can skip the register allocation by overloading the register allocator with one does no allocation. Is there any assumption in this infrastructure that would prevent from doing so?

2) Method #2: follow the custom code generator path, similar as the CBackend and MSIL targets.

 

I’d like to evaluate which method is more appropriate for this particular target. Method#1 provides some optimizations at machine instruction level (in this case, the virtual instruction set). Is the custom path capable of doing the same?

 

Thanks,

-Sanjay

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081028/3ed9d099/attachment.html>


More information about the llvm-dev mailing list