[llvm-dev] Live Register Spilling

Matthias Braun via llvm-dev llvm-dev at lists.llvm.org
Fri Sep 8 11:06:35 PDT 2017


This would be a lot easier to discuss having a concrete example, llc invocations etc.

It sounds like you are using RegAllocFast, have you tried using the optimized register allocators (= make sure you don't have the optnone attribute on your function and are not passing -O0 to the tools).

- Matthias

> On Sep 8, 2017, at 12:10 AM, jin chuan see via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hi All, 
> 
> I faced some problems while using the BuildMI().
> Currently, i am trying to replace specific MI with a series of new MI.
> I wrote a routine under the processFunctionAfterISel() to detect the targeted MI and replace it accordingly.
> After using BuildMI() to perform my replacement, i realize there are unnecessary spilling and reloading of registers in the assembly generated.
> By checking the llc debug output, i am suspecting that the virtual register states have been completely messed up.
> This is because the spilling and reloading codes are only inserted at the register allocation phase, especially during the state of "Spilling live registers at the end of block".
> These spilling and reloading codes are messing up the assembly generated, and the behavior of the code generated is undetermined. 
> I would like to know is there anything i can do to fix the virtual register use-def relationship?
> Or is there any standard procedure i should follow to handle the MachineOperands while using BuildMI()?
> Any opinions or suggestion are welcomed.
> 
> Regards,
> JC
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170908/9e4202f0/attachment.html>


More information about the llvm-dev mailing list