<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 22, 2008, at 11:03 AM, Wei wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>I have 24-bit integer operations as well as 24-bit floating point<br>(s7.16) operations.<br><br>The H/W supports load/store instructions, however, they does suggest<br>us not to use these load/store instructions besides debugging purpose.<br>That is to say, you can imagine we don't have load/store instructions,<br>we don't have memory, we just have registers.<br><br>I will run OpenGL shading laugnage programs on these chip.</div></blockquote><div><br></div>GLSL doesn't have pointers, so no "generic" load + store simplifying things.<br><br></div><div>Unextended GLSL only requires support for integers in the 16 bit range, and has no bitwise operations. It also doesn't specify integer overflow behavior in any way.</div><div><div><br></div><div>The machines I worked with didn't support any integer ops, but GLSL let us get by with "emulated" 16 bit integers (storing and operating on them as floating point; divides required truncation after the op - that sort of thing).<div><br></div><div>Since you have 24 bit integer operations, you're in better shape.</div></div><div><br></div><blockquote type="cite"><div>About your comments, I (a new LLVM user) have some more questions:<br><br>1) You mention "custom handle the conversion of the integer/float<br>constants that LLVM spits out", does it means:<br>I have to register a callback function which will operate when LLVM<br>wants to spits out a constant value to memory. But what about non-<br>constant value? </div></blockquote><div><br></div><div>What I mean is that you can probably get away with LLVM working with float literals as f32, then converting them to your 24 bit format during code gen. The specifics depend on how you want to handle constants in your backend: literals in instructions or a constant pool are the options I know of. For now, I'm using special "load literal" instructions, but a constant pool may be more appropriate in the long run. I'm still learning.</div><div><br></div><div>Integers too: let LLVM work with i32 internally, and convert literals during code gen.</div><div><br></div><div>Since GLSL doesn't require load/store, and it sounds like your HW may not 100% reliable for these ops, you want to make sure your code stays in registers.</div><div><br></div><div>I assume you'll be starting with the reference GLSL parser (from 3DLabs, IIRC - I don't even know if they stil exist, actually) and having it generate LLVM IR (has anybody done this before?). This will give you much more control over the code - Clang is the front end for the project I'm working on, and it generates stack based code; most of the stack operations get optimized out by inlining and the mem2reg pass, but not everything.</div><div><br></div><div><br></div><blockquote type="cite"><div>ex:<br>int a;<br>and LLVM wants to put a into memory.</div></blockquote><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>and I don't really know what the "i32/f32 sounds a good place to<br>start" means...</div></blockquote><div><br></div><div>I mean that having your registers declared as i32 + f32 will probably work out well, especially since you don't have pointers in your language. </div><div><br></div><div>The issue would be that LLVM would want to store register values as 32 bits - and do all the pointer math that way. Depending on how your HW works, this may or may not be okay. Even then, you might be able to patch it up if you really needed to store your registers 3 byte aligned.</div><div><br></div><div>Fortunately, this is not an issue with GLSL.</div><div><br></div><blockquote type="cite"><div>2) I don't know why you mention "I'd assume you'd have intrinsics for<br>I/O."</div></blockquote><div><br></div><div>For GLSL, you have to have some way of reading attributes and uniforms, exporting to/reading from varyings, etc.</div><div><br></div><div>Different GPUs do things differently of course: in some cases, it's a matter of certain GPRs being initialized by "fixed function" HW with input values at the start of the shader and certain GPRs being left with output values at the end of the shader. Other GPUs require explicit "export" instructions, perhaps just reads/writes to dedicated I/O registers. Some have a mix (this is the case for HW I've worked with).</div><div><br></div><div>If you have export instructions, or even special I/O registers, I was thinking that they could be represented or accessed by Target specific ops -intrinsics. You'd have the GLSL front end generate these intrinsic operations.</div><div><br></div><div>I haven't had to work with register constraints in LLVM, so I'm not sure what would be best approach if I/O is done through specific GPRs: you don't want to reserve those registers for I/O only.... it would take some exploration.</div><div><br></div><blockquote type="cite"><div><br>3) I don't think I get you about the following statements:<br><blockquote type="cite">If you want to support memory operations, your integers need to<br></blockquote><blockquote type="cite">support the addressing range correctly - you effectively have 17 bits<br></blockquote><blockquote type="cite">of mantissa - so it may be a tight squeeze without 24 bit integer ops<br></blockquote><blockquote type="cite">(shifts and ands and stuff will also be a painful, but that's a more<br></blockquote><blockquote type="cite">expansive topic).<br></blockquote>Can you give some example?</div></blockquote><div><br></div><div>Sorry, I was "thinking out loud".</div><div><br></div><div>I made the assumption here that you didn't have 24 bit integer ops, and that you might try to represent pointers as integers in a single 24 bit float value (maybe with a 1D texture as your addressable memory). In that case, you'd have a very limited range.</div><div><br></div><div>But GLSL doesn't have pointers, so this isn't an issue (and 24 bit integers gives you a decent addressing range for debugging).</div><div><br></div><div>Dan</div><div><br></div><div><br></div><div><br></div><blockquote type="cite"><div><br>Really really thanks about your comments.<br><br>Wei.<br><br>On Nov 20, 10:24 pm, Daniel M Gessel <ges...@apple.com> wrote:<br><blockquote type="cite">This is similar to ATI's R300/R420 pixel shaders. I'm familiar with <br></blockquote><blockquote type="cite">this hardware, but not really an LLVM expert (working on a code <br></blockquote><blockquote type="cite">generator myself, but learning as I go).<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Do you have 24-bit integer operations, or just floating point?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">What about load/store?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Are you looking to run large C programs with complex data structures, <br></blockquote><blockquote type="cite">or just comparatively simple math functions (i.e. a compute "kernel")?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">If you only want to support programs that can live entirely within <br></blockquote><blockquote type="cite">registers, you can custom handle the conversion of the integer/float <br></blockquote><blockquote type="cite">constants that LLVM spits out and i32/f32 sounds a good place to start <br></blockquote><blockquote type="cite">- LLVM's mem2reg and inlining is very effective at getting rid the <br></blockquote><blockquote type="cite">majority of stack operations, and I'd assume you'd have intrinsics for <br></blockquote><blockquote type="cite">I/O.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">If you want to support memory operations, your integers need to <br></blockquote><blockquote type="cite">support the addressing range correctly - you effectively have 17 bits <br></blockquote><blockquote type="cite">of mantissa - so it may be a tight squeeze without 24 bit integer ops <br></blockquote><blockquote type="cite">(shifts and ands and stuff will also be a painful, but that's a more <br></blockquote><blockquote type="cite">expansive topic).<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Dan<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Nov 20, 2008, at 7:46 AM, Wei wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Because each channel contains 24-bit, so.. what is the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">llvm::SimpleValueType I should use for each channel?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the current llvm::SimpleValueType contains i1, i8, i16, i32, i64, f32,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">f64, f80, none of them are fit one channel (24-bit).<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">I think I can use i32 or f32 to represent each 24-bit channel, if the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">runtime result of some machine instructions exceeds 23-bit (1 bit is<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">for sign), then it is an overflow.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Is it correct to claim that the programmers needs to revise his<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">program to fix this problem?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Am I right or wrong about this thought?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">If there is a chip, whose registers are 24-bit long, and you have to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">compile C/C++ programs on it.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">How would you represent the following statement?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">int a = 3;<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">(Programmers think sizeof(int) = 4)<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Wei.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">On Nov 19, 2:01 am, Evan Cheng <evan.ch...@apple.com> wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Why not model each channel as a separate physical register?<br></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Evan<br></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Nov 17, 2008, at 6:36 AM, Wei wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I have a very strange and complicate H/W platform.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">It has many registers in one format.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The register format is:<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">------------------------------<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">----------------------------------------------------------------------------------------<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">| 24-bit | 24-bit<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">| 24-bit | 24-bit |<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">----------------------------------------------------------------------------------------------------------------------<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> a<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">b<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">c d<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">There are 4 channels in a register, and each channel contains 24-<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">bit, hence, there are total 96-bit in 'one' register.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">You can store a 24-bit integer or a s7.16 floating-point data into<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">each channel.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">You can name each channel 'a', 'b', 'c', 'd'.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Here is an example of the operation in this H/W platform:<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> ADD R3.ab, R1.abab, R2.bbaa<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">it means<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> Add 'abab' channel of R1 and 'bbaa' channel of R2, and<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">put the result into the 'ab' channel of R3.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">It's complicate.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Imagine a non-existed temp register named 'Rt1', the content of its<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">'a','b','c','d' channel are got from 'a','b','a','b' channel of R1,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">and imagine another non-existed temp register named 'Rt2', the<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">content of its 'a','b','c','d' channel are got from 'b','b','a','a'<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">channel of R2.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">and then add Rt1 & Rt2, put the result to R3<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">this means<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the 'a' channel of R3 will be equal to the 'a' channel of Rt1 plus<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the 'a' channel of Rt2, (i.e. 'a' from R1 + 'b' from R2, because<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">R1.'a'bab and R2.'b'baa)<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the 'b' channel of R3 will be equal to the 'b' channel of Rt1 plus<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the 'b' channel of Rt2, (i.e. 'b' from R1 + 'b' from R2, because<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">R1.a'b'ab and R2.b'b'aa)<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the 'c' channel of R3 will be untouched, the value of the 'c'<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">channel of Rt1 plus the 'c' channel of Rt2 (i.e. 'a' from R1 + 'a'<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">from R2, because R1.ab'a'b and R2.bb'a'a) will be lost.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the 'd' channel of R3 will be untouched, too. The value of the 'd'<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">channel of Rt1 plus the 'd' channel of Rt2 (i.e. 'b' from R1 + 'a'<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">from R2, because R1.aba'b' and R2.bba'a') will be lost, too.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I don't know whether I can set the 'type' of such register using a<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">llvm::MVT::SimpleValueType?<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">According the LLVM doc & LLVM source codes, I think llvm::MVT::v8i8,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">v2f32, etc is used to represent register for SIMD instructions.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I don't think the operations in my platform are SIMD instructions.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">However, I can not find any llvm::MVT::SimpleValueType which can<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">represents a 96-bit register.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Thus, my question is:<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">1) Does current LLVM backend supports this H/W?<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">2) If yes, how can I write the type of the register class in my .td<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">file?<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">(Which value should I fill in the following 'XXX' ?)<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">def TempRegs : RegisterClass<"MFLEXG", [XXX], 32, [R0, R1, R2, R3,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">R4, R5, R6, R7, R8, R9,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> R10, R11, R12,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">R13, R14, R15, R16, R17, R18, R19,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> R20, R21, R22,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">R23, R24, R25, R26, R27, R28, R29,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> R30, R31]> {<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">}<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">3) If not, does this means I have to write the whole LLVM backend<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">based on the basic llvm::TargetMachine & llvm::TargetData, just like<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">what CBackend does?<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">--------------------------------------------------------<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Wei Hu<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="http://www.csie.ntu.edu.tw/~r88052/">http://www.csie.ntu.edu.tw/~r88052/</a><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="http://wei-hu-tw.blogspot.com/">http://wei-hu-tw.blogspot.com/</a><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">LLVM Developers mailing list<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">LLVM...@cs.uiuc.edu <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">LLVM Developers mailing list<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">LLVM...@cs.uiuc.edu <a href="http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">LLVM Developers mailing list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">LLVM...@cs.uiuc.edu <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">LLVM Developers mailing list<br></blockquote><blockquote type="cite">LLVM...@cs.uiuc.edu <a href="http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote><br>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></div></blockquote></div><br></body></html>