<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="">FWIW, I ran SPEC2006 on ARM64 and didn’t observe any performance changes beyond the noise level.<div class=""><br class=""><div class="">The configuration was O3/PGO/LTO. ‘Reference' compiler was trunk r242173, ‘experimental’ compiler was the same compiler with commented out line<div class=""><font face="Menlo" class="">PM.add(createGlobalsModRefPass()); // IP alias analysis.</font></div><div class="">in file lib/Transforms/IPO/PassManagerBuilder.cpp</div><div class=""><br class=""></div><div class="">Michael<br class=""><div><blockquote type="cite" class=""><div class="">On Jul 17, 2015, at 9:27 AM, Xinliang David Li <<a href="mailto:xinliangli@gmail.com" class="">xinliangli@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">The common way is to use AliasEvaluator pass and dump alias results of all possible queries. This can be expensive. For ModRef result, it is probably simpler to just modify GlobalModRef::alias method to emit traces of noalias queries -- use the helper method: PrintResults from AliasAnalysisEvaluator.cpp<div class=""><br class=""></div><div class="">David</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jul 17, 2015 at 9:08 AM, Evgeny Astigeevich <span dir="ltr" class=""><<a href="mailto:evgeny.astigeevich@arm.com" target="_blank" class="">evgeny.astigeevich@arm.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple" class=""><div class=""><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">Hi David,<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">I can check this. How can I do this?<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">Kind regards,<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">Evgeny Astigeevich<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><b class=""><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class="">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class=""> Xinliang David Li [mailto:<a href="mailto:xinliangli@gmail.com" target="_blank" class="">xinliangli@gmail.com</a>] <br class=""><b class="">Sent:</b> 17 July 2015 16:53<br class=""><b class="">To:</b> Evgeny Astigeevich<br class=""><b class="">Cc:</b> Chandler Carruth; LLVM Developers Mailing List</span></p><div class=""><div class="h5"><br class=""><b class="">Subject:</b> Re: [LLVMdev] GlobalsModRef (and thus LTO) is completely broken<u class=""></u><u class=""></u></div></div><div class=""><br class="webkit-block-placeholder"></div><div class=""><div class="h5"><p class="MsoNormal"><u class=""></u> <u class=""></u></p><div class=""><p class="MsoNormal">Before the fix, the compiler may simply return 'noalias' for cases it can not really prove to be noalias, but actually correct by luck (or even wrong noalias, but does not result in miscompile). It would be useful to find out the set of missed noalias queries from GlobalModRef with your benchmark and examine if there is some improvement can be done.<u class=""></u><u class=""></u></p><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div><div class=""><p class="MsoNormal">David<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div></div><div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p><div class=""><p class="MsoNormal">On Fri, Jul 17, 2015 at 6:32 AM, Evgeny Astigeevich <<a href="mailto:Evgeny.Astigeevich@arm.com" target="_blank" class="">Evgeny.Astigeevich@arm.com</a>> wrote:<u class=""></u><u class=""></u></p><div class=""><div class=""><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">Yes, the regression is stable. I double checked this. A full benchmark run consists of at least 10 sub-runs to validate the score.</span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">I also checked if there were regressions of this benchmark across different ARM hardware versions. I found all regressions of this benchmark were in range 1.6%-2%.</span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class=""> </span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">Kind regards,</span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">Evgeny Astigeevich</span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class=""> </span><u class=""></u><u class=""></u></p><p class="MsoNormal"><b class=""><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class="">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class=""> Chandler Carruth [mailto:<a href="mailto:chandlerc@gmail.com" target="_blank" class="">chandlerc@gmail.com</a>] <br class=""><b class="">Sent:</b> 17 July 2015 07:52<br class=""><b class="">To:</b> Evgeny Astigeevich; Chandler Carruth<br class=""><b class="">Cc:</b> LLVM Developers Mailing List; Michael Zolotukhin</span><u class=""></u><u class=""></u></p><div class=""><div class=""><p class="MsoNormal"><br class=""><b class="">Subject:</b> Re: [LLVMdev] GlobalsModRef (and thus LTO) is completely broken<u class=""></u><u class=""></u></p></div></div><div class=""><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p><div class=""><p class="MsoNormal">Hey, thanks for benchmarking.<u class=""></u><u class=""></u></p><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">How stable is the 2% regression?<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">Michael ran some benchmarks with GlobalsModRef completely disabled and the only differences were in the noise. This was a complete spec2k6 run along with some others. Based on the number of benchmarks run there, I'm going to go ahead and submit these patches, but if you can clarify the impact here, we can look at potentially some other tradeoff. I'm not particularly set on one set of defaults, etc, I just don't want to keep patches held up based on that. We can flip the default back and forth as new data arrives.<u class=""></u><u class=""></u></p></div><p class="MsoNormal"> <u class=""></u><u class=""></u></p><div class=""><div class=""><p class="MsoNormal">On Thu, Jul 16, 2015 at 12:23 PM Evgeny Astigeevich <<a href="mailto:evgeny.astigeevich@arm.com" target="_blank" class="">evgeny.astigeevich@arm.com</a>> wrote:<u class=""></u><u class=""></u></p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt" class=""><div class=""><div class=""><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">Hi Chandler,</span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class=""> </span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">I ran couple benchmarks with LTO turned on and your patches on ARM hardware.</span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">There were no performance degradation of one benchmark and 2% slowdown of another benchmark.</span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class=""> </span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">Kind regards,</span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">Evgeny Astigeevich</span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class=""> </span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class=""> </span><u class=""></u><u class=""></u></p><div class=""><div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm" class=""><p class="MsoNormal"><b class=""><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class="">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class=""> <a href="mailto:llvmdev-bounces@cs.uiuc.edu" target="_blank" class="">llvmdev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:llvmdev-bounces@cs.uiuc.edu" target="_blank" class="">llvmdev-bounces@cs.uiuc.edu</a>] <b class="">On Behalf Of </b>Evgeny Astigeevich<br class=""><b class="">Sent:</b> 15 July 2015 15:12</span><u class=""></u><u class=""></u></p></div></div></div></div><div class=""><div class=""><div class=""><div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm" class=""><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class=""><br class=""><b class="">To:</b> 'Chandler Carruth'; Gerolf Hoflehner<br class=""><b class="">Cc:</b> LLVM Developers Mailing List<br class=""><b class="">Subject:</b> Re: [LLVMdev] GlobalsModRef (and thus LTO) is completely broken</span><u class=""></u><u class=""></u></p></div></div></div></div><div class=""><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">Hi Chandler,</span><u class=""></u><u class=""></u></p></div></div><div class=""><div class=""><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class=""> </span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">I would like to run some benchmarks on ARM hardware and to look at impact of your patches on LTO.</span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class=""> </span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">Kind regards,</span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">Evgeny Astigeevich</span><u class=""></u><u class=""></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class=""> </span><u class=""></u><u class=""></u></p></div></div><div class=""><div class=""><p class="MsoNormal"><b class=""><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class="">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class=""> <a href="mailto:llvmdev-bounces@cs.uiuc.edu" target="_blank" class="">llvmdev-bounces@cs.uiuc.edu</a> [<a href="mailto:llvmdev-bounces@cs.uiuc.edu" target="_blank" class="">mailto:llvmdev-bounces@cs.uiuc.edu</a>] <b class="">On Behalf Of </b>Chandler Carruth</span><u class=""></u><u class=""></u></p></div></div><div class=""><div class=""><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class=""><br class=""><b class="">Sent:</b> 15 July 2015 10:45<br class=""><b class="">To:</b> Chandler Carruth; Gerolf Hoflehner<br class=""><b class="">Cc:</b> LLVM Developers Mailing List<br class=""><b class="">Subject:</b> Re: [LLVMdev] GlobalsModRef (and thus LTO) is completely broken</span><u class=""></u><u class=""></u></p></div></div><div class=""><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p><div class=""><div class=""><p class="MsoNormal">I've fixed the obvious bugs I spotted in r242281. These should be pure correctness improvements.<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">I've sent the two patches I'm imagining to address the core issue here:<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11213&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=TDTMPyN-BRKio_S9jhFxP6vHW7gAN3F73DTvS3M46go&s=TjLIFmohippEitr9aFYFcADeLJeQ-z2E_LH0fpsL38Q&e=" target="_blank" class="">http://reviews.llvm.org/D11213</a><u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal"><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11214&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=TDTMPyN-BRKio_S9jhFxP6vHW7gAN3F73DTvS3M46go&s=z8Wdu7ZruKrV5dqBOmaBxWe1aaiDWtf4it9ZI1dVweQ&e=" target="_blank" class="">http://reviews.llvm.org/D11214</a><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, I have the unsafe alias results disabled by default, but with a flag that can re-enable them if needed. I don't feel really strongly about which way the default is set -- but that may be because I don't have lots of users relying on LTO. I'll let others indicate which way they would be most comfortable.<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">Some IRC conversations indicated that early benchmark results with GMR completely disabled weren't showing really significant swings, so maybe this relatively small reduction in power of GMR won't be too problematic for folks. Either way, I'm open to the different approaches. It's D11214 that I care a lot about. =]<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">Thanks for all the thoughts here!<u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">-Chandler<u class=""></u><u class=""></u></p></div></div><p class="MsoNormal"> <u class=""></u><u class=""></u></p><div class=""><div class=""><p class="MsoNormal">On Tue, Jul 14, 2015 at 11:25 PM Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank" class="">chandlerc@gmail.com</a>> wrote:<u class=""></u><u class=""></u></p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt" class=""><div class=""><p class="MsoNormal">Replying here, but several of the questions raised boil down to "couldn't you make the usage of GetUnderlyingObject conservatively correct?". I'll try and address that.<u class=""></u><u class=""></u></p><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p></div><div class=""><p class="MsoNormal">I think this *is* the right approach, but I think it is very hard to do without effectively disabling this part of GlobalsModRef. That is, the easy ways are likely to fire very frequently IMO.<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 core idea is to detect a "no information" state coming out of GetUnderlyingObject (likely be providing a custom version just for GlobalsModRef and tailored to its use cases). This is particularly effective at avoiding the problems with the recursion limit. But let's look at what cases we *wouldn't* return that. Here are the cases I see when I thought about this last night with Hal, roughly in descending likelihood I would guess:<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) We detect some global or an alloca. In that case, even BasicAA would be sufficient to provide no-alias. GMR shouldn't be relevant.<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">2) We detect a phi, select, or inttoptr, and stop there.<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">3) We detect a load and stop there.<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">4) We detect a return from a function.<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">5) We detect an argument to the function.<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">I strongly suspect the vast majority of queries hit #1. That's why BasicAA is *so* effective. Both #4 and #5 I think are actually reasonable places for GMR to potentially say "no-alias" and provide useful definitive information. But I also suspect these are the least common.<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">So let's look at #2 and #3 because I think they're interesting. For these, I think it is extremely hard to return "no-alias". It seems extremely easy for a reasonable and innocuous change to the IR to introduce a phi or a select into one side of the GetUnderlyingObject but not the other. If that ever happens, we can't return "no-alias" for #2, or we need to add really expensive updates. It also seems reasonable (if not as likely) to want adding a store and load to the IR to not trigger a miscompile. If it is possible for a valid optimization pass to do reg2mem on an SSA value, then that could happen to only one side of the paired GetUnderlyingObject and break GMR with #3. If that seems like an unreasonable thing to do, consider loop re-rolling or other transformations which may need to take things in SSA form at move them out of SSA form. Even if we then try immediately to put it back *into* SSA form, before we do that we create a point where GMR cannot correctly return no-alias.<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">So ultimately, I don't think we want to rely on GMR returning "no-alias" for either #2 or #3 because of the challenge of actually updating it in all of the circumstances that could break them. That means that *only* #4 and #5 are going to return "no-alias" usefully. And even then, function inlining and function outlining both break #4 and #5, so you have to preclude those transforms while GMR is active. And I have serious doubts about these providing enough value to be worth the cost.<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">I think the better way to approach this is the other way around. Rather than doing a backwards analysis to see if one location reaches and global and the other location doesn't reach a global, I think it would be much more effective to re-cast this as a forward analysis that determines all the memory locations in a function that come from outside the function, and use that to drive the no-alias responses.<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><div class=""><div class=""><div class=""><div class=""><p class="MsoNormal">On Tue, Jul 14, 2015 at 12:12 PM Gerolf Hoflehner <<a href="mailto:ghoflehner@apple.com" target="_blank" class="">ghoflehner@apple.com</a>> wrote:<u class=""></u><u class=""></u></p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt" class=""><div class=""><div class=""><p class="MsoNormal">I wouldn’t be willing to give up performance for hypothetical issues. Please protect all your changes with options. For some of your concerns it is probably hard to provide a test case that shows an/the actual issue.<u class=""></u><u class=""></u></p></div></div></blockquote><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p></div></div></div></div><div class=""><div class=""><div class=""><div class=""><p class="MsoNormal">I certainly agree that it will be very hard to provide a test case and extremely rare to see this in the wild for most of these issues. As long as I can remove the problematic update API we currently have (which as its an API change can't really be put behind flags), I'm happy to have flags control whether or not GMR uses the unsound / stale information to try to answer alias queries. Do you have any opinion about what the default value of the flags should be?<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">I'll go ahead and prepare the patches, as it seems like we're all ending up in the same position, and just wondering about the precise tradeoffs we want to settle on.<u class=""></u><u class=""></u></p></div></div></div></div><div class=""><div class=""><div class=""><div class=""><p class="MsoNormal"> <u class=""></u><u class=""></u></p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt" class=""><div class=""><div class=""><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt" class=""><div class=""><p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"" class="">_______________________________________________<br class="">LLVM Developers mailing list</span><u class=""></u><u class=""></u></p></div></blockquote></div></div><div class=""><div class=""><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt" class=""><div class=""><p class="MsoNormal"><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank" class=""><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"" class="">LLVMdev@cs.uiuc.edu</span></a><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"" class=""> </span><a href="http://llvm.cs.uiuc.edu/" target="_blank" class=""><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"" class="">http://llvm.cs.uiuc.edu</span></a><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"" class=""><br class=""></span><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class=""><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</span></a><u class=""></u><u class=""></u></p></div></blockquote></div><p class="MsoNormal"> <u class=""></u><u class=""></u></p></div><p class="MsoNormal">_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank" class="">http://llvm.cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><u class=""></u><u class=""></u></p></blockquote></div></div></div></blockquote></div></div></div><p class="MsoNormal">_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank" class="">http://llvm.cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><u class=""></u><u class=""></u></p></blockquote></div></div></div></div></div></div><p class="MsoNormal" style="margin-bottom:12.0pt">_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank" class="">http://llvm.cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><u class=""></u><u class=""></u></p></div><p class="MsoNormal"><u class=""></u> <u class=""></u></p></div></div></div></div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:LLVMdev@cs.uiuc.edu" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" class="">http://llvm.cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br class=""></div></blockquote></div><br class=""></div></div></div></body></html>