<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Lang -<br>
<br>
Your version does NOT work for me (i.e., I still get an error from
the assembler when I run your code on my tst.c) unless I force
compilation and assembly for a 32-bit X86 machine:<br>
<pre wrap=""> llc -march=x86 -regalloc=gc tst.bc
gcc -m32 tst.s
</pre>
My machine is a 64-bit machine. Maybe you are working with a
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 try
other C code (with my "real" register allocator, not the 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 looks
to me like there's a problem with the LLVM-3.1 API for register
allocation and/or the code-generation phase. What do you think?<br>
<br>
Susan<br>
<br>
On 11/1/2012 5:28 PM, Lang Hames wrote:<br>
</div>
<blockquote
cite="mid:CALLttgoMyuC=U4CE5sLZCzRcDdT+Ros4gz0NWJN_0SfL2Ugf=g@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
Hi Susan,
<div><br>
</div>
<div>Without debugging symbols I can't make much out of that stack
trace I'm afraid.</div>
<div><br>
</div>
<div>I've attached my modified version of Gcra.cpp. I built llvm
3.1 by dropping this file into lib/CodeGen, and adding
references to createGcra to include/lib/CodeGen/Passes.h and
include/lib/CodeGen/LinkAllCodeGenComponents.h. (If you search
for createRegAllocPBQP you'll see where to add the
declarations).</div>
<div><br>
</div>
<div>With that setup, running your allocator on the tst.c file you
attached previously yielded a sane assembly file.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Lang.</div>
<div><br>
<div class="gmail_quote">On Thu, Nov 1, 2012 at 3:13 PM, Susan
Horwitz <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote">I still get a coredump:<br>
<br>
0 <a moz-do-not-send="true" href="http://libLLVM-3.1.so"
target="_blank">libLLVM-3.1.so</a> 0x00007f0158a4e67f<br>
1 <a moz-do-not-send="true" href="http://libLLVM-3.1.so"
target="_blank">libLLVM-3.1.so</a> 0x00007f0158a500ca<br>
2 libpthread.so.0 0x0000003a86c0f500<br>
3 <a moz-do-not-send="true" href="http://libLLVM-3.1.so"
target="_blank">libLLVM-3.1.so</a> 0x00007f01583c346c<br>
4 <a moz-do-not-send="true" href="http://libLLVM-3.1.so"
target="_blank">libLLVM-3.1.so</a> 0x00007f0158546349
llvm::FPPassManager::runOnFunction(llvm::Function&) +
521<br>
5 <a moz-do-not-send="true" href="http://libLLVM-3.1.so"
target="_blank">libLLVM-3.1.so</a> 0x00007f01585463e3
llvm::FPPassManager::runOnModule(llvm::Module&) + 51<br>
6 <a moz-do-not-send="true" href="http://libLLVM-3.1.so"
target="_blank">libLLVM-3.1.so</a> 0x00007f0158545fae
llvm::MPPassManager::runOnModule(llvm::Module&) + 462<br>
7 <a moz-do-not-send="true" href="http://libLLVM-3.1.so"
target="_blank">libLLVM-3.1.so</a> 0x00007f01585460bd
llvm::PassManagerImpl::run(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
-regalloc=gc tst.bc<br>
1. Running pass 'Function Pass Manager' on module
'tst.bc'.<br>
2. Running pass 'Machine Loop Invariant Code Motion' on
function '@main'<br>
make: *** [tst.reg] Segmentation fault (core dumped)
<div class="im"><br>
<br>
<br>
On 11/01/2012 04:59 PM, Lang Hames wrote:<br>
</div>
<blockquote class="gmail_quote">
Hi Susan,<br>
<br>
<div class="im">
Sorry - I had missed that you're using llvm-3.1, rather
than the<br>
development branch. We encourage people to live on
top-of-tree - it's<br>
well tested, easier for active developers to offer help
with, and<br>
keeping up with incremental changes is often easier than
porting between<br>
stable versions.<br>
<br>
It also sounds like you were building a Release version
of LLVM. That<br>
will not have any asserts enabled (though it will have
some other<br>
diagnostics). You will probably want to work with a
Debug+Asserts<br>
version (<src>/configure --disable-optimized
--enable-assertions) while<br>
you're developing your allocator and watch for any
asserts that trigger.<br>
<br>
In your case the Assertion that is triggering in PEI
indicates that the<br>
MachineRegisterInfo object still contained some virtregs
post<br>
register-allocation. You need to call
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 <<a
moz-do-not-send="true"
href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a><br>
</div>
<div>
<div class="h5">
<mailto:<a moz-do-not-send="true"
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
whether it makes<br>
the assembly-code problem go away. Again, I tried
a very simple<br>
register allocator (attached) that just calls
vrm.assignVirt2Phys<br>
for every vreg in each function, mapping the vreg
to the first preg<br>
in the register class. I tried two versions: one
maps *every* vreg,<br>
and the other only maps those for which
MRI->reg_empty(vreg) returns<br>
false. In both cases I get a core dump somewhere
after my<br>
reg-allocation pass has run (when I use the
"tst.c" file that I sent<br>
last time as input).<br>
<br>
Note also that there is no VirtRegMap.h in the
"include" directory<br>
of my installed llvm-3.1. I had to copy that 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
my end, but I think the<br>
problem is probably that you're not using the
VirtRegRewriter<br>
infrastructure. What your allocator needs to
do is populate the<br>
virtual<br>
register mapping (VirtRegMap pass) with your
allocation, rather than<br>
rewriting the registers directly through
MachineRegisterInfo.<br>
<br>
Have your allocator require and preserve the
VirtRegMap pass,<br>
then in<br>
your runOnMachineFunction pass grab a
reference to the pass with:<br>
<br>
VirtRegMap &vrm =
getAnalysis<VirtRegMap>();<br>
<br>
You can then describe your register
allocations with:<br>
<br>
vrm.assignVirt2Phys(<virtreg>,
<physreg>)<br>
<br>
The VirtRegRewriter pass (in VirtRegMap.cpp)
will run after your<br>
allocator and apply the mapping that you
described in the<br>
VirtRegMap.<br>
<br>
I hope this helps. Let me know if it doesn't
fix your issue.<br>
<br>
Cheers,<br>
Lang.<br>
<br>
On Wed, Oct 31, 2012 at 3:54 PM, Susan Horwitz<br>
<<a moz-do-not-send="true"
href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>
<mailto:<a moz-do-not-send="true"
href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>><br>
</div>
</div>
<div>
<div class="h5">
<mailto:<a moz-do-not-send="true"
href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>
<mailto:<a moz-do-not-send="true"
href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>>>>
wrote:<br>
<br>
Thanks Lang!<br>
<br>
Here's another question: I'm trying to
process this input:<br>
<br>
int main() {<br>
return 0;<br>
}<br>
<br>
but I'm getting an error<br>
Assertion `!Fn.getRegInfo().
getNumVirtRegs() &&<br>
"Regalloc must<br>
<br>
assign all vregs"' failed.<br>
<br>
At the start of runOnMachineFunction I
call Fn.getRegInfo().<br>
getNumVirtRegs();<br>
and find that there is 1 virtual
register. However,<br>
MRI->reg_empty(vreg)<br>
tells me that it is not used or defined.
So my<br>
register-allocation<br>
code never sees it, and thus can't
allocate a preg for it.<br>
I tried<br>
using MRI->replaceRegWith(vreg, preg);<br>
(where preg is available to vreg's
register class) but that<br>
didn't<br>
work. When I look, the number of vregs
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
that your pass needs<br>
X to be<br>
run, and<br>
for X to be preserved by all passes
that run after X<br>
and before your<br>
pass. The PHIElemination and
TwoAddressInstruction<br>
passes do not<br>
preserve each other, hence there's no
way for the pass<br>
manager to<br>
schedule them for you if you
addRequire(...) them.<br>
<br>
The trick is that CodeGen will
schedule both of these<br>
passes to<br>
be run<br>
before _any_ register allocation pass
(see Passes.cpp),<br>
so you<br>
needn't<br>
require them explicitly - you can
just assume they have<br>
been<br>
run. If you<br>
just remove those lines from your
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,
Susan Horwitz<br>
<<a moz-do-not-send="true"
href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>
<mailto:<a moz-do-not-send="true"
href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>><br>
<mailto:<a moz-do-not-send="true"
href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>
<mailto:<a moz-do-not-send="true"
href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>>><br>
<mailto:<a moz-do-not-send="true"
href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>
<mailto:<a moz-do-not-send="true"
href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>><br>
<mailto:<a moz-do-not-send="true"
href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>
<mailto:<a moz-do-not-send="true"
href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>>>>>
wrote:<br>
<br>
I'm trying to write a
MachineFunctionPass to do<br>
register<br>
allocation.<br>
I have code that worked with
an old version of<br>
LLVM. It<br>
does not<br>
work with llvm-3.1. (or various
other versions<br>
that I've<br>
tried).<br>
<br>
The first problem is that
including this line:<br>
<br>
AU.addRequiredID(__
TwoAddressInstructionPassID);<br>
<br>
<br>
in method getAnalysisUsage
causes a runtime error:<br>
<br>
Unable to schedule 'Eliminate
PHI nodes for register<br>
allocation'<br>
required by 'Unnamed pass:
implement<br>
Pass::getPassName()'<br>
Unable to schedule pass<br>
UNREACHABLE executed at ...<br>
<br>
I'm invoking the pass like this
(given input file<br>
foo.c):<br>
<br>
clang -emit-llvm -O0 -c foo.c -o
foo.bc<br>
opt -mem2reg foo.bc > foo.ssa<br>
mv foo.ssa foo.bc<br>
llc -load Debug/lib/P4.so
-regalloc=gc foo.bc<br>
<br>
<br>
I've attached my entire file
(it's very short).<br>
Any help<br>
would be<br>
much appreciated!<br>
<br>
Susan Horwitz<br>
<br>
______________________________
_________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>
<mailto:<a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>><br>
<mailto:<a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>
<mailto:<a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>>><br>
<mailto:<a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>
<mailto:<a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>><br>
<mailto:<a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>
<mailto:<a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>>>><br>
<br>
<a moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/" target="_blank">http://lists.cs.uiuc.edu/</a>
mailman/listinfo/llvmdev<br>
</div>
</div>
<<a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev"
target="_blank">http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev</a><br>
<<a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>>><br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>