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><font face="courier new, monospace">llvm-dis -o <asm file> <bitcode></font></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" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<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 class="HOEnZb"><font color="#888888"><br>
<br>
Susan</font></span><div><div class="h5"><br>
<br>
On 11/7/2012 7:31 PM, Lang Hames wrote:<br>
</div></div></div><div><div class="h5">
<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>