[llvm-dev] Live Register Spilling

[Matthias Braun via llvm-dev]

> On Sep 10, 2017, at 7:01 PM, jin chuan see <jinchuansee at hotmail.com> wrote:
> 
> Sorry about the previous message 
> 
> This message showed up:
> llc: /home/jc/Desktop/Project/For_Testing/llvm/lib/CodeGen/MachineRegisterInfo.cpp:366: llvm::MachineInstr* llvm::MachineRegisterInfo::getVRegDef(unsigned int) const: Assertion `(I.atEnd() || std::next(I) == def_instr_end()) && "getVRegDef assumes a single definition or no definition"' failed.
Earlier backend phases are in "Machine SSA" form (you can check MachineRegisterInfo::isSSA() for that), meaning virtual registers are only allowed to have a single definition.

- Matthias

> 
> I am assuming that i messed up the virtual register allocation when i am using BuildMI().
> 
> Also, i cannot invoke the clang as -O1 and so on as it will optimize my code and the generated .ll file will contain nothing other than the prologue and epilogue code.
> Is there any information i can provide you so that we can discuss the issue further? 
> 
> Chuan. 
> 
> From: jin chuan see <jinchuansee at hotmail.com>
> Sent: Monday, September 11, 2017 9:57 AM
> To: Matthias Braun
> Cc: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] Live Register Spilling
>  
> Hi Matthias,
> 
> Sorry for the late reply. 
> Yes, you are correct, I do have optnone attribute on my function. 
> I did pass -O0 to the tools. 
> 
> For your information, my invocations are as below:
> 
> clang  --target=mips-unknown-linux  -mips32  test.c  -emit-llvm  -S
> llc  -O0  -march=mips  -mcpu=mips32  test.ll  -o  test.s
> 
> Based on the generated .ll file, there is optnone attribute on the function, i am guessing this is due to the default optimization -O0 by clang if not specified.
> As for the llc, i tried to invoke it with -O1,-O2,-O3. All of them resulted in failure during the phase "PROCESS IMPLICIT DEFS"
> This message showed up:
> 
> 
> From: mbraun at apple.com <mbraun at apple.com> on behalf of Matthias Braun <mbraun at apple.com>
> Sent: Saturday, September 9, 2017 2:06 AM
> To: jin chuan see
> Cc: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] Live Register Spilling
>  
> 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 <mailto: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/20170911/ba966b11/attachment.html>