Hi Susan,<div><br></div><div>The problem is that the allocator is re-using the 'preg', which is calculated for an operand that may have a subreg index, for loads and stores to a stack-slot. The stack slot always has the same width as vreg (which is the right behavior), but for operands with subreg indexes, 'preg''s class will be different from 'vreg', in which case you get the mismatched loads/stores you were seeing.</div>
<div><br></div><div>I've attached an updated copy of Gcra.cpp that doesn't exhibit this bug. In the new version the loads and stores always reference 'preg', which is always a physical register of the same class as 'vreg'. The update adds a new variable, preg_op, to hold the subregister of preg that will be used for the operand currently being rewritten, and preg_op will be set to a subreg of preg where appropriate.</div>
<div><br></div><div>- Lang.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Nov 11, 2012 at 10:30 AM, 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">
<div text="#000000" bgcolor="#FFFFFF">
<div>Sorry about that. I created the
assembly file and attached it (as math.txt).<br>
<br>
Susan<br>
<br>
On 11/11/2012 12:41 AM, Lang Hames wrote:<br>
</div>
<blockquote type="cite">
Hi Susan,
<div><br>
</div>
<div>It looks like the bitcode you have attached is corrupted. You
should make sure to attach it as a binary file. Alternatively
you can attach the LLVM assembly as text. You can generate an
assembly file from bitcode with:</div>
<div><br>
</div>
<div>llvm-dis -o <asm file> <bitcode></div>
<div><br>
</div>
<div>Regards,</div>
<div>Lang.</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
On Fri, Nov 9, 2012 at 11:15 AM, 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">
<div>
<div>Thanks Lang, we are making progress! I no longer get
the failed assertion, but the code I'm using for vregs
that don't get allocated a preg, and thus need to be
spilled and re-loaded is causing assembler errors.<br>
<br>
I suspect the problem is my code for allocating space in
the stack, but I don't know how to fix it.<br>
<br>
I've attached a new version of the simple
register-allocation code, a test program that causes the
bad assembler to be produced, and the bc file. (I had
to name everything with a .txt extension to copy the
files to my laptop.)<br>
<br>
As always, thank you for your help!<span><br>
<br>
Susan</span>
<div>
<div><br>
<br>
On 11/7/2012 7:31 PM, Lang Hames wrote:<br>
</div>
</div>
</div>
<div>
<div>
<blockquote type="cite"> Hi Susan,
<div><br>
</div>
<div>In x86-64 the REX prefix must be used to access
an extended register (r8-r15 and their aliases),
but cannot be used when accessing the high byte of
the ABCD regs (AH, BH, CH, DH). In your test case
you have hardcoded %vreg1 to R8B, and %vreg15 to
AH, and the test case contains a copy between
these registers. The copy simultaneously must have
a REX prefix, and cannot have a REX prefix, hence
the assertion.</div>
<div><br>
</div>
<div>The problem is that not all registers in a
class are allocable for all vregs. As you can see
from the above constraint, which pregs are valid
varies dynamically depending on the context that
the register is used. The trick is to query the
"allocation order" for a class (and as an added
headache filter out any reserved registers). I've
attached a test-case where I do this somewhat
manually. In short:</div>
<div><br>
</div>
<div>
<div>int regClass =
MRI->getRegClass(vreg)->getID();</div>
<div>const TargetRegisterClass *trc =
TRI->getRegClass(regClass);</div>
<div>ArrayRef<uint16_t> rawOrder =
trc->getRawAllocationOrder(Fn);</div>
<div>ArrayRef<uint16_t>::iterator rItr =
rawOrder.begin();</div>
<div>while (reservedRegs.test(*rItr))</div>
<div> ++rItr;</div>
<div>preg = *rItr;</div>
</div>
<div><br>
</div>
<div>Alternatively, you could use the
AllocationOrder class
(lib/CodeGen/AllocationOrder.h). This has the
benefit of considering register hints for improved
coalescing too. It does, however, require you to
use VirtRegMap.</div>
<div><br>
</div>
<div>Hope this helps!</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Lang.</div>
<div><br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Nov 7, 2012 at
2:56 PM, Lang Hames <span dir="ltr"><<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote">Hi Susan,
<div><br>
</div>
<div>Sorry for the delayed response. Thanks
for the test cases - I'm looking in to this
now.</div>
<span>
<div><br>
</div>
<div>- Lang.</div>
</span>
<div>
<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">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><br>
<br>
On 11/04/2012 06:19 PM, Lang Hames
wrote:<br>
</div>
<blockquote class="gmail_quote"> Hi
Susan,<br>
<br>
<div> 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> <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/%7Ehorwitz/LANG/tst.bc" target="_blank">http://pages.cs.wisc.edu/~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">
<div>
<div> 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> <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">
<div>
<div> 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/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> <<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> 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><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>
0x00007f0158546349<br>
llvm::FPPassManager::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><br>
0x00007f01585463e3<br>
llvm::FPPassManager::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><br>
0x00007f0158545fae<br>
llvm::MPPassManager::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><br>
0x00007f01585460bd<br>
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<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>
<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>
<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>>>>>
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>>>>>>
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>>>>><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/__mailman/listinfo/llvmdev</a><br>
<<a 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>
<br>
<br>
</div>
</div>
</blockquote>
<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote></div><br></div>