<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 31, 2016, at 8:50 PM, Mehdi Amini via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Mar 31, 2016, at 7:11 PM, David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="gmail_extra"><br class="Apple-interchange-newline"><br class=""><div class="gmail_quote">On Tue, Mar 29, 2016 at 11:50 PM, Eric Christopher via cfe-dev<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><span class=""><div dir="ltr" class="">On Tue, Mar 29, 2016 at 11:20 PM Robinson, Paul <<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank" class="">Paul_Robinson@playstation.sony.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div lang="EN-US" link="blue" vlink="purple" class=""><div class=""><p class="MsoNormal"><span class="" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">Skipping a serialization and doing something clever about LTO uniquing sounds awesome. I'm guessing you achieve this by extracting types out of DI metadata and packaging them as lumps-o-DWARF that the back-end can then paste together? Reading between the lines a bit here.<u class=""></u><u class=""></u></span></p><div class=""><span class="" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);"></span><br class="webkit-block-placeholder"></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Pretty much, yes.</div><span class=""><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div lang="EN-US" link="blue" vlink="purple" class=""><div class=""><p class="MsoNormal"><span class="" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">Can you share data about how much "pure" types dominate the size of debug info? Or at least the current metadata scheme? (Channeling Sean Silva here: show me the data!) Does this hold for C as well as C++?</span></p></div></div></blockquote></span><div class="">They're huge. It's ridiculous. Take a look at the size of the metadata and then the size of the stuff we put in there versus dwarf.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Because numbers are nice to have, I modified Clang to generate every type as 'int' (patch attached - I may've screwed some things up) & then compiled llvm-tblgen's object files with -flto (I would've used all of clang, but I don't have the lto plugin setup, so I couldn't get past tblgen)<br class=""></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I guess you have a non-LTO build somewhere, so you should be able to build other tools by bypassing the llvm-tblgen build using:</div><div class=""><br class=""></div><div class="">cmake -DLLVM_TABLEGEN=path/to/llvm-tblgen ..</div></div></div></blockquote><div><br class=""></div><div>To be clear: that was meant as FYI / good to know, I was not asking you for more data.</div><div><br class=""></div><div>-- </div><div>Mehdi</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class="">Without debug info: 77 MB of bitcode files<br class="">With debug info: 24 MB<br class="">With debug info, but no types: 46 MB<br class=""><br class="">so... 59% is pure type descriptions (these are the pure ones, the same things we put in type units - I didn't even remove the injected declarations (so if you compile example programs with this - you'll find that the DW_TAG_base_type for "int" has a child for every member function declaration that's defined (even used inline functions) in this translation unit) for this particular test, at least. Clang would be a larger/more representative sample.<br class=""></div><div class=""><br class=""></div><div class="">I confirmed that both with and without types, there were the same number (48542) of subprogram definitions and without types there were no instances of DICompositeType (both of these were confirmed with xargs/llvm-dis/grep, nothing fancy)<br class=""><br class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">And yes, it also trivially holds for C.</div><span class=""><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div lang="EN-US" link="blue" vlink="purple" class=""><div class=""><p class="MsoNormal"><span class="" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);"><u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span class="" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">Not much discussion of data objects and code objects (other than concrete subprograms), is that because they basically aren't changing? Still defined in the metadata and still managed/emitted by the back-end?</span></p></div></div></blockquote><div class=""><br class=""></div></span><div class="">Yep. A way of looking at it is more that it is related to things in the IR and so needs IR to represent it.</div><span class=""><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div lang="EN-US" link="blue" vlink="purple" class=""><div class=""><p class="MsoNormal"><span class="" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);"><u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span class="" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">Please say something about types (which you're thinking of as a front-end thing) defined within scopes (which it looks like you're thinking of as a back-end thing). Not seeing how to get the scoping right.<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span class="" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);"><u class=""></u> </span></p></div></div></blockquote><div class=""><br class=""></div></span><div class="">Basic idea is non-defining declarations holding types and be the abstract origin for the concrete function? Honestly, I wish they were type unitable at the moment, but that might be something to look into. The current plan at least. This will make some debug info a little bit larger, but only for things like nested types where we need to throw an extra declaration (i.e. the same sorts of places that type units make things larger).</div><div class=""><br class=""></div><div class="">At any rate, the first thing is to get the APIs split anyhow.</div><div class=""><br class=""></div><div class="">-eric</div><div class=""><div class=""><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div lang="EN-US" link="blue" vlink="purple" class=""><div class=""><p class="MsoNormal"><span class="" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);"><u class=""></u></span></p><p class="MsoNormal"><span class="" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">Thanks!<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span class="" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);">--paulr<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><a name="m_-3608509686125761661_m_4039372186788237136_m_7647402183533570110_m_-4897511106553300520__MailEndCompose" class=""><span class="" style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);"><u class=""></u> <u class=""></u></span></a></p><div class="" style="border-style: none none none solid; border-left-color: blue; border-left-width: 1.5pt; padding: 0in 0in 0in 4pt;"><div class=""><div class="" style="border-style: solid none none; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in;"><p class="MsoNormal"><b class=""><span class="" style="font-size: 10pt; font-family: Tahoma, sans-serif;">From:</span></b><span class="" style="font-size: 10pt; font-family: Tahoma, sans-serif;"><span class="Apple-converted-space"> </span>cfe-dev [mailto:<a href="mailto:cfe-dev-bounces@lists.llvm.org" target="_blank" class="">cfe-dev-bounces@lists.llvm.org</a>]<span class="Apple-converted-space"> </span><b class="">On Behalf Of<span class="Apple-converted-space"> </span></b>Eric Christopher via cfe-dev<br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>Tuesday, March 29, 2016 6:01 PM<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span>Clang Dev; llvm-dev<br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>[cfe-dev] RFC: Up front type information generation in clang and llvm<u class=""></u><u class=""></u></span></p></div></div></div></div></div><div lang="EN-US" link="blue" vlink="purple" class=""><div class=""><div class="" style="border-style: none none none solid; border-left-color: blue; border-left-width: 1.5pt; padding: 0in 0in 0in 4pt;"><p class="MsoNormal"><u class=""></u> <u class=""></u></p><div class=""><div class=""><p class="MsoNormal">Hi All,<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">This is something that's been talked about for some time and it's probably time to propose it.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">The "We" in this document is everyone on the cc line plus me.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">Please go ahead and take a look.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">Thanks!<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">-eric<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">Objective (and TL;DR)<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">=================<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">Migrate debug type information generation from the backends to the front end.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">This will enable:<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">1. Separation of concerns and maintainability: LLVM shouldn’t have to know about C preprocessor macros, Obj-C properties, or extensive details about debug information binary formats.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">2. Performance: Skipping a serialization should speed up normal compilations.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">3. Memory usage: The DI metadata structures are smaller than they were, but are still fairly large and pointer heavy.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">Motivation<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">========<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">Currently, types in LLVM debug info are described by the DIType class hierarchy. This hierarchy evolved organically from a more flexible sea-of-nodes representation into what it is today - a large, only somewhat format neutral representation of debug types. Making this more format neutral will only increase the memory use - and for no reason as type information is static (or nearly so). Debug formats already have a memory efficient serialization, their own binary format so we should support a front end emitting type information with sufficient representation to allow the backend to emit debug information based on the more normal IR features: functions, scopes, variables, etc.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">Scope/Impact<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">===========<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">This is going to involve large scale changes across both LLVM and clang. This will also affect any out-of-tree front ends, however, we expect the impact to be on the order of a large API change rather than needing massive infrastructure changes.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">Related work<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">==========<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">This is related to the efforts to support CodeView in LLVM and clang as well as efforts to reduce overall memory consumption when compiling with debug information enabled; in particular efforts to prune LTO memory usage.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">Concerns<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">========<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">We need a good story for transitioning all the debug info testcases in the backend without giving up coverage and/or readability. David believes he has a plan here.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">Proposal<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">=======<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">Short version<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">-----------------<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">1. Split the DIBuilder API into Types (+Macros, Imports, …) and Line Table.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">2. Split the clang CGDebugInfo API into Types and Line Table to match.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">3. Add a LLVM DWARF emission library similar to the existing CodeView one.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">4. Migrate the Types API into a clang internal API taking clang AST structures and use the LLVM binary emission libraries to produce type information.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">5. Remove the old binary emission out of LLVM.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">Questions/Thoughts/Elaboration<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">-------------------------------------------<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">Splitting the DIBuilder API<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">~~~~~~~~~~~~~~~~~~~~<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">Will DISubprogram be part of both?<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> * We should split it in two: Full declarations with type and a slimmed down version with an abstract origin.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">How will we reference types in the DWARF blob?<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> * ODR types can be referenced by name<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> * Non-odr types by full DWARF hash<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> * Each type can be a pair(tuple) of identifier (DITypeRef today) and blob.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> * For < DWARF4 we can emit each type as a unit, but not a DWARF Type Unit and use references and module relocations for the offsets. (See below)<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">How will we handle references in DWARF2 or global relocations for non-type template parameters?<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> * We can use a “relocation” metadata as part of the format.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> * Representable as a tuple that has the DIType and the offset within the DIBlob as where to write the final relocation/offset for the reference at emission time.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">Why break up the types at all?<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> * To enable non-debug format aware linking and type uniquing for LTO that won’t be huge in size. We break up the types so we don’t need to parse debug information to link two modules together efficiently.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">Any other concerns there?<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> * Debug information without type units might be slightly larger in this scheme due to parents being duplicated (declarations and abstract origin, not full parents). It may be possible to extend dsymutil/etc to merge all siblings into a common parent. Open question for better ways to solve this.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">How should we handle DWARF5/Apple Accelerator Tables?<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> * Thoughts:<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> * We can parse the dwarf in the back end and generate them.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> * We can emit in the front end for the base case of non-LTO (with help from the backend for relocation aspects).<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> * We can use dsymutil on LTO debug information to generate them.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">Why isn’t this a more detailed spec?<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"> * Mostly because we’ve thought about the issues, but we can’t plan for everything during implementation.<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">Future work<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">----------------<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">Not contained as part of this, but an obvious future direction is that the Module linker could grow support for debug aware linking. Then we can have all of the type information for a single translation unit in a single blob and use the debug aware linking to handle merging types.<u class=""></u><u class=""></u></p></div></div></div></div></div></blockquote></div></div></div></div><br class="">_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class=""><br class=""></blockquote></div><br class=""></div></div><span id="cid:8E4EAB3E-E9C6-44CD-A241-E46124B75E9B@hsd1.ca.comcast.net." class=""><notypes.diff></span><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">_______________________________________________</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">LLVM Developers mailing list</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><a href="mailto:llvm-dev@lists.llvm.org" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">llvm-dev@lists.llvm.org</a><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></div></blockquote></div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">LLVM Developers mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:llvm-dev@lists.llvm.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">llvm-dev@lists.llvm.org</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></div></blockquote></div><br class=""></body></html>