hameeza ahmed via llvm-dev
2016-Dec-10 20:13 UTC
[llvm-dev] llvm-dev Digest, Vol 150, Issue 37
Thank you vivek pandya. I will try my best to do things as you mentioned. Regards Hameeza Ahmed On Sun, Dec 11, 2016 at 1:00 AM, via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Send llvm-dev mailing list submissions to > llvm-dev at lists.llvm.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > or, via email, send a message with subject or body 'help' to > llvm-dev-request at lists.llvm.org > > You can reach the person managing the list at > llvm-dev-owner at lists.llvm.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of llvm-dev digest..." > > > Today's Topics: > > 1. Re: LLVM possible projects (vivek pandya via llvm-dev) > 2. Re: RFC: Adding argument allocas (Hal Finkel via llvm-dev) > 3. Re: [cfe-dev] 3.9.1-rc3 has been tagged > (Renato Golin via llvm-dev) > 4. Re: RFC: Adding argument allocas (Hal Finkel via llvm-dev) > 5. Re: RFC: Adding argument allocas (Hal Finkel via llvm-dev) > 6. Re: RFC: Adding argument allocas (Hal Finkel via llvm-dev) > 7. Re: RFC: Adding argument allocas (Hal Finkel via llvm-dev) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 10 Dec 2016 13:50:38 +0530 > From: vivek pandya via llvm-dev <llvm-dev at lists.llvm.org> > To: llvm-dev <llvm-dev at lists.llvm.org>, > llvm-dev-request at lists.llvm.org > Subject: Re: [llvm-dev] LLVM possible projects > Message-ID: > <CAHYgpo+9R7pJuMGRgtQBbMahHPa=UmU1sZ4eR-DkTNCKcDyyKg at mail. > gmail.com> > Content-Type: text/plain; charset="utf-8" > > > Hello, > > Presently my research is focused on compiler and i found LLVM great tool > to > > work with. I want to familiarize it at undergraduate level. > > > > Hi Hameeza, > > I have face similar situation before and I would suggest you to read some > books/ blogs available on Internet for LLVM. > I think the best way to understand LLVM is by playing with it. > Then you should try doing some assignments based on LLVM from some good > universities. > For example : > https://utah.instructure.com/courses/377698/assignments/3299816 > > or > https://www.cs.cmu.edu/afs/cs/academic/class/15745-s09/www/ > assignments/1/P1.pdf > > or https://wiki.aalto.fi/display/t1065450/assignments+2015 > > almost all good universities have LLVM based course structure for Advance > compiler courses > > Could you suggest some good optimization and backend based LLVM projects at > > undergraduate level. > > > > Once you get enough experience then you can contact some community member > on IRC asking some task which is yet to be done but because of busy > schedule LLVM-Dev are not able to work on it. > > Also as you are student I will encourage you to participate in Google > Summer of Code 2017. > > Hope this helps! > > - Vivek > > > Thankyou > > > > Regards > > Hameeza Ahmed > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.llvm.org/pipermail/llvm-dev/ > attachments/20161210/bb0f1ca8/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Sat, 10 Dec 2016 09:01:38 -0600 > From: Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> > To: James Y Knight <jyknight at google.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] RFC: Adding argument allocas > Message-ID: > <593911.506.1481382095370.JavaMail.hfinkel at sapling5.localdomain> > Content-Type: text/plain; charset="utf-8" > > ----- Original Message ----- > > > From: "James Y Knight via llvm-dev" <llvm-dev at lists.llvm.org> > > To: "Eli Friedman" <efriedma at codeaurora.org> > > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > > Sent: Friday, December 9, 2016 6:04:18 PM > > Subject: Re: [llvm-dev] RFC: Adding argument allocas > > > On Fri, Dec 9, 2016 at 1:30 PM, Friedman, Eli via llvm-dev < > > llvm-dev at lists.llvm.org > wrote: > > > > On 12/9/2016 8:45 AM, Reid Kleckner wrote: > > > > > > > On Thu, Dec 8, 2016 at 5:37 PM, Mehdi Amini < > > > > mehdi.amini at apple.com > > > > > > > > > wrote: > > > > > > > > > > > So IIUC basically the *only* reason for this IR change is that > > > > > we > > > > > don’t want to pattern match in debug build? > > > > > > > > > > > > > > I don't understand right now why we wouldn’t want to do this? > > > > > > > > > > > > > If we need to pattern match such a basic construct, it suggests > > > > to > > > > me > > > > that we have the wrong representation, and we should instead make > > > > our representation more accurately model reality. To me, it feels > > > > like this representation allows several good things to just "fall > > > > out" without any additional work, and that suggests it's a good > > > > representation. > > > > > > > > Mmm... maybe. The part I really don't like is the implied store: > > > there are a lot of transformations which specifically reason about > > > store instructions, and they would all need to be fixed to > > > specifically deal with "alloca with an argument" so it doesn't > > > block > > > optimizations. Every feature we add to the IR makes it more > > > difficult to write IR transformations, and this really doesn't seem > > > to carry its own weight. > > > > > > A couple of other thoughts I had: > > > > > 1. We could use metadata, e.g. "%px = alloca i32, align 4 !argument > > > !i32 %x", followed by a store. There's still a little > > > pattern-matching involved because the metadata is only a hint, but > > > the intent in the IR is more explicit. > > > > > 2. We could change the way clang generates function definitions: > > > instead of "define void @f(i32 %x)", generate "define void @f(i32* > > > byval %px)" if the value is going to end up on the stack. This > > > should work without any changes to the IR. This is a bad idea if > > > we're trying to run optimizations because it obscures data flow, > > > but > > > it seems reasonable at -O0. > > > > IMO, the LLVM function definitions should be a straightforward > > transformation from the C function signatures, and clang should stop > > mangling the function signatures with its own intimate knowledge of > > the calling convention rules. > > > Instead, clang could emit (still ABI-specific!) annotations on the > > arguments that communicates the *properties* of the source-language > > types which affect the ABI. LLVM, then, would use that information > > to implement the complete calling convention. No counting of numbers > > of registers in Clang to put "inreg" markers in the right places, or > > byval, or any of that sort of stuff it has to do today. > > > For example, on x86-64 SysV ABI, a complex classification algorithm > > is run over the fields in an aggregate, to classify each eightbyte > > quantity into one of several classes (MEMORY, INTEGER, SSE, etc). > > That must run on the clang side, using source types, but it could > > send the direct result of the classification to llvm, rather than > > using it to mangle the prototype of the function in a secret > > undocumented handshake using the few > > seemingly-but-not-really-generic attributes that are available now. > If we implement a system which worked like this, that would be > spectacular! :-) The fact that so much of our ABI knowledge is locked up in > Clang is fragile, causes difficulties with implementing other frontends, > etc. > > -Hal > > > For that reason, I really don't like the second option you mention > > above, as it requires clang to know more about exactly what the > > calling convention decisions made by llvm are going to be. > > > Actually, I think byval should be deleted entirely. If you want to > > pass by value...then, pass by value... > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > -- > > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Computing Facility > Argonne National Laboratory > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.llvm.org/pipermail/llvm-dev/ > attachments/20161210/37805fcc/attachment-0001.html> > > ------------------------------ > > Message: 3 > Date: Sat, 10 Dec 2016 15:10:21 +0000 > From: Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> > To: Tom Stellard <tom at stellard.net> > Cc: LLVM Dev <llvm-dev at lists.llvm.org>, Release-testers > <release-testers at lists.llvm.org>, Clang Dev < > cfe-dev at lists.llvm.org> > Subject: Re: [llvm-dev] [cfe-dev] 3.9.1-rc3 has been tagged > Message-ID: > <CAMSE1keh5qu1F1U0o-LY_XaKNG6QWrUFOhWtQiV=6YDg5BxqyA@ > mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 10 December 2016 at 00:48, Tom Stellard via cfe-dev > <cfe-dev at lists.llvm.org> wrote: > > I have tagged 3.9.1-rc3. The only differences from -rc2 were a few > > bug fixes for ARM/AARCH64, so if you aren't testing either of these > > I think it's safe to take this -rc off and what for -final. > > > > I'm hoping to do -final next week after I get the ARM test results. > > I'm on it. > > cheers, > --renato > > > ------------------------------ > > Message: 4 > Date: Sat, 10 Dec 2016 09:28:50 -0600 > From: Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> > To: Eli Friedman <efriedma at codeaurora.org> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] RFC: Adding argument allocas > Message-ID: > <11002675.584.1481383726680.JavaMail.hfinkel at sapling5.localdomain> > Content-Type: text/plain; charset="utf-8" > > ----- Original Message ----- > > > From: "Eli via llvm-dev Friedman" <llvm-dev at lists.llvm.org> > > To: "Reid Kleckner" <rnk at google.com> > > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > > Sent: Friday, December 9, 2016 2:21:57 PM > > Subject: Re: [llvm-dev] RFC: Adding argument allocas > > > On 12/9/2016 11:49 AM, Reid Kleckner wrote: > > > > On Fri, Dec 9, 2016 at 10:30 AM, Friedman, Eli < > > > efriedma at codeaurora.org > wrote: > > > > > > > Mmm... maybe. The part I really don't like is the implied store: > > > > there are a lot of transformations which specifically reason > > > > about > > > > store instructions, and they would all need to be fixed to > > > > specifically deal with "alloca with an argument" so it doesn't > > > > block > > > > optimizations. Every feature we add to the IR makes it more > > > > difficult to write IR transformations, and this really doesn't > > > > seem > > > > to carry its own weight. > > > > > > > > I don't feel like it complicates our model that much, though. > > > Passes > > > already have to know that uninitialized allocas contain undef, and > > > with this change they can contain a value. That doesn't seem very > > > surprising. It is a fair point that we'd have to add new cases to > > > code like llvm::FindAvailableLoadedValue, which looks for StoreInst > > > but not AllocaInst. > > > > It's more that that... I mean, obviously you have to fix all the > > places which assume allocas start off containing undef, but you're > > also introducing the potential for missed optimizations by making > > the store implicit. For example, consider: > > > void g(int *x); > > __attribute((noinline)) void f(int y) { > > y = 10; > > g(&y); > > } > > void h() { f(134314); } > > > The argument to f is dead; there are two stores to y, and instcombine > > will eliminate the first one. With extended allocas, we need a new > > form of dead store elimination which transforms "alloca i32, > > argument %x" -> "alloca i32". > > This is a good point, but it does not seem complicated to implement. > > -Hal > > > > > 2. We could change the way clang generates function definitions: > > > > instead of "define void @f(i32 %x)", generate "define void > > > > @f(i32* > > > > byval %px)" if the value is going to end up on the stack. This > > > > should work without any changes to the IR. This is a bad idea if > > > > we're trying to run optimizations because it obscures data flow, > > > > but > > > > it seems reasonable at -O0. > > > > > > > > This is problematic because it would break out "bitcode ABI" > > > between > > > optimized and debug builds. We've had problems in the past when the > > > caller and callee disagree on whether an argument is a byval > > > pointer > > > or not, and instcombine will come along and try to simplify the > > > casts: https://llvm.org/bugs/show_bug.cgi?id=21573 > > > > If instcombine is breaking this somehow, it's a bug; we're not > > supposed to eliminate bitcasts unless we can prove the signatures > > are equivalent. Granted, this is a complicated transform which has > > had a lot of bugs in the past. > > > -Eli > > -- > > Employee of Qualcomm Innovation Center, Inc. > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > > Linux Foundation Collaborative Project > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > -- > > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Computing Facility > Argonne National Laboratory > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.llvm.org/pipermail/llvm-dev/ > attachments/20161210/4a69a971/attachment-0001.html> > > ------------------------------ > > Message: 5 > Date: Sat, 10 Dec 2016 09:32:20 -0600 > From: Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> > To: Eli Friedman <efriedma at codeaurora.org> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] RFC: Adding argument allocas > Message-ID: > <10804386.590.1481383940297.JavaMail.hfinkel at sapling5.localdomain> > Content-Type: text/plain; charset="utf-8" > > ----- Original Message ----- > > > From: "Eli via llvm-dev Friedman" <llvm-dev at lists.llvm.org> > > To: "Reid Kleckner" <rnk at google.com> > > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > > Sent: Friday, December 9, 2016 12:30:34 PM > > Subject: Re: [llvm-dev] RFC: Adding argument allocas > > > On 12/9/2016 8:45 AM, Reid Kleckner wrote: > > > > On Thu, Dec 8, 2016 at 5:37 PM, Mehdi Amini < mehdi.amini at apple.com > > > > > > > wrote: > > > > > > > So IIUC basically the *only* reason for this IR change is that we > > > > don’t want to pattern match in debug build? > > > > > > > > > I don't understand right now why we wouldn’t want to do this? > > > > > > > > If we need to pattern match such a basic construct, it suggests to > > > me > > > that we have the wrong representation, and we should instead make > > > our representation more accurately model reality. To me, it feels > > > like this representation allows several good things to just "fall > > > out" without any additional work, and that suggests it's a good > > > representation. > > > > Mmm... maybe. The part I really don't like is the implied store: > > there are a lot of transformations which specifically reason about > > store instructions, and they would all need to be fixed to > > specifically deal with "alloca with an argument" so it doesn't block > > optimizations. > I'm not sure this is true. The instruction does write to memory, at least > formally, but by definition the address of the alloca cannot yet have been > used by anything else, and so no other memory access can alias with it. The > write also can't trap. The alloca, as a result, does not even need to be > tagged as writing to memory. > > -Hal > > > Every feature we add to the IR makes it more difficult to write IR > > transformations, and this really doesn't seem to carry its own > > weight. > > > A couple of other thoughts I had: > > 1. We could use metadata, e.g. "%px = alloca i32, align 4 !argument > > !i32 %x", followed by a store. There's still a little > > pattern-matching involved because the metadata is only a hint, but > > the intent in the IR is more explicit. > > 2. We could change the way clang generates function definitions: > > instead of "define void @f(i32 %x)", generate "define void @f(i32* > > byval %px)" if the value is going to end up on the stack. This > > should work without any changes to the IR. This is a bad idea if > > we're trying to run optimizations because it obscures data flow, but > > it seems reasonable at -O0. > > > -Eli > > -- > > Employee of Qualcomm Innovation Center, Inc. > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > > Linux Foundation Collaborative Project > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > -- > > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Computing Facility > Argonne National Laboratory > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.llvm.org/pipermail/llvm-dev/ > attachments/20161210/53c5436d/attachment-0001.html> > > ------------------------------ > > Message: 6 > Date: Sat, 10 Dec 2016 10:00:23 -0600 > From: Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> > To: Eli Friedman <efriedma at codeaurora.org> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] RFC: Adding argument allocas > Message-ID: > <20259972.609.1481385620617.JavaMail.hfinkel at sapling5.localdomain> > Content-Type: text/plain; charset="utf-8" > > ----- Original Message ----- > > From: "Eli via llvm-dev Friedman" <llvm-dev at lists.llvm.org> > > To: "Reid Kleckner" <rnk at google.com>, "llvm-dev" < > llvm-dev at lists.llvm.org> > > Sent: Thursday, December 8, 2016 7:47:28 PM > > Subject: Re: [llvm-dev] RFC: Adding argument allocas > > > > On 12/8/2016 5:05 PM, Reid Kleckner via llvm-dev wrote: > > > If the semantics are the same, it begs the question, why don’t we > > > pattern match the alloca and store to elide dead stores and reuse > > > existing argument stack slots? My main preference for adding a new > > > way > > > to do this is that it gives us simpler and smaller code in debug > > > builds, where we presumably don’t want to do this kind of pattern > > > recognition. My experience with our -O0 codegen is that we do a lot > > > of > > > useless copies to initialize parameters, and this leads to larger > > > output size, which slows things down. Having a more easily > > > recognizable idiom for getting the storage behind parameters if it > > > exists feels like a win. > > > > Why don't we want to do this kind of pattern recognition at -O0? We > > can > > do a fast scan which just looks at the entry block if you're > > concerned > > about compile-time. > > > > > One other questionable side benefit of doing this is that it would > > > make it possible to implement va_start by taking the address of a > > > parameter and doing pointer arithmetic. While that code is fairly > > > invalid, it’s exactly what the MSVC STL headers do for 32-bit x86. > > > If > > > we make this work in Clang, we can remove our stdarg.h and vadefs.h > > > wrapper headers. Users often pass flags that cause clang to skip > > > these > > > wrapper headers, and then they file bugs complaining that va lists > > > don't work. > > > > This ignores the other reason why this doesn't work at the moment: > > reading off the end of an alloca returns undef, whether or not the > > actual pointer value points at the data you want. I mean, it's not > > impossible to make it work, but it involves a bunch of unrelated > > changes > > which I don't think we want to pursue. > > I agree. Making reading past the end of an alloca defined behavior seems > undesirable. > > -Hal > > > > > -Eli > > > > -- > > Employee of Qualcomm Innovation Center, Inc. > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > > Linux Foundation Collaborative Project > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > -- > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Computing Facility > Argonne National Laboratory > > > ------------------------------ > > Message: 7 > Date: Sat, 10 Dec 2016 10:20:00 -0600 > From: Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> > To: Reid Kleckner <rnk at google.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] RFC: Adding argument allocas > Message-ID: > <6867190.632.1481386796505.JavaMail.hfinkel at sapling5.localdomain> > Content-Type: text/plain; charset="utf-8" > > ----- Original Message ----- > > > From: "Reid Kleckner via llvm-dev" <llvm-dev at lists.llvm.org> > > To: "llvm-dev" <llvm-dev at lists.llvm.org> > > Sent: Thursday, December 8, 2016 7:05:44 PM > > Subject: [llvm-dev] RFC: Adding argument allocas > > > Clang is currently missing some low-hanging performance and code size > > opportunities when receiving function parameters. For most scalar > > parameters, Clang typically emits an alloca and stores the LLVM SSA > > argument value into the alloca to initialize it. With optimizations, > > this initialization is often removed, but it stays behind in debug > > builds and when the user takes the address of a parameter ( > > https://llvm.org/bugs/show_bug.cgi?id=26328 ). In many cases, the > > memory allocation and store duplicate work already done by the > > caller. > > > Case 1: The parameter is already being passed in memory. In this > > case, we waste memory and do an extra load and store to copy it into > > our own alloca. This is very common on 32-bit x86. > > > Case 2: On Win64, the caller pre-allocates shadow stack slots for all > > register parameters. This allows the callee to “home” register > > parameters to ease debugging and the implementation of variadic > > functions. In this case, the store is not dead, but we fail to use > > the pre-allocated memory. > > > Case 3: The parameter is a register parameter in a normal Sys-V ABI. > > In this case, nothing is wasted. Both the memory and store are > > needed. > > > I think we can improve our code for cases 1 and 2 by making it > > possible to create allocas from parameters, and we can lower this > > down to a regular stack object with a store in case 3. The syntax > > for this would look like: > > define void @f(i32 %x) { > > %px = alloca i32, argument i32 %x, align 4 > > > The semantics are the same as the following: > > define void @f(i32 %x) { > > > %px = alloca i32, align 4 > > store i32 %x, i32* %px, align 4 > > > It is invalid to make one of these argument allocas dynamic in any > > way, either by using inalloca, using a dynamic element count, or > > being outside the entry block. > > Having an alloca with an initializer seems like a reasonable enhancement. > Please, however, without all of these special restrictions: any value > should be accepted on any alloca. We can match the special argument cases > in the backend and otherwise lower to the equivalent of an alloca+store. > > -Hal > > > If the semantics are the same, it begs the question, why don’t we > > pattern match the alloca and store to elide dead stores and reuse > > existing argument stack slots? My main preference for adding a new > > way to do this is that it gives us simpler and smaller code in debug > > builds, where we presumably don’t want to do this kind of pattern > > recognition. My experience with our -O0 codegen is that we do a lot > > of useless copies to initialize parameters, and this leads to larger > > output size, which slows things down. Having a more easily > > recognizable idiom for getting the storage behind parameters if it > > exists feels like a win. > > > Changing the semantics of alloca affects a lot of things, but I think > > it makes sense to extend alloca here rather than a new intrinsic or > > instruction that can create local variable stack memory that passes > > would have to reason about. Here’s a list of things we’d need to > > change off the top of my head: > > 1. Inliner: When hoisting static allocas to the entry block, the > > inliner will now strip the argument operand off of allocas and > > insert the equivalent store at the inlined call site. > > 2. Mem2reg: Loading from an argument alloca needs to produce the > > argument value instead of undef. > > 3. GVN: We need to apply the same logic to GVN and similar store to > > load forwarding transforms. > > 4. Instcombine: This transform has some simple store forwarding logic > > that would need to be updated. > > > I’m sure there are more, but the changes seem worth it to get at > > these low hanging opportunities. > > > One other questionable side benefit of doing this is that it would > > make it possible to implement va_start by taking the address of a > > parameter and doing pointer arithmetic. While that code is fairly > > invalid, it’s exactly what the MSVC STL headers do for 32-bit x86. > > If we make this work in Clang, we can remove our stdarg.h and > > vadefs.h wrapper headers. Users often pass flags that cause clang to > > skip these wrapper headers, and then they file bugs complaining that > > va lists don't work. > > > At the end of the day, this feels like a straightforward engineering > > improvement to LLVM, and it feels worth doing to me. Does anyone > > feel otherwise or have any suggestions? > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > -- > > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Computing Facility > Argonne National Laboratory > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.llvm.org/pipermail/llvm-dev/ > attachments/20161210/e56670a8/attachment-0001.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > llvm-dev mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > ------------------------------ > > End of llvm-dev Digest, Vol 150, Issue 37 > ***************************************** >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161211/3c672cf8/attachment.html>
Apparently Analagous Threads
Wisdom of the Ancients
