[LLVMdev] Register Allocation on IR

[Matthias Braun]

llvm uses three different representations until machine code is emitted:

- the llvm language as specified in the llvm manuals, we usually call that IR
- the selection DAG
- machine code, which is often called MI

llvm currently only has infrastructure to serialize the first one. Register allocation only makes sense on the MI representation (before that we have no knowledge about register class or constraints, let alone which machine instructions will be used). Unfortunately MI cannot be serialized at the moment, although I think Alex Lorenz is currently working on adding this.

- Matthias

> On Jun 12, 2015, at 11:00 AM, kartikram3 <kartikram3 at gmail.com> wrote:
> 
> Hello all,
>  
>   I am trying to use the LLVM libraries to do register allocation on LLVM IR code -- and output IR as the result.
> There are two problems that arise when we try this : 
> 
> a. The LLVM backend requires that one goes through all the steps sequentially namely
>  
>      -- Instruction selection
>      -- Scheduling and Formation
>      -- SSA-based machine code optimizations
>      -- Register allocations 
> 
> 
>        ...
> 
> 
>       -- Code emission
> 
> Is it possible to emit IR from the 1st 3 stages and then do register allocation on it ?
> Normally, we would emit assembly based on the machine/ISA specifications during
> instruction selection.
> 
> b. I have llvm IR in the form of a DAG already. This was obtained by using the llvm;;parseIRFile
> function. I am not sure how to provide this ISA as an input to the backend phases as they
> seem to accept all kinds of other objects. 
> 
> Are there any llvm functions that accept a DAG as input so that we can do register allocation on it 
> subsequently ? 
> 
> 
> Note : This might look like a weird thing to do, but I want to do simulations on IR and getting a 
> register-allocated IR is useful for that purpose.
> 
> View this message in context: Register Allocation on IR <https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.1065342.n5.nabble.com_Register-2DAllocation-2Don-2DIR-2Dtp82414.html&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=2OblNhBarTDXhb_DrXgPBErQpK4kzZPCqObSAYnWrNw&s=tieOG_IuhO0b9Eri02OVFdSWvkr0zlhF0WFyiUI1zkc&e=>
> Sent from the LLVM - Dev mailing list archive <https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.1065342.n5.nabble.com_LLVM-2DDev-2Df3.html&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=2OblNhBarTDXhb_DrXgPBErQpK4kzZPCqObSAYnWrNw&s=Juy7RgBEqqIruJdLOsZMOwtOx_WfBU0iRbkQOe9TEOM&e=> at Nabble.com.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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