[LLVMdev] Register Allocation on IR

[Kartik Ramkrishnan]

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 :)

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>
wrote:

> On 17 June 2015 at 18:05, Matthias Braun <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150617/dd652ab9/attachment.html>