Asiri Rathnayake via llvm-dev
2017-Apr-25 20:37 UTC
[llvm-dev] RFC: Improving the performance of ItaniumDemangle
On Tue, Apr 25, 2017 at 8:36 PM, Vedant Kumar via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > > On Apr 25, 2017, at 12:24 PM, Scott Smith <scott.smith at purestorage.com> > wrote: > > > > well, top-of-branch lldb uses this code, that's how I found it. Do you > mean libc++'s demangler? > > Thanks for explaining, this is the first time I'm looking at the demangler > situation. It looks like libcxxabi has an arena-based demangler, and that > the one in llvm is different. > > I'm confused by this because the comment in llvm says that libcxxabi is > supposed to reuse the llvm demangler. This doesn't seem to be happening, > right? >This seems correct. libcxxabi demangler [1] is different from the one used by llvm [2]. I'm hoping Saleem, Eric or Jon (copied) knows a bit of history as to why this is so (perhaps because the two projects evolved independently ?).> > > FYI when I said 14+% (and now it's 17%), I mean the overall performance > of starting lldb, not just the demangler itself. It's probably several > times faster now with this change (https://reviews.llvm.org/D32500) > > Do you know what the llvm policy is on using TLS in library code? I can't > find any mention of this in the programmer's manual, and my officemates > don't know either. >Both libcxx and libcxxabi use __libcpp_tls_*() functions of the threading API [2] (which call pthread functions on most platforms) for thread-local storage needs. IIRC thread_local is not implemented across all the platforms that llvm support. If the idea is to improve libcxxabi's demangler, then it should be straightforward to use these functions instead of thread_local. [1] https://github.com/llvm-mirror/libcxxabi/blob/master/ src/cxa_demangle.cpp [2] https://github.com/llvm-mirror/llvm/blob/master/lib/Demangle/ItaniumDemangle.cpp [3] https://github.com/llvm-mirror/libcxx/blob/master/ include/__threading_support PS: Here's a particularly amusing bug of the current libcxxabi demangler: https://bugs.llvm.org//show_bug.cgi?id=31031 Cheers, / Asiri> > vedant > > > > On Tue, Apr 25, 2017 at 12:19 PM, Vedant Kumar <vsk at apple.com> wrote: > > I thought the plan of record was (r280732): > > > > ''' > > Once the fast demangler in lldb can handle any names this > > implementation can be replaced with it and we will have the one true > > demangler. > > ''' > > > > What is the status of lldb's fast demangler? Is it available on Ubuntu > 16.04? > > > > vedant > > > > > > > On Apr 24, 2017, at 6:02 PM, Scott Smith via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > > > (Again), while trying to improve the performance of lldb, I ran into a > bottleneck with the demangler. This may be specific to my platform - > Ubuntu 16.04, probably using libstdc++, not libc++. It makes extensive use > of std::string and std::vector, and I see memory allocation at the top. I > prototyped a version that uses an arena-style memory allocator (you can > allocate, but you can't ever free). It is approximately 14+% faster. I > think I can further optimize it by making repeated appends zero-copy (for > the string being appended too). > > > > > > The code right now is a little ugly, because it uses a thread local > variable to pass around the arena pointer, rather than change every + and > += to be function calls that take db.arena as a parameter. I'm not sure > what you guys would prefer for that either (thread local variable vs api > change). > > > > > > _______________________________________________ > > > LLVM Developers mailing list > > > llvm-dev at lists.llvm.org > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170425/48cc375e/attachment.html>
Jonathan Roelofs via llvm-dev
2017-Apr-25 20:51 UTC
[llvm-dev] RFC: Improving the performance of ItaniumDemangle
On 4/25/17 2:37 PM, Asiri Rathnayake wrote:> > > On Tue, Apr 25, 2017 at 8:36 PM, Vedant Kumar via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > On Apr 25, 2017, at 12:24 PM, Scott Smith > <scott.smith at purestorage.com <mailto:scott.smith at purestorage.com>> > wrote: > > > > well, top-of-branch lldb uses this code, that's how I found it. > Do you mean libc++'s demangler? > > Thanks for explaining, this is the first time I'm looking at the > demangler situation. It looks like libcxxabi has an arena-based > demangler, and that the one in llvm is different. > > I'm confused by this because the comment in llvm says that > libcxxabi is supposed to reuse the llvm demangler. This doesn't > seem to be happening, right? > > > This seems correct. libcxxabi demangler [1] is different from the one > used by llvm [2]. I'm hoping Saleem, Eric or Jon (copied) knows a bit > of history as to why this is so (perhaps because the two projects > evolved independently ?).A copy of the libcxxabi one was added to libSupport relatively recently so that lldb could use it.... so they should be almost the same. lldb has its own because it has different constraints w.r.t. memory allocation and speed compared to the __cxa_* one. (I don't know much about the details there though). If falls back on the __cxa_* implementation for some cases where the "fast" one's implementation is incomplete (again, repeating what I remember... I don't know the details). Jon> > > > > FYI when I said 14+% (and now it's 17%), I mean the overall > performance of starting lldb, not just the demangler itself. It's > probably several times faster now with this change > (https://reviews.llvm.org/D32500 <https://reviews.llvm.org/D32500>) > > Do you know what the llvm policy is on using TLS in library code? > I can't find any mention of this in the programmer's manual, and > my officemates don't know either. > > > Both libcxx and libcxxabi use __libcpp_tls_*() functions of the > threading API [2] (which call pthread functions on most platforms) for > thread-local storage needs. IIRC thread_local is not implemented > across all the platforms that llvm support. > > If the idea is to improve libcxxabi's demangler, then it should be > straightforward to use these functions instead of thread_local. > > [1] > https://github.com/llvm-mirror/libcxxabi/blob/master/src/cxa_demangle.cpp > <https://github.com/llvm-mirror/libcxxabi/blob/master/src/cxa_demangle.cpp> > [2] > https://github.com/llvm-mirror/llvm/blob/master/lib/Demangle/ItaniumDemangle.cpp > [3] > https://github.com/llvm-mirror/libcxx/blob/master/include/__threading_support > <https://github.com/llvm-mirror/libcxx/blob/master/include/__threading_support> > > PS: Here's a particularly amusing bug of the current libcxxabi > demangler: https://bugs.llvm.org//show_bug.cgi?id=31031 > > Cheers, > > / Asiri > > > vedant > > > > On Tue, Apr 25, 2017 at 12:19 PM, Vedant Kumar <vsk at apple.com > <mailto:vsk at apple.com>> wrote: > > I thought the plan of record was (r280732): > > > > ''' > > Once the fast demangler in lldb can handle any names this > > implementation can be replaced with it and we will have the one true > > demangler. > > ''' > > > > What is the status of lldb's fast demangler? Is it available on > Ubuntu 16.04? > > > > vedant > > > > > > > On Apr 24, 2017, at 6:02 PM, Scott Smith via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > > > (Again), while trying to improve the performance of lldb, I > ran into a bottleneck with the demangler. This may be specific to > my platform - Ubuntu 16.04, probably using libstdc++, not libc++. > It makes extensive use of std::string and std::vector, and I see > memory allocation at the top. I prototyped a version that uses an > arena-style memory allocator (you can allocate, but you can't ever > free). It is approximately 14+% faster. I think I can further > optimize it by making repeated appends zero-copy (for the string > being appended too). > > > > > > The code right now is a little ugly, because it uses a thread > local variable to pass around the arena pointer, rather than > change every + and += to be function calls that take db.arena as a > parameter. I'm not sure what you guys would prefer for that > either (thread local variable vs api change). > > > > > > _______________________________________________ > > > LLVM Developers mailing list > > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > >-- Jon Roelofs jonathan at codesourcery.com CodeSourcery / Mentor Embedded / Siemens -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170425/ec89a40d/attachment.html>
Scott Smith via llvm-dev
2017-Apr-25 21:09 UTC
[llvm-dev] RFC: Improving the performance of ItaniumDemangle
The libcxxapi demangler doesn't look any faster than the llvm demangler. It still suffers from excessive use of malloc. On Tue, Apr 25, 2017 at 1:37 PM, Asiri Rathnayake < asiri.rathnayake at gmail.com> wrote:> > > On Tue, Apr 25, 2017 at 8:36 PM, Vedant Kumar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> > On Apr 25, 2017, at 12:24 PM, Scott Smith <scott.smith at purestorage.com> >> wrote: >> > >> > well, top-of-branch lldb uses this code, that's how I found it. Do you >> mean libc++'s demangler? >> >> Thanks for explaining, this is the first time I'm looking at the >> demangler situation. It looks like libcxxabi has an arena-based demangler, >> and that the one in llvm is different. >> >> I'm confused by this because the comment in llvm says that libcxxabi is >> supposed to reuse the llvm demangler. This doesn't seem to be happening, >> right? >> > > This seems correct. libcxxabi demangler [1] is different from the one used > by llvm [2]. I'm hoping Saleem, Eric or Jon (copied) knows a bit of history > as to why this is so (perhaps because the two projects evolved > independently ?). > > >> >> > FYI when I said 14+% (and now it's 17%), I mean the overall performance >> of starting lldb, not just the demangler itself. It's probably several >> times faster now with this change (https://reviews.llvm.org/D32500) >> >> Do you know what the llvm policy is on using TLS in library code? I can't >> find any mention of this in the programmer's manual, and my officemates >> don't know either. >> > > Both libcxx and libcxxabi use __libcpp_tls_*() functions of the threading > API [2] (which call pthread functions on most platforms) for thread-local > storage needs. IIRC thread_local is not implemented across all the > platforms that llvm support. > > If the idea is to improve libcxxabi's demangler, then it should be > straightforward to use these functions instead of thread_local. > > [1] https://github.com/llvm-mirror/libcxxabi/blob/master/src/ > cxa_demangle.cpp > [2] https://github.com/llvm-mirror/llvm/blob/master/lib/ > Demangle/ItaniumDemangle.cpp > [3] https://github.com/llvm-mirror/libcxx/blob/master/include/__ > threading_support > > PS: Here's a particularly amusing bug of the current libcxxabi demangler: > https://bugs.llvm.org//show_bug.cgi?id=31031 > > Cheers, > > / Asiri > > >> >> vedant >> >> >> > On Tue, Apr 25, 2017 at 12:19 PM, Vedant Kumar <vsk at apple.com> wrote: >> > I thought the plan of record was (r280732): >> > >> > ''' >> > Once the fast demangler in lldb can handle any names this >> > implementation can be replaced with it and we will have the one true >> > demangler. >> > ''' >> > >> > What is the status of lldb's fast demangler? Is it available on Ubuntu >> 16.04? >> > >> > vedant >> > >> > >> > > On Apr 24, 2017, at 6:02 PM, Scott Smith via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> > > >> > > (Again), while trying to improve the performance of lldb, I ran into >> a bottleneck with the demangler. This may be specific to my platform - >> Ubuntu 16.04, probably using libstdc++, not libc++. It makes extensive use >> of std::string and std::vector, and I see memory allocation at the top. I >> prototyped a version that uses an arena-style memory allocator (you can >> allocate, but you can't ever free). It is approximately 14+% faster. I >> think I can further optimize it by making repeated appends zero-copy (for >> the string being appended too). >> > > >> > > The code right now is a little ugly, because it uses a thread local >> variable to pass around the arena pointer, rather than change every + and >> += to be function calls that take db.arena as a parameter. I'm not sure >> what you guys would prefer for that either (thread local variable vs api >> change). >> > > >> > > _______________________________________________ >> > > LLVM Developers mailing list >> > > llvm-dev at lists.llvm.org >> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > >> > >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170425/94e10ae5/attachment.html>
Scott Smith via llvm-dev
2017-Apr-25 21:38 UTC
[llvm-dev] RFC: Improving the performance of ItaniumDemangle
On Tue, Apr 25, 2017 at 1:51 PM, Jonathan Roelofs <jonathan at codesourcery.com> wrote:> lldb has its own because it has different constraints w.r.t. memory > allocation and speed compared to the __cxa_* one. (I don't know much about > the details there though). If falls back on the __cxa_* implementation for > some cases where the "fast" one's implementation is incomplete (again, > repeating what I remember... I don't know the details). >I didn't realize lldb had its own demangler. It must not be very thorough, because my lldb session was falling back to llvm's demangler quite a lot! Without my change, disabling lldb's FastDemangler is ~10% slower. With my change, disabling lldb's FastDemangler is ~1.25% slower. (as measured by perf stat running lldb, # of cycles. Interesting, the instruction count difference is much larger, implying lldb's demangler has very poor IPC). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170425/168e8c5d/attachment.html>
Saleem Abdulrasool via llvm-dev
2017-Apr-30 20:54 UTC
[llvm-dev] RFC: Improving the performance of ItaniumDemangle
On Tue, Apr 25, 2017 at 1:37 PM, Asiri Rathnayake < asiri.rathnayake at gmail.com> wrote:> > > On Tue, Apr 25, 2017 at 8:36 PM, Vedant Kumar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> > On Apr 25, 2017, at 12:24 PM, Scott Smith <scott.smith at purestorage.com> >> wrote: >> > >> > well, top-of-branch lldb uses this code, that's how I found it. Do you >> mean libc++'s demangler? >> >> Thanks for explaining, this is the first time I'm looking at the >> demangler situation. It looks like libcxxabi has an arena-based demangler, >> and that the one in llvm is different. >> >> I'm confused by this because the comment in llvm says that libcxxabi is >> supposed to reuse the llvm demangler. This doesn't seem to be happening, >> right? >> > > This seems correct. libcxxabi demangler [1] is different from the one used > by llvm [2]. I'm hoping Saleem, Eric or Jon (copied) knows a bit of history > as to why this is so (perhaps because the two projects evolved > independently ?). >They didnt really evolve independently, the version in LLVM was imported from libc++. However, we simplified it to make it more portable. The simpifications naturally led to the ability to remove the arena allocation routines. The copy in libc++ needs to retain a certain amount of flexibility due to the exporting of the interface into the user's address space (via the __cxa_demangle interface). However, making adjustments that improve performance in the LLVM version should be acceptable.> >> >> > FYI when I said 14+% (and now it's 17%), I mean the overall performance >> of starting lldb, not just the demangler itself. It's probably several >> times faster now with this change (https://reviews.llvm.org/D32500) >> >> Do you know what the llvm policy is on using TLS in library code? I can't >> find any mention of this in the programmer's manual, and my officemates >> don't know either. >> > > Both libcxx and libcxxabi use __libcpp_tls_*() functions of the threading > API [2] (which call pthread functions on most platforms) for thread-local > storage needs. IIRC thread_local is not implemented across all the > platforms that llvm support. > > If the idea is to improve libcxxabi's demangler, then it should be > straightforward to use these functions instead of thread_local. > > [1] https://github.com/llvm-mirror/libcxxabi/blob/master/src/ > cxa_demangle.cpp > [2] https://github.com/llvm-mirror/llvm/blob/master/lib/ > Demangle/ItaniumDemangle.cpp > [3] https://github.com/llvm-mirror/libcxx/blob/master/include/__ > threading_support > > PS: Here's a particularly amusing bug of the current libcxxabi demangler: > https://bugs.llvm.org//show_bug.cgi?id=31031 > > Cheers, > > / Asiri > > >> >> vedant >> >> >> > On Tue, Apr 25, 2017 at 12:19 PM, Vedant Kumar <vsk at apple.com> wrote: >> > I thought the plan of record was (r280732): >> > >> > ''' >> > Once the fast demangler in lldb can handle any names this >> > implementation can be replaced with it and we will have the one true >> > demangler. >> > ''' >> > >> > What is the status of lldb's fast demangler? Is it available on Ubuntu >> 16.04? >> > >> > vedant >> > >> > >> > > On Apr 24, 2017, at 6:02 PM, Scott Smith via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> > > >> > > (Again), while trying to improve the performance of lldb, I ran into >> a bottleneck with the demangler. This may be specific to my platform - >> Ubuntu 16.04, probably using libstdc++, not libc++. It makes extensive use >> of std::string and std::vector, and I see memory allocation at the top. I >> prototyped a version that uses an arena-style memory allocator (you can >> allocate, but you can't ever free). It is approximately 14+% faster. I >> think I can further optimize it by making repeated appends zero-copy (for >> the string being appended too). >> > > >> > > The code right now is a little ugly, because it uses a thread local >> variable to pass around the arena pointer, rather than change every + and >> += to be function calls that take db.arena as a parameter. I'm not sure >> what you guys would prefer for that either (thread local variable vs api >> change). >> > > >> > > _______________________________________________ >> > > LLVM Developers mailing list >> > > llvm-dev at lists.llvm.org >> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > >> > >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > >-- Saleem Abdulrasool compnerd (at) compnerd (dot) org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170430/6b4864fb/attachment.html>
Pavel Labath via llvm-dev
2017-May-03 09:46 UTC
[llvm-dev] RFC: Improving the performance of ItaniumDemangle
One of the things we need in lldb is to find a "basename" of a function. This is so that you can set a breakpoint on a function named "foo", even if "foo" is a method of a template class declared inside another function, which is inside 5 namespaces, a couple of them being anonymous... :) Currently we do that by parsing the demangled name, which is neither fast nor easy, especially when function pointers come into the game (D31451). We could probably save some runtime if the demangler could provide us with a bit more structured information instead of just the final demangled string. I expect the demangler to be in a much better position to do that then us trying to reverse engineer the string. I have no idea how this fits in with the rest of the goals of llvm's demangler, but I guess it doesn't hurt throwing the idea out there. cheers, pl On 30 April 2017 at 21:54, Saleem Abdulrasool via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > > On Tue, Apr 25, 2017 at 1:37 PM, Asiri Rathnayake > <asiri.rathnayake at gmail.com> wrote: >> >> >> >> On Tue, Apr 25, 2017 at 8:36 PM, Vedant Kumar via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> >>> >>> > On Apr 25, 2017, at 12:24 PM, Scott Smith <scott.smith at purestorage.com> >>> > wrote: >>> > >>> > well, top-of-branch lldb uses this code, that's how I found it. Do you >>> > mean libc++'s demangler? >>> >>> Thanks for explaining, this is the first time I'm looking at the >>> demangler situation. It looks like libcxxabi has an arena-based demangler, >>> and that the one in llvm is different. >>> >>> I'm confused by this because the comment in llvm says that libcxxabi is >>> supposed to reuse the llvm demangler. This doesn't seem to be happening, >>> right? >> >> >> This seems correct. libcxxabi demangler [1] is different from the one used >> by llvm [2]. I'm hoping Saleem, Eric or Jon (copied) knows a bit of history >> as to why this is so (perhaps because the two projects evolved independently >> ?). > > > They didnt really evolve independently, the version in LLVM was imported > from libc++. However, we simplified it to make it more portable. The > simpifications naturally led to the ability to remove the arena allocation > routines. The copy in libc++ needs to retain a certain amount of > flexibility due to the exporting of the interface into the user's address > space (via the __cxa_demangle interface). However, making adjustments that > improve performance in the LLVM version should be acceptable. > >>> >>> >>> >>> > FYI when I said 14+% (and now it's 17%), I mean the overall performance >>> > of starting lldb, not just the demangler itself. It's probably several >>> > times faster now with this change (https://reviews.llvm.org/D32500) >>> >>> Do you know what the llvm policy is on using TLS in library code? I can't >>> find any mention of this in the programmer's manual, and my officemates >>> don't know either. >> >> >> Both libcxx and libcxxabi use __libcpp_tls_*() functions of the threading >> API [2] (which call pthread functions on most platforms) for thread-local >> storage needs. IIRC thread_local is not implemented across all the platforms >> that llvm support. >> >> If the idea is to improve libcxxabi's demangler, then it should be >> straightforward to use these functions instead of thread_local. >> >> [1] >> https://github.com/llvm-mirror/libcxxabi/blob/master/src/cxa_demangle.cpp >> [2] >> https://github.com/llvm-mirror/llvm/blob/master/lib/Demangle/ItaniumDemangle.cpp >> [3] >> https://github.com/llvm-mirror/libcxx/blob/master/include/__threading_support >> >> PS: Here's a particularly amusing bug of the current libcxxabi demangler: >> https://bugs.llvm.org//show_bug.cgi?id=31031 >> >> Cheers, >> >> / Asiri >> >>> >>> >>> vedant >>> >>> >>> > On Tue, Apr 25, 2017 at 12:19 PM, Vedant Kumar <vsk at apple.com> wrote: >>> > I thought the plan of record was (r280732): >>> > >>> > ''' >>> > Once the fast demangler in lldb can handle any names this >>> > implementation can be replaced with it and we will have the one true >>> > demangler. >>> > ''' >>> > >>> > What is the status of lldb's fast demangler? Is it available on Ubuntu >>> > 16.04? >>> > >>> > vedant >>> > >>> > >>> > > On Apr 24, 2017, at 6:02 PM, Scott Smith via llvm-dev >>> > > <llvm-dev at lists.llvm.org> wrote: >>> > > >>> > > (Again), while trying to improve the performance of lldb, I ran into >>> > > a bottleneck with the demangler. This may be specific to my platform - >>> > > Ubuntu 16.04, probably using libstdc++, not libc++. It makes extensive use >>> > > of std::string and std::vector, and I see memory allocation at the top. I >>> > > prototyped a version that uses an arena-style memory allocator (you can >>> > > allocate, but you can't ever free). It is approximately 14+% faster. I >>> > > think I can further optimize it by making repeated appends zero-copy (for >>> > > the string being appended too). >>> > > >>> > > The code right now is a little ugly, because it uses a thread local >>> > > variable to pass around the arena pointer, rather than change every + and +>>> > > to be function calls that take db.arena as a parameter. I'm not sure what >>> > > you guys would prefer for that either (thread local variable vs api change). >>> > > >>> > > _______________________________________________ >>> > > LLVM Developers mailing list >>> > > llvm-dev at lists.llvm.org >>> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> > >>> > >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> > > > > -- > Saleem Abdulrasool > compnerd (at) compnerd (dot) org > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >