[LLVMdev] Register Allocation on IR

[Jonathan Roelofs]

On 6/17/15 1:53 PM, Kartik Ramkrishnan wrote:
> In my simulations, I am actually running the IR, rather than only
> evaluating cost function. I don't want to go too much into the details
> currently because I am hoping to get some results and publish them :)

Are you familiar with lli?  It is able to interpret, or "run" IR without 
doing register allocation (in addition to being able to JIT things). 
I'm not sure how close that is to the problem you're actually trying to 
solve, but there might be some infrastructure there you could leverage.


Cheers,

Jon

>
> I don't know if it will be useful for the LLVM codebase yet. If the
> weird IR proves to have useful application, then maybe that is possible.
>
>
> On Wed, Jun 17, 2015 at 2:10 PM, Renato Golin <renato.golin at linaro.org
> <mailto:renato.golin at linaro.org>> wrote:
>
>     On 17 June 2015 at 18:05, Matthias Braun <mbraun at apple.com
>     <mailto:mbraun at apple.com>> wrote:
>     > Having worked on SSA register allocators in the past I have to say that SSA is actually a good fit for register allocation. However LLVM IR is indeed not. You don't have any target instructions or register classed/constraints. It wouldn't make much sense to designate registers to llvm IR values nor is there a way to express that in IR. llvm has the machine instruction (MI) representation for that.
>
>     If I got it right, the intention here is to do simulations in IR. I'm
>     assuming this is some form of cost function that instead of executing,
>     would try to predict what would happen if it did run, without running.
>     For that, doing some form of register allocation in IR can actually be
>     beneficial from the register pressure point of view.
>
>     You could even do that in a generic way by just passing the ABI
>     register allocation first (what we do during lowering/legalization)
>     and then just letting the simulator know how many GPRs there are, and
>     the simulator can then estimate register pressure in basic blocks or
>     functions by using a poor-man's version of liveness analysis on the
>     remaining SSA registers in the sub-graph.
>
>     While this would be an interesting project, I can't see this being an
>     integral part of the LLVM codebase, as it would mess up the IR beyond
>     recognition by current back-ends.
>
>     cheers,
>     --renato
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded