llvm dev - Nov 2012 - [LLVMdev] problem trying to write an LLVM register-allocation pass

Hi again Lang,

I decided to try the approach you proposed to see whether it makes the 
assembly-code problem go away.  Again, I tried a very simple register 
allocator (attached) that just calls vrm.assignVirt2Phys for every vreg 
in each function, mapping the vreg to the first preg in the register 
class.  I tried two versions: one maps *every* vreg, and the other only 
maps those for which MRI->reg_empty(vreg) returns false.  In both cases 
I get a core dump somewhere after my reg-allocation pass has run (when I 
use the "tst.c" file that I sent last time as input).

Note also that there is no VirtRegMap.h in the "include" directory of
my
installed llvm-3.1.  I had to copy that file from the source directory. 
  That seems suspicious.

Any thoughts?

Thanks!

Susan

On 10/31/2012 07:51 PM, Lang Hames wrote:
> 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
> <mailto: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>
>         <mailto: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>
>         <mailto: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 --------------
A non-text attachment was scrubbed...
Name: Gcra.cpp
Type: text/x-c++src
Size: 8001 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121101/8d008a71/attachment.cpp>

Hi Susan,

Sorry - I had missed that you're using llvm-3.1, rather than the
development branch. We encourage people to live on top-of-tree - it's well
tested, easier for active developers to offer help with, and keeping up
with incremental changes is often easier than porting between stable
versions.

It also sounds like you were building a Release version of LLVM. That will
not have any asserts enabled (though it will have some other diagnostics).
You will probably want to work with a Debug+Asserts version
(<src>/configure --disable-optimized --enable-assertions) while you're
developing your allocator and watch for any asserts that trigger.

In your case the Assertion that is triggering in PEI indicates that the
MachineRegisterInfo object still contained some virtregs post
register-allocation. You need to call MRI->clearVirtRegs() at the end of
your allocator.

Hope this helps!

Cheers,
Lang.

On Thu, Nov 1, 2012 at 2:41 PM, Susan Horwitz <horwitz at cs.wisc.edu>
wrote:
> Hi again Lang,
>
> I decided to try the approach you proposed to see whether it makes the
> assembly-code problem go away.  Again, I tried a very simple register
> allocator (attached) that just calls vrm.assignVirt2Phys for every vreg in
> each function, mapping the vreg to the first preg in the register class.  I
> tried two versions: one maps *every* vreg, and the other only maps those
> for which MRI->reg_empty(vreg) returns false.  In both cases I get a
core
> dump somewhere after my reg-allocation pass has run (when I use the
"tst.c"
> file that I sent last time as input).
>
> Note also that there is no VirtRegMap.h in the "include"
directory of my
> installed llvm-3.1.  I had to copy that file from the source directory.
>  That seems suspicious.
>
> Any thoughts?
>
> Thanks!
>
> Susan
>
>
> On 10/31/2012 07:51 PM, Lang Hames wrote:
>
>> 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
>> <mailto: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>
>>         <mailto: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>
>>         <mailto: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<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>> >
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121101/a3d14a44/attachment.html>

I still get a coredump:

0  libLLVM-3.1.so  0x00007f0158a4e67f
1  libLLVM-3.1.so  0x00007f0158a500ca
2  libpthread.so.0 0x0000003a86c0f500
3  libLLVM-3.1.so  0x00007f01583c346c
4  libLLVM-3.1.so  0x00007f0158546349 
llvm::FPPassManager::runOnFunction(llvm::Function&) + 521
5  libLLVM-3.1.so  0x00007f01585463e3 
llvm::FPPassManager::runOnModule(llvm::Module&) + 51
6  libLLVM-3.1.so  0x00007f0158545fae 
llvm::MPPassManager::runOnModule(llvm::Module&) + 462
7  libLLVM-3.1.so  0x00007f01585460bd 
llvm::PassManagerImpl::run(llvm::Module&) + 125
8  llc             0x000000000040b012 main + 5218
9  libc.so.6       0x0000003a8601ecdd __libc_start_main + 253
10 llc             0x0000000000407d79
Stack dump:
0.      Program arguments: llc -load Debug/lib/P4.so -regalloc=gc tst.bc
1.      Running pass 'Function Pass Manager' on module 'tst.bc'.
2.      Running pass 'Machine Loop Invariant Code Motion' on function 
'@main'
make: *** [tst.reg] Segmentation fault (core dumped)


On 11/01/2012 04:59 PM, Lang Hames wrote:
> Hi Susan,
>
> Sorry - I had missed that you're using llvm-3.1, rather than the
> development branch. We encourage people to live on top-of-tree - it's
> well tested, easier for active developers to offer help with, and
> keeping up with incremental changes is often easier than porting between
> stable versions.
>
> It also sounds like you were building a Release version of LLVM. That
> will not have any asserts enabled (though it will have some other
> diagnostics). You will probably want to work with a Debug+Asserts
> version (<src>/configure --disable-optimized --enable-assertions)
while
> you're developing your allocator and watch for any asserts that
trigger.
>
> In your case the Assertion that is triggering in PEI indicates that the
> MachineRegisterInfo object still contained some virtregs post
> register-allocation. You need to call MRI->clearVirtRegs() at the end of
> your allocator.
>
> Hope this helps!
>
> Cheers,
> Lang.
>
> On Thu, Nov 1, 2012 at 2:41 PM, Susan Horwitz <horwitz at cs.wisc.edu
> <mailto:horwitz at cs.wisc.edu>> wrote:
>
>     Hi again Lang,
>
>     I decided to try the approach you proposed to see whether it makes
>     the assembly-code problem go away.  Again, I tried a very simple
>     register allocator (attached) that just calls vrm.assignVirt2Phys
>     for every vreg in each function, mapping the vreg to the first preg
>     in the register class.  I tried two versions: one maps *every* vreg,
>     and the other only maps those for which MRI->reg_empty(vreg) returns
>     false.  In both cases I get a core dump somewhere after my
>     reg-allocation pass has run (when I use the "tst.c" file that
I sent
>     last time as input).
>
>     Note also that there is no VirtRegMap.h in the "include"
directory
>     of my installed llvm-3.1.  I had to copy that file from the source
>     directory.  That seems suspicious.
>
>     Any thoughts?
>
>     Thanks!
>
>     Susan
>
>
>     On 10/31/2012 07:51 PM, Lang Hames wrote:
>
>         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 <mailto:horwitz at cs.wisc.edu>
>         <mailto:horwitz at cs.wisc.edu <mailto: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>
>         <mailto:horwitz at cs.wisc.edu <mailto:horwitz at
cs.wisc.edu>>
>         <mailto:horwitz at cs.wisc.edu <mailto:horwitz at
cs.wisc.edu>
>         <mailto: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>
>         <mailto:LLVMdev at cs.uiuc.edu <mailto:LLVMdev at
cs.uiuc.edu>>
>         <mailto:LLVMdev at cs.uiuc.edu <mailto:LLVMdev at
cs.uiuc.edu>
>         <mailto: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
>         <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>>
>
>
>
>
>
>