<div>Hi Susan,<div><br></div><div>The problem now is the usedPregSet. Take the instruction:</div><div><br></div><div>%vreg13:sub_32bit<def> = ADD32rr %vreg13:sub_32bit, %EAX<kill>, %EFLAGS<imp-def,dead><br>
</div><div><br></div></div><div>%EAX will be added to usedPregSet when the instruction is encountered, but %vreg13 is a different class (64bit registers), so none of its candidates will conflict. In addition to checking membership of usedPregSet, you need to check all aliases of the elements of usedPregSet.</div>
<div><br></div><div>The attached Gcra includes code for this. It also moves the erasure of the subreg index out of the inner loop so that if a vreg appears multiple times in an instruction all subreg indexes will be cleared.</div>
<div><br></div><div>- Lang.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 13, 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">Lang -<br>
<br>
Your fix does prevent the assembler errors, but it doesn't seem to produce correct assembly.<br>
<br>
I created a slightly modified version that, for each instruction that includes a vreg, adds a check that the preg selected is not already in that instruction. I've attached that version.<br>
<br>
I think that this version of Gcra.cpp should produce correct assembler, since it's allocating one stackframe for each vreg and always loading/storing from/to that stackframe.<br>
<br>
I've attached a simpler version of the test input (now called bug.c) plus the .bc file and the .s file produced by the new code. When I assemble and run I get this output:<br>
<br>
x: 1001<br>
x: 200<br>
x: 40<br>
x: 8<br>
<br>
while the correct output is<br>
<br>
x: 1001<br>
x: 100<br>
x: 10<br>
<br>
Susan<div class="im"><br>
<br>
On 11/13/2012 01:20 AM, 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">
The problem is that the allocator is re-using the 'preg', which is<br>
calculated for an operand that may have a subreg index, for loads and<br>
stores to a stack-slot. The stack slot always has the same width as vreg<br>
(which is the right behavior), but for operands with subreg indexes,<br>
'preg''s class will be different from 'vreg', in which case you get the<br>
mismatched loads/stores you were seeing.<br>
<br>
I've attached an updated copy of Gcra.cpp that doesn't exhibit this bug.<br>
In the new version the loads and stores always reference 'preg', which<br>
is always a physical register of the same class as 'vreg'. The update<br>
adds a new variable, preg_op, to hold the subregister of preg that will<br>
be used for the operand currently being rewritten, and preg_op will be<br>
set to a subreg of preg where appropriate.<br>
<br>
- Lang.<br>
<br>
<br>
On Sun, Nov 11, 2012 at 10:30 AM, Susan Horwitz <<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a><br></div><div class="im">
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>>> wrote:<br>
<br>
Sorry about that. I created the assembly file and attached it (as<br>
math.txt).<br>
<br>
Susan<br>
<br>
On 11/11/2012 12:41 AM, Lang Hames wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Hi Susan,<br>
<br>
It looks like the bitcode you have attached is corrupted. You<br>
should make sure to attach it as a binary file. Alternatively you<br>
can attach the LLVM assembly as text. You can generate an assembly<br>
file from bitcode with:<br>
<br>
llvm-dis -o <asm file> <bitcode><br>
<br>
Regards,<br>
Lang.<br>
<br>
<br>
On Fri, Nov 9, 2012 at 11:15 AM, Susan Horwitz<br></div><div><div class="h5">
<<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>
Thanks Lang, we are making progress! I no longer get the<br>
failed assertion, but the code I'm using for vregs that don't<br>
get allocated a preg, and thus need to be spilled and<br>
re-loaded is causing assembler errors.<br>
<br>
I suspect the problem is my code for allocating space in the<br>
stack, but I don't know how to fix it.<br>
<br>
I've attached a new version of the simple register-allocation<br>
code, a test program that causes the bad assembler to be<br>
produced, and the bc file. (I had to name everything with a<br>
.txt extension to copy the files to my laptop.)<br>
<br>
As always, thank you for your help!<br>
<br>
Susan<br>
<br>
<br>
On 11/7/2012 7:31 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>
In x86-64 the REX prefix must be used to access an extended<br>
register (r8-r15 and their aliases), but cannot be used when<br>
accessing the high byte of the ABCD regs (AH, BH, CH, DH). In<br>
your test case you have hardcoded %vreg1 to R8B, and %vreg15<br>
to AH, and the test case contains a copy between these<br>
registers. The copy simultaneously must have a REX prefix,<br>
and cannot have a REX prefix, hence the assertion.<br>
<br>
The problem is that not all registers in a class are<br>
allocable for all vregs. As you can see from the above<br>
constraint, which pregs are valid varies dynamically<br>
depending on the context that the register is used. The trick<br>
is to query the "allocation order" for a class (and as an<br>
added headache filter out any reserved registers). I've<br>
attached a test-case where I do this somewhat manually. In short:<br>
<br>
int regClass = MRI->getRegClass(vreg)->getID(<u></u>);<br>
const TargetRegisterClass *trc = TRI->getRegClass(regClass);<br>
ArrayRef<uint16_t> rawOrder = trc->getRawAllocationOrder(Fn)<u></u>;<br>
ArrayRef<uint16_t>::iterator rItr = rawOrder.begin();<br>
while (reservedRegs.test(*rItr))<br>
++rItr;<br>
preg = *rItr;<br>
<br>
Alternatively, you could use the AllocationOrder class<br>
(lib/CodeGen/AllocationOrder.<u></u>h). This has the benefit of<br>
considering register hints for improved coalescing too. It<br>
does, however, require you to use VirtRegMap.<br>
<br>
Hope this helps!<br>
<br>
Cheers,<br>
Lang.<br>
<br>
<br>
<br>
On Wed, Nov 7, 2012 at 2:56 PM, Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a><br></div></div><div class="im">
<mailto:<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>>> wrote:<br>
<br>
Hi Susan,<br>
<br>
Sorry for the delayed response. Thanks for the test cases<br>
- I'm looking in to this now.<br>
<br>
- Lang.<br>
<br>
<br>
On Mon, Nov 5, 2012 at 2:58 PM, Susan Horwitz<br></div><div><div class="h5">
<<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>
Hi Lang,<br>
<br>
I looked more into one of the problems I'm now<br>
having, and I've attached 3 files:<br>
<br>
Gcra.cpp is like your version except that for two<br>
specific vregs it uses hard-coded pregs instead of<br>
the first in the corresponding class.<br>
<br>
bug1.c is an input that causes the failed assertion<br>
for me. If I use the non-debug version of LLVM-3.1 I<br>
instead get assembler errors like this:<br>
Error: can't encode register '%ah' in an<br>
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.<br>
One is replaced with preg 1 and the other with preg<br>
74. Those are both in register class 0, and are not<br>
aliased. Any idea why using those pregs causes trouble?<br>
<br>
Thanks!<br>
<br>
Susan<br>
<br>
<br>
On 11/04/2012 06:19 PM, Lang Hames wrote:<br>
<br>
Hi Susan,<br>
<br>
With your bitcode file I am now able to reproduce<br>
the issue you're<br>
seeing. It looks like this is a problem with the<br>
naive rewriting from<br>
virtregs to physregs. It appears that the subreg<br>
field of physreg<br>
operands is ignored post-register allocation. In<br>
your testcase<br>
%vreg11:sub32 is being rewritten to RBX:sub32,<br>
but the :sub32 part is<br>
being quietly dropped when the assembly is<br>
written out. If this is<br>
expected behaviour, and is still happening in the<br>
development branch,<br>
then I'll add some sort of verification to catch it.<br>
<br>
The VirtRegMap::rewrite() method sidesteps this<br>
issue by rewriting<br>
physreg operands to remove the subreg field. The<br>
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<br>
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<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 class="im">
<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></div><div class="im">
My tst.bc is attached. I had to use ssh to<br>
copy it from my office<br>
machine to my home laptop. In case that<br>
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></div>
<<a href="http://pages.cs.wisc.edu/%7Ehorwitz/LANG/tst.bc" target="_blank">http://pages.cs.wisc.edu/%<u></u>7Ehorwitz/LANG/tst.bc</a>><div><div class="h5"><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>
<br>
Hi Susan,<br>
<br>
I tested the version of Gcra.cpp that I<br>
sent you on x86-64 systems<br>
running MacOS 10.8 and Ubuntu 12.04<br>
(Linux 3.2.0).<br>
<br>
Could you send me the bitcode file you're<br>
compiling? Different<br>
bitcodes (due to different clang versions<br>
or applied<br>
optimizations) could account for the<br>
different results we're<br>
seeing. For reference I've attached the<br>
*.ll file that I have<br>
tested with, which was compiled from your<br>
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<br>
checkout from subversion.<br>
<br>
It's unlikely that there is any<br>
fundamental problem with the<br>
register allocation APIs or the code<br>
generator that would prevent<br>
you from building a working allocator.<br>
The APIs certainly could<br>
have changed in a way that would break<br>
existing allocators though.<br>
<br>
- Lang.<br>
<br>
<br>
On Sat, Nov 3, 2012 at 4:34 PM, Susan<br>
Horwitz <<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></div></div><div class="im">
<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></div><div><div class="h5">
Lang -<br>
<br>
Your version does NOT work for me<br>
(i.e., I still get an error<br>
from the assembler when I run your<br>
code on my tst.c) unless I<br>
force compilation and assembly for a<br>
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.<br>
Maybe you are working with a<br>
different architecture and that's why<br>
it worked for you?<br>
<br>
I would be happy if the above worked<br>
in general, but when I<br>
try other C code (with my "real"<br>
register allocator, not the<br>
naive one I sent you) I get assembly<br>
that includes<br>
<br>
%r8d<br>
<br>
which seems to be invalid for a<br>
32-bit machine. Sigh. It<br>
looks to me like there's a problem<br>
with the LLVM-3.1 API for<br>
register allocation and/or the<br>
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>
<br>
Hi Susan,<br>
<br>
Without debugging symbols I can't<br>
make much out of that stack<br>
trace I'm afraid.<br>
<br>
I've attached my modified version<br>
of Gcra.cpp. I built llvm<br>
3.1 by dropping this file into<br>
lib/CodeGen, and adding<br>
references to createGcra to<br>
include/lib/CodeGen/Passes.h and<br>
<br>
include/lib/CodeGen/<u></u>LinkAllCodeGenComponents.h.<br>
(If you<br>
search for createRegAllocPBQP<br>
you'll see where to add the<br>
declarations).<br>
<br>
With that setup, running your<br>
allocator on the tst.c file you<br>
attached previously yielded a<br>
sane assembly file.<br>
<br>
Cheers,<br>
Lang.<br>
<br>
On Thu, Nov 1, 2012 at 3:13 PM,<br>
Susan Horwitz<br>
<<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></div></div><div class="im">
<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></div><div><div class="h5">
I still get a coredump:<br>
<br>
0 <a href="http://libLLVM-3.1.so" target="_blank">libLLVM-3.1.so</a><br>
<<a href="http://libLLVM-3.1.so" target="_blank">http://libLLVM-3.1.so</a>><br>
<<a href="http://libLLVM-3.1.so" target="_blank">http://libLLVM-3.1.so</a>> 0x00007f0158a4e67f<br>
1 <a href="http://libLLVM-3.1.so" target="_blank">libLLVM-3.1.so</a><br>
<<a href="http://libLLVM-3.1.so" target="_blank">http://libLLVM-3.1.so</a>><br>
<<a href="http://libLLVM-3.1.so" target="_blank">http://libLLVM-3.1.so</a>> 0x00007f0158a500ca<br>
2 libpthread.so.0<br>
0x0000003a86c0f500<br>
<br>
3 <a href="http://libLLVM-3.1.so" target="_blank">libLLVM-3.1.so</a><br>
<<a href="http://libLLVM-3.1.so" target="_blank">http://libLLVM-3.1.so</a>><br>
<<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><br>
<<a href="http://libLLVM-3.1.so" target="_blank">http://libLLVM-3.1.so</a>><br>
<<a href="http://libLLVM-3.1.so" target="_blank">http://libLLVM-3.1.so</a>><br>
0x00007f0158546349<br>
<br>
llvm::FPPassManager::<u></u>runOnFunction(llvm::Function&)<br>
+ 521<br>
5 <a href="http://libLLVM-3.1.so" target="_blank">libLLVM-3.1.so</a><br>
<<a href="http://libLLVM-3.1.so" target="_blank">http://libLLVM-3.1.so</a>><br>
<<a href="http://libLLVM-3.1.so" target="_blank">http://libLLVM-3.1.so</a>><br>
<br>
0x00007f01585463e3<br>
<br>
llvm::FPPassManager::<u></u>runOnModule(llvm::Module&)<br>
+ 51<br>
6 <a href="http://libLLVM-3.1.so" target="_blank">libLLVM-3.1.so</a><br>
<<a href="http://libLLVM-3.1.so" target="_blank">http://libLLVM-3.1.so</a>><br>
<<a href="http://libLLVM-3.1.so" target="_blank">http://libLLVM-3.1.so</a>><br>
<br>
0x00007f0158545fae<br>
<br>
llvm::MPPassManager::<u></u>runOnModule(llvm::Module&)<br>
+ 462<br>
7 <a href="http://libLLVM-3.1.so" target="_blank">libLLVM-3.1.so</a><br>
<<a href="http://libLLVM-3.1.so" target="_blank">http://libLLVM-3.1.so</a>><br>
<<a href="http://libLLVM-3.1.so" target="_blank">http://libLLVM-3.1.so</a>><br>
<br>
0x00007f01585460bd<br>
<br>
llvm::PassManagerImpl::run(<u></u>llvm::Module&)<br>
+ 125<br>
8 llc<br>
0x000000000040b012 main + 5218<br>
9 libc.so.6<br>
0x0000003a8601ecdd __libc_start_main + 253<br>
10 llc<br>
0x0000000000407d79<br>
Stack dump:<br>
0. Program arguments:<br>
llc -load Debug/lib/P4.so<br>
-regalloc=gc tst.bc<br>
1. Running pass<br>
'Function Pass Manager' on module<br>
'tst.bc'.<br>
2. Running pass 'Machine<br>
Loop Invariant Code Motion'<br>
on function '@main'<br>
make: *** [tst.reg]<br>
Segmentation fault (core dumped)<br>
<br>
<br>
<br>
On 11/01/2012 04:59 PM, Lang<br>
Hames wrote:<br>
<br>
Hi Susan,<br>
<br>
Sorry - I had missed that<br>
you're using llvm-3.1,<br>
rather than the<br>
development branch. We<br>
encourage people to live on<br>
top-of-tree - it's<br>
well tested, easier for<br>
active developers to offer<br>
help with, and<br>
keeping up with<br>
incremental changes is often easier<br>
than porting between<br>
stable versions.<br>
<br>
It also sounds like you<br>
were building a Release<br>
version of LLVM. That<br>
will not have any asserts<br>
enabled (though it will<br>
have some other<br>
diagnostics). You will<br>
probably want to work with a<br>
Debug+Asserts<br>
version (<src>/configure<br>
--disable-optimized<br>
--enable-assertions) while<br>
you're developing your<br>
allocator and watch for any<br>
asserts that trigger.<br>
<br>
In your case the<br>
Assertion that is triggering in PEI<br>
indicates that the<br>
MachineRegisterInfo<br>
object still contained some<br>
virtregs post<br>
register-allocation. You<br>
need to call<br>
MRI->clearVirtRegs() at<br>
the end of<br>
your allocator.<br>
<br>
Hope this helps!<br>
<br>
Cheers,<br>
Lang.<br>
<br>
On Thu, Nov 1, 2012 at<br>
2:41 PM, Susan Horwitz<br>
<<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></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>
Hi again Lang,<br>
<br>
I decided to try the<br>
approach you proposed to see<br>
whether it makes<br>
the assembly-code<br>
problem go away. Again, I<br>
tried a very simple<br>
register allocator<br>
(attached) that just calls<br>
vrm.assignVirt2Phys<br>
for every vreg in<br>
each function, mapping the vreg<br>
to the first preg<br>
in the register<br>
class. I tried two versions: one<br>
maps *every* vreg,<br>
and the other only<br>
maps those for which<br>
MRI->reg_empty(vreg) returns<br>
false. In both cases<br>
I get a core dump somewhere<br>
after my<br>
reg-allocation pass<br>
has run (when I use the<br>
"tst.c" file that I sent<br>
last time as input).<br>
<br>
Note also that there<br>
is no VirtRegMap.h in the<br>
"include" directory<br>
of my installed<br>
llvm-3.1. I had to copy that<br>
file from the source<br>
directory. That<br>
seems suspicious.<br>
<br>
Any thoughts?<br>
<br>
Thanks!<br>
<br>
Susan<br>
<br>
<br>
On 10/31/2012 07:51<br>
PM, Lang Hames wrote:<br>
<br>
Hi Susan,<br>
<br>
I'm having<br>
trouble reproducing that error on<br>
my end, but I think the<br>
problem is<br>
probably that you're not using the<br>
VirtRegRewriter<br>
infrastructure.<br>
What your allocator needs to<br>
do is populate the<br>
virtual<br>
register mapping<br>
(VirtRegMap pass) with your<br>
allocation, rather than<br>
rewriting the<br>
registers directly through<br>
MachineRegisterInfo.<br>
<br>
Have your<br>
allocator require and preserve the<br>
VirtRegMap pass,<br>
then in<br>
your<br>
runOnMachineFunction pass grab a<br>
reference to the pass with:<br>
<br>
VirtRegMap &vrm =<br>
getAnalysis<VirtRegMap>();<br>
<br>
You can then<br>
describe your register<br>
allocations with:<br>
<br>
<br>
vrm.assignVirt2Phys(<virtreg>, <physreg>)<br>
<br>
The<br>
VirtRegRewriter pass (in VirtRegMap.cpp)<br>
will run after your<br>
allocator and<br>
apply the mapping that you<br>
described in the<br>
VirtRegMap.<br>
<br>
I hope this<br>
helps. Let me know if it doesn't<br>
fix your issue.<br>
<br>
Cheers,<br>
Lang.<br>
<br>
On Wed, Oct 31,<br>
2012 at 3:54 PM, Susan Horwitz<br>
<<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>>>><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>>><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>
Thanks Lang!<br>
<br>
Here's<br>
another question: I'm trying to<br>
process this input:<br>
<br>
int main() {<br>
return 0;<br>
}<br>
<br>
but I'm<br>
getting an error<br>
Assertion<br>
`!Fn.getRegInfo().<br>
getNumVirtRegs() &&<br>
"Regalloc must<br>
<br>
assign all<br>
vregs"' failed.<br>
<br>
At the start<br>
of runOnMachineFunction I<br>
call Fn.getRegInfo().<br>
<br>
getNumVirtRegs();<br>
and find<br>
that there is 1 virtual<br>
register. However,<br>
<br>
MRI->reg_empty(vreg)<br>
tells me<br>
that it is not used or defined.<br>
So my<br>
register-allocation<br>
code never<br>
sees it, and thus can't<br>
allocate a preg for it.<br>
I tried<br>
using<br>
MRI->replaceRegWith(vreg, preg);<br>
(where preg<br>
is available to vreg's<br>
register class) but that<br>
didn't<br>
work. When<br>
I look, the number of vregs<br>
in the function is<br>
still 1.<br>
<br>
Can you help<br>
with this?<br>
<br>
Thanks again!<br>
<br>
Susan<br>
<br>
<br>
On<br>
10/31/2012 04:55 PM, Lang Hames wrote:<br>
<br>
Hi Susan,<br>
<br>
The<br>
meaning of "addRequired(X)" is<br>
that your pass needs<br>
X to be<br>
run, and<br>
for X to<br>
be preserved by all passes<br>
that run after X<br>
and before your<br>
pass.<br>
The PHIElemination and<br>
TwoAddressInstruction<br>
passes do not<br>
preserve<br>
each other, hence there's<br>
no way for the pass<br>
manager to<br>
schedule<br>
them for you if you<br>
addRequire(...) them.<br>
<br>
The<br>
trick is that CodeGen will<br>
schedule both of these<br>
passes to<br>
be run<br>
before<br>
_any_ register allocation<br>
pass (see Passes.cpp),<br>
so you<br>
needn't<br>
require<br>
them explicitly - you can<br>
just assume they have<br>
been<br>
run. If you<br>
just<br>
remove those lines from your<br>
getAnalysisUsage<br>
method your pass<br>
should<br>
now run as you expect.<br>
<br>
Cheers,<br>
Lang.<br>
<br>
On Wed,<br>
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><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>>>><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><br>
<mailto:<a href="mailto:horwitz@cs.wisc.edu" target="_blank">horwitz@cs.wisc.edu</a>>>><u></u>><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><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>><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<br>
trying to write a<br>
MachineFunctionPass to do<br>
register<br>
allocation.<br>
I<br>
have code that worked with<br>
an old version of<br>
LLVM. It<br>
does not<br>
<br>
work with llvm-3.1. (or various<br>
other versions<br>
that I've<br>
tried).<br>
<br>
The<br>
first problem is that<br>
including this line:<br>
<br>
<br>
AU.addRequiredID(__<br>
TwoAddressInstructionPassID);<br>
<br>
<br>
in<br>
method getAnalysisUsage<br>
causes a runtime error:<br>
<br>
<br>
Unable to schedule 'Eliminate<br>
PHI nodes for register<br>
allocation'<br>
<br>
required by 'Unnamed pass:<br>
implement<br>
Pass::getPassName()'<br>
<br>
Unable to schedule pass<br>
<br>
UNREACHABLE executed at ...<br>
<br>
I'm<br>
invoking the pass like this<br>
(given input file<br>
foo.c):<br>
<br>
<br>
clang -emit-llvm -O0 -c foo.c<br>
-o foo.bc<br>
opt<br>
-mem2reg foo.bc > foo.ssa<br>
mv<br>
foo.ssa foo.bc<br>
llc<br>
-load Debug/lib/P4.so<br>
-regalloc=gc foo.bc<br>
<br>
<br>
<br>
I've attached my entire file<br>
(it's very short).<br>
Any help<br>
would be<br>
<br>
much appreciated!<br>
<br>
<br>
Susan Horwitz<br>
<br>
<br>
______________________________<br>
_________________<br>
<br>
LLVM Developers mailing list<br>
<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>>>><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><br>
<mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>>>><u></u>><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><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>><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><br>
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>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</div></div></blockquote>
<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
<br>
</blockquote></div><br></div>