[LLVMdev] problem trying to write an LLVM register-allocation pass

Lang Hames lhames at gmail.com
Wed Oct 31 17:51:00 PDT 2012


Hi Susan,

I'm having trouble reproducing that error on my end, but I think the
problem is probably that you're not using the VirtRegRewriter
infrastructure. What your allocator needs to do is populate the virtual
register mapping (VirtRegMap pass) with your allocation, rather than
rewriting the registers directly through MachineRegisterInfo.

Have your allocator require and preserve the VirtRegMap pass, then in your
runOnMachineFunction pass grab a reference to the pass with:

VirtRegMap &vrm = getAnalysis<VirtRegMap>();

You can then describe your register allocations with:

vrm.assignVirt2Phys(<virtreg>, <physreg>)

The VirtRegRewriter pass (in VirtRegMap.cpp) will run after your allocator
and apply the mapping that you described in the VirtRegMap.

I hope this helps. Let me know if it doesn't fix your issue.

Cheers,
Lang.

On Wed, Oct 31, 2012 at 3:54 PM, Susan Horwitz <horwitz at cs.wisc.edu> wrote:

> Thanks Lang!
>
> Here's another question: I'm trying to process this input:
>
> int main() {
>   return 0;
> }
>
> but I'm getting an error
>  Assertion `!Fn.getRegInfo().**getNumVirtRegs() && "Regalloc must assign
> all vregs"' failed.
>
> At the start of runOnMachineFunction I call Fn.getRegInfo().**
> getNumVirtRegs();
> and find that there is 1 virtual register.  However,  MRI->reg_empty(vreg)
> tells me that it is not used or defined.  So my register-allocation code
> never sees it, and thus can't allocate a preg for it.  I tried using
> MRI->replaceRegWith(vreg, preg);
> (where preg is available to vreg's register class) but that didn't work.
>  When I look, the number of vregs in the function is still 1.
>
> Can you help with this?
>
> Thanks again!
>
> Susan
>
>
> On 10/31/2012 04:55 PM, Lang Hames wrote:
>
>> Hi Susan,
>>
>> The meaning of "addRequired(X)" is that your pass needs X to be run, and
>> for X to be preserved by all passes that run after X and before your
>> pass. The PHIElemination and TwoAddressInstruction passes do not
>> preserve each other, hence there's no way for the pass manager to
>> schedule them for you if you addRequire(...) them.
>>
>> The trick is that CodeGen will schedule both of these passes to be run
>> before _any_ register allocation pass (see Passes.cpp), so you needn't
>> require them explicitly - you can just assume they have been run. If you
>> just remove those lines from your getAnalysisUsage method your pass
>> should now run as you expect.
>>
>> Cheers,
>> Lang.
>>
>> On Wed, Oct 31, 2012 at 1:46 PM, Susan Horwitz <horwitz at cs.wisc.edu
>> <mailto:horwitz at cs.wisc.edu>> wrote:
>>
>>     I'm trying to write a MachineFunctionPass to do register allocation.
>>       I have code that worked with an old version of LLVM.  It does not
>>     work with llvm-3.1. (or various other versions that I've tried).
>>
>>     The first problem is that including this line:
>>
>>       AU.addRequiredID(__**TwoAddressInstructionPassID);
>>
>>
>>     in method getAnalysisUsage causes a runtime error:
>>
>>     Unable to schedule 'Eliminate PHI nodes for register allocation'
>>     required by 'Unnamed pass: implement Pass::getPassName()'
>>     Unable to schedule pass
>>     UNREACHABLE executed at ...
>>
>>     I'm invoking the pass like this (given input file foo.c):
>>
>>     clang -emit-llvm -O0 -c foo.c -o foo.bc
>>     opt -mem2reg foo.bc > foo.ssa
>>     mv foo.ssa foo.bc
>>     llc -load Debug/lib/P4.so -regalloc=gc foo.bc
>>
>>
>>     I've attached my entire file (it's very short).  Any help would be
>>     much appreciated!
>>
>>     Susan Horwitz
>>
>>     ______________________________**_________________
>>     LLVM Developers mailing list
>>     LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>> http://llvm.cs.uiuc.edu
>>     http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121031/5e3eb831/attachment.html>


More information about the llvm-dev mailing list