Hi Susan,<div><br></div><div>Sorry for the delayed response. Thanks for the test cases - I'm looking in to this now.</div><div><br></div><div>- Lang.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 5, 2012 at 2:58 PM, Susan Horwitz <span dir="ltr"><<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Lang,<br>
<br>
I looked more into one of the problems I'm now having, and I've attached 3 files:<br>
<br>
Gcra.cpp is like your version except that for two specific vregs it uses hard-coded pregs instead of the first in the corresponding class.<br>
<br>
bug1.c is an input that causes the failed assertion for me. If I use the non-debug version of LLVM-3.1 I instead get assembler errors like this:<br>
Error: can't encode register '%ah' in an instruction requiring REX prefix.<br>
<br>
bug1.bc is my bitcode version of bug1.c.<br>
<br>
The problematic vregs are both in register class 0. One is replaced with preg 1 and the other with preg 74. Those are both in register class 0, and are not aliased. Any idea why using those pregs causes trouble?<br>
<br>
Thanks!<br>
<br>
Susan<div class="im"><br>
<br>
On 11/04/2012 06:19 PM, Lang Hames wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Susan,<br>
<br><div class="im">
With your bitcode file I am now able to reproduce the issue you're<br>
seeing. It looks like this is a problem with the naive rewriting from<br>
virtregs to physregs. It appears that the subreg field of physreg<br>
operands is ignored post-register allocation. In your testcase<br>
%vreg11:sub32 is being rewritten to RBX:sub32, but the :sub32 part is<br>
being quietly dropped when the assembly is written out. If this is<br>
expected behaviour, and is still happening in the development branch,<br>
then I'll add some sort of verification to catch it.<br>
<br>
The VirtRegMap::rewrite() method sidesteps this issue by rewriting<br>
physreg operands to remove the subreg field. The code for this is in<br>
VirtRegMap.cpp, around line 165. In short:<br>
<br>
PhysReg = MO.getReg();<br>
if (MO.getSubReg() != 0) {<br>
PhysReg = TRI->getSubReg(PhysReg, MO.getSubReg());<br>
MO.setSubReg(0);<br>
}<br>
MO.setReg(PhysReg);<br>
<br>
Adding this code to Gcra fixes the assembly issue for me. I've attached<br>
my updated copy. Hope this helps.<br>
<br>
Cheers,<br>
Lang.<br>
<br>
<br>
On Sun, Nov 4, 2012 at 2:08 PM, Susan Horwitz <<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a><br></div><div><div class="h5">
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>>> wrote:<br>
<br>
My tst.bc is attached. I had to use ssh to copy it from my office<br>
machine to my home laptop. In case that corrupts it, I also put a<br>
copy here:<br>
<a href="http://pages.cs.wisc.edu/~horwitz/LANG/tst.bc" target="_blank">http://pages.cs.wisc.edu/~<u></u>horwitz/LANG/tst.bc</a><br>
<br>
I created the file like this:<br>
<br>
clang -emit-llvm -O0 -c tst.c -o tst.bc<br>
opt -mem2reg tst.bc > tst.mem2reg<br>
mv tst.mem2reg tst.bc<br>
<br>
<br>
Susan<br>
<br>
<br>
On 11/4/2012 3:27 PM, Lang Hames wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Hi Susan,<br>
<br>
I tested the version of Gcra.cpp that I sent you on x86-64 systems<br>
running MacOS 10.8 and Ubuntu 12.04 (Linux 3.2.0).<br>
<br>
Could you send me the bitcode file you're compiling? Different<br>
bitcodes (due to different clang versions or applied<br>
optimizations) could account for the different results we're<br>
seeing. For reference I've attached the *.ll file that I have<br>
tested with, which was compiled from your tst.c file with:<br>
<br>
clang -O0 -emit-llvm -S -o tst.ll tst.c<br>
<br>
My clang version was built from a recent checkout from subversion.<br>
<br>
It's unlikely that there is any fundamental problem with the<br>
register allocation APIs or the code generator that would prevent<br>
you from building a working allocator. The APIs certainly could<br>
have changed in a way that would break existing allocators though.<br>
<br>
- Lang.<br>
<br>
<br>
On Sat, Nov 3, 2012 at 4:34 PM, Susan Horwitz <<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a><br></div></div><div><div class="h5">
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>>> wrote:<br>
<br>
Lang -<br>
<br>
Your version does NOT work for me (i.e., I still get an error<br>
from the assembler when I run your code on my tst.c) unless I<br>
force compilation and assembly for a 32-bit X86 machine:<br>
<br>
llc -march=x86 -regalloc=gc tst.bc<br>
gcc -m32 tst.s<br>
<br>
My machine is a 64-bit machine. Maybe you are working with a<br>
different architecture and that's why it worked for you?<br>
<br>
I would be happy if the above worked in general, but when I<br>
try other C code (with my "real" register allocator, not the<br>
naive one I sent you) I get assembly that includes<br>
<br>
%r8d<br>
<br>
which seems to be invalid for a 32-bit machine. Sigh. It<br>
looks to me like there's a problem with the LLVM-3.1 API for<br>
register allocation and/or the code-generation phase. What do<br>
you think?<br>
<br>
Susan<br>
<br>
<br>
On 11/1/2012 5:28 PM, Lang Hames wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Hi Susan,<br>
<br>
Without debugging symbols I can't make much out of that stack<br>
trace I'm afraid.<br>
<br>
I've attached my modified version of Gcra.cpp. I built llvm<br>
3.1 by dropping this file into lib/CodeGen, and adding<br>
references to createGcra to include/lib/CodeGen/Passes.h and<br>
include/lib/CodeGen/<u></u>LinkAllCodeGenComponents.h. (If you<br>
search for createRegAllocPBQP you'll see where to add the<br>
declarations).<br>
<br>
With that setup, running your allocator on the tst.c file you<br>
attached previously yielded a sane assembly file.<br>
<br>
Cheers,<br>
Lang.<br>
<br>
On Thu, Nov 1, 2012 at 3:13 PM, Susan Horwitz<br></div></div><div class="im">
<<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a> <mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>>> wrote:<br>
<br>
I still get a coredump:<br>
<br></div><div class="im">
0 <a href="http://libLLVM-3.1.so" target="_blank">libLLVM-3.1.so</a> <<a href="http://libLLVM-3.1.so" target="_blank">http://libLLVM-3.1.so</a>> 0x00007f0158a4e67f<br></div>
1 <a href="http://libLLVM-3.1.so" target="_blank">libLLVM-3.1.so</a> <<a href="http://libLLVM-3.1.so" target="_blank">http://libLLVM-3.1.so</a>> 0x00007f0158a500ca<br>
2 libpthread.so.0 0x0000003a86c0f500<div class="im"><br>
3 <a href="http://libLLVM-3.1.so" target="_blank">libLLVM-3.1.so</a> <<a href="http://libLLVM-3.1.so" target="_blank">http://libLLVM-3.1.so</a>> 0x00007f01583c346c<br>
4 <a href="http://libLLVM-3.1.so" target="_blank">libLLVM-3.1.so</a> <<a href="http://libLLVM-3.1.so" target="_blank">http://libLLVM-3.1.so</a>><br></div><div class="im">
0x00007f0158546349<br>
llvm::FPPassManager::<u></u>runOnFunction(llvm::Function&) + 521<br></div>
5 <a href="http://libLLVM-3.1.so" target="_blank">libLLVM-3.1.so</a> <<a href="http://libLLVM-3.1.so" target="_blank">http://libLLVM-3.1.so</a>><div class="im"><br>
0x00007f01585463e3<br>
llvm::FPPassManager::<u></u>runOnModule(llvm::Module&) + 51<br></div>
6 <a href="http://libLLVM-3.1.so" target="_blank">libLLVM-3.1.so</a> <<a href="http://libLLVM-3.1.so" target="_blank">http://libLLVM-3.1.so</a>><div class="im"><br>
0x00007f0158545fae<br>
llvm::MPPassManager::<u></u>runOnModule(llvm::Module&) + 462<br></div>
7 <a href="http://libLLVM-3.1.so" target="_blank">libLLVM-3.1.so</a> <<a href="http://libLLVM-3.1.so" target="_blank">http://libLLVM-3.1.so</a>><div><div class="h5"><br>
0x00007f01585460bd<br>
llvm::PassManagerImpl::run(<u></u>llvm::Module&) + 125<br>
8 llc 0x000000000040b012 main + 5218<br>
9 libc.so.6 0x0000003a8601ecdd __libc_start_main + 253<br>
10 llc 0x0000000000407d79<br>
Stack dump:<br>
0. Program arguments: llc -load Debug/lib/P4.so<br>
-regalloc=gc tst.bc<br>
1. Running pass 'Function Pass Manager' on module<br>
'tst.bc'.<br>
2. Running pass 'Machine Loop Invariant Code Motion'<br>
on function '@main'<br>
make: *** [tst.reg] Segmentation fault (core dumped)<br>
<br>
<br>
<br>
On 11/01/2012 04:59 PM, Lang Hames wrote:<br>
<br>
Hi Susan,<br>
<br>
Sorry - I had missed that you're using llvm-3.1,<br>
rather than the<br>
development branch. We encourage people to live on<br>
top-of-tree - it's<br>
well tested, easier for active developers to offer<br>
help with, and<br>
keeping up with incremental changes is often easier<br>
than porting between<br>
stable versions.<br>
<br>
It also sounds like you were building a Release<br>
version of LLVM. That<br>
will not have any asserts enabled (though it will<br>
have some other<br>
diagnostics). You will probably want to work with a<br>
Debug+Asserts<br>
version (<src>/configure --disable-optimized<br>
--enable-assertions) while<br>
you're developing your allocator and watch for any<br>
asserts that trigger.<br>
<br>
In your case the Assertion that is triggering in PEI<br>
indicates that the<br>
MachineRegisterInfo object still contained some<br>
virtregs post<br>
register-allocation. You need to call<br>
MRI->clearVirtRegs() at the end of<br>
your allocator.<br>
<br>
Hope this helps!<br>
<br>
Cheers,<br>
Lang.<br>
<br>
On Thu, Nov 1, 2012 at 2:41 PM, Susan Horwitz<br>
<<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a> <mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>><br></div></div><div><div class="h5">
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a><br>
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>>>> wrote:<br>
<br>
Hi again Lang,<br>
<br>
I decided to try the approach you proposed to see<br>
whether it makes<br>
the assembly-code problem go away. Again, I<br>
tried a very simple<br>
register allocator (attached) that just calls<br>
vrm.assignVirt2Phys<br>
for every vreg in each function, mapping the vreg<br>
to the first preg<br>
in the register class. I tried two versions: one<br>
maps *every* vreg,<br>
and the other only maps those for which<br>
MRI->reg_empty(vreg) returns<br>
false. In both cases I get a core dump somewhere<br>
after my<br>
reg-allocation pass has run (when I use the<br>
"tst.c" file that I sent<br>
last time as input).<br>
<br>
Note also that there is no VirtRegMap.h in the<br>
"include" directory<br>
of my installed llvm-3.1. I had to copy that<br>
file from the source<br>
directory. That seems suspicious.<br>
<br>
Any thoughts?<br>
<br>
Thanks!<br>
<br>
Susan<br>
<br>
<br>
On 10/31/2012 07:51 PM, Lang Hames wrote:<br>
<br>
Hi Susan,<br>
<br>
I'm having trouble reproducing that error on<br>
my end, but I think the<br>
problem is probably that you're not using the<br>
VirtRegRewriter<br>
infrastructure. What your allocator needs to<br>
do is populate the<br>
virtual<br>
register mapping (VirtRegMap pass) with your<br>
allocation, rather than<br>
rewriting the registers directly through<br>
MachineRegisterInfo.<br>
<br>
Have your allocator require and preserve the<br>
VirtRegMap pass,<br>
then in<br>
your runOnMachineFunction pass grab a<br>
reference to the pass with:<br>
<br>
VirtRegMap &vrm = getAnalysis<VirtRegMap>();<br>
<br>
You can then describe your register<br>
allocations with:<br>
<br>
vrm.assignVirt2Phys(<virtreg>, <physreg>)<br>
<br>
The VirtRegRewriter pass (in VirtRegMap.cpp)<br>
will run after your<br>
allocator and apply the mapping that you<br>
described in the<br>
VirtRegMap.<br>
<br>
I hope this helps. Let me know if it doesn't<br>
fix your issue.<br>
<br>
Cheers,<br>
Lang.<br>
<br>
On Wed, Oct 31, 2012 at 3:54 PM, Susan Horwitz<br>
<<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a> <mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>><br>
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a> <mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>>><br></div></div><div>
<div class="h5">
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a><br>
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>><br>
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a><br>
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>>>><u></u>> wrote:<br>
<br>
Thanks Lang!<br>
<br>
Here's another question: I'm trying to<br>
process this input:<br>
<br>
int main() {<br>
return 0;<br>
}<br>
<br>
but I'm getting an error<br>
Assertion `!Fn.getRegInfo().<br>
getNumVirtRegs() &&<br>
"Regalloc must<br>
<br>
assign all vregs"' failed.<br>
<br>
At the start of runOnMachineFunction I<br>
call Fn.getRegInfo().<br>
getNumVirtRegs();<br>
and find that there is 1 virtual<br>
register. However,<br>
MRI->reg_empty(vreg)<br>
tells me that it is not used or defined.<br>
So my<br>
register-allocation<br>
code never sees it, and thus can't<br>
allocate a preg for it.<br>
I tried<br>
using MRI->replaceRegWith(vreg, preg);<br>
(where preg is available to vreg's<br>
register class) but that<br>
didn't<br>
work. When I look, the number of vregs<br>
in the function is<br>
still 1.<br>
<br>
Can you help with this?<br>
<br>
Thanks again!<br>
<br>
Susan<br>
<br>
<br>
On 10/31/2012 04:55 PM, Lang Hames wrote:<br>
<br>
Hi Susan,<br>
<br>
The meaning of "addRequired(X)" is<br>
that your pass needs<br>
X to be<br>
run, and<br>
for X to be preserved by all passes<br>
that run after X<br>
and before your<br>
pass. The PHIElemination and<br>
TwoAddressInstruction<br>
passes do not<br>
preserve each other, hence there's<br>
no way for the pass<br>
manager to<br>
schedule them for you if you<br>
addRequire(...) them.<br>
<br>
The trick is that CodeGen will<br>
schedule both of these<br>
passes to<br>
be run<br>
before _any_ register allocation<br>
pass (see Passes.cpp),<br>
so you<br>
needn't<br>
require them explicitly - you can<br>
just assume they have<br>
been<br>
run. If you<br>
just remove those lines from your<br>
getAnalysisUsage<br>
method your pass<br>
should now run as you expect.<br>
<br>
Cheers,<br>
Lang.<br>
<br>
On Wed, Oct 31, 2012 at 1:46 PM,<br>
Susan Horwitz<br>
<<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a> <mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>><br>
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a> <mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>>><br>
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a><br>
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>><br>
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a><br>
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>>>><br>
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a><br>
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>><br>
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a> <mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>>><br>
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a><br>
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>><br>
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a><br>
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>>>><u></u>>> wrote:<br>
<br>
I'm trying to write a<br>
MachineFunctionPass to do<br>
register<br>
allocation.<br>
I have code that worked with<br>
an old version of<br>
LLVM. It<br>
does not<br>
work with llvm-3.1. (or various<br>
other versions<br>
that I've<br>
tried).<br>
<br>
The first problem is that<br>
including this line:<br>
<br>
AU.addRequiredID(__<br>
TwoAddressInstructionPassID);<br>
<br>
<br>
in method getAnalysisUsage<br>
causes a runtime error:<br>
<br>
Unable to schedule 'Eliminate<br>
PHI nodes for register<br>
allocation'<br>
required by 'Unnamed pass:<br>
implement<br>
Pass::getPassName()'<br>
Unable to schedule pass<br>
UNREACHABLE executed at ...<br>
<br>
I'm invoking the pass like this<br>
(given input file<br>
foo.c):<br>
<br>
clang -emit-llvm -O0 -c foo.c<br>
-o foo.bc<br>
opt -mem2reg foo.bc > foo.ssa<br>
mv foo.ssa foo.bc<br>
llc -load Debug/lib/P4.so<br>
-regalloc=gc foo.bc<br>
<br>
<br>
I've attached my entire file<br>
(it's very short).<br>
Any help<br>
would be<br>
much appreciated!<br>
<br>
Susan Horwitz<br>
<br>
______________________________<br>
_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>><br>
<mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>>><br>
<mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a><br>
<mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>><br>
<mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a><br>
<mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>>>><br>
<mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a><br>
<mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>><br>
<mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>>><br>
<mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a><br>
<mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>><br>
<mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a><br>
<mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>>>><u></u>><br>
<br>
<a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/" target="_blank">http://lists.cs.uiuc.edu/</a> mailman/listinfo/llvmdev<br>
<<a href="http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/__<u></u>mailman/listinfo/llvmdev</a><br>
<<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a>>><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</div></div></blockquote>
<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</blockquote></div><br></div>