search for: itaniumdemangle

Hi all, We know that 'ItaniumDemangle' has been added into llvm lib to resolve demangling related issues. And if we dump mangled function name '_Z3duti' into 'char *llvm::itaniumDemangle(const char *mangled_name, char *buf, size_t *n, int *status)', we will get 'dut(int)'. So my question is: How can I just...

Hi Fangqing, llvm::itaniumDemangle() doesn't yet provide this functionality, but I'm working on adding it in now for the LLDB folks (http://lists.llvm.org/pipermail/lldb-dev/2018-January/013186.html). I should have a patch up Very Soon! If you would like I can CC you to it. Thanks, Erik On 2018-03-16 2:15 PM, Fangqing Du...

(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

Yes, that’s right. Some LLVM terminology though: The blocks you mention, are called the “exiting blocks” of the loop, and the blocks outside the loop (that are the targets of these exiting blocks) are called the exit blocks. getExitingBlocks in LoopInfoImpl.h is the code you’re interested in. By definition: one of the successor’s of the exiting block is an exit block, and it should have another

...a 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 > > >> >>...

well, top-of-branch lldb uses this code, that's how I found it. Do you mean libc++'s demangler? 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) On Tue, Apr 25, 2017 at 12:19 PM, Vedant Kumar <vsk at apple.com>

...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 P...

...xample), and the code for doing that is quite ugly. It would be much nicer if we could just query the parsed representation of the name somehow, and the AST would enable us to do that. I was thinking about this use case a little, actually. I think it makes more sense to provide a function, say getItaniumDemangledBasename(), which could just parse and query the AST for the base name (the AST already has an way of doing this). This would allow the demangler to bail out if it knows that the rest of the input string isn’t relevant, i.e., we could bail out after parsing the ‘foo’ in _Z3fooiiiiiii. That, and not...

Hello, I have a question about exit blocks : is it true that every loop's exit block will contain only those comparisons that will lead to exit or to continue execution in loop? I have tried many examples , after optimizations it seems to be true, but does it have to be so? -------------- next part -------------- An HTML attachment was scrubbed... URL:

...their system's C++ standard library?) > > I believe there is some work being done on that already < http://lists.llvm.org/pipermail/lldb-dev/2018-January/013186.html>, but I'm not sure what's the current state of it. Also, in the default configuration, LLDB will use lllvm::itaniumDemangle for demangling (although there is a build option to use cxa_demangle). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180306/14f392aa/attachment.html>

...nts that I'd like to get > through. After that, it might be interesting to try to replace the > FastDemangle.cpp demangler in LLDB with this, to restore the one > true demangler in the source tree. The FastDemangler.cpp is only > partially completed, and calls out to ItaniumDemangle.cpp in llvm > (which is a copy of cxa_demangle.cpp) if it fails to parse the symbol. > > Any thoughts here would be appreciated! > Thanks, > Erik > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at l...

...would be much nicer if we >> could just query the parsed representation of the name somehow, and >> the AST would enable us to do that. >> >> >> I was thinking about this use case a little, actually. I think it makes more >> sense to provide a function, say getItaniumDemangledBasename(), which could >> just parse and query the AST for the base name (the AST already has an way >> of doing this). This would allow the demangler to bail out if it knows that >> the rest of the input string isn’t relevant, i.e., we could bail out after >> parsing the ‘...

Dear testers, 8.0.0-rc1 was just tagged (from the branch at r351980). It took a little longer than planned, but it's looking good. Please run the test script, share your results, and upload binaries. I'll get the source tarballs and docs published as soon as possible, and binaries as they become available. Thanks, Hans

> On Dec 15, 2016, at 6:18 AM, Dave Bozier via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > > We’re hoping to replace the demangler in some of our tools to use the LLVM demangler. We’d like to enhance it with missing functionality (legal names that it cannot demangle) and provide a set of tests that we use with the demangler that we currently use. >

> On Mar 4, 2018, at 10:20 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > > On Sun, Mar 4, 2018 at 12:33 AM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote: >> On Mar 3, 2018, at 11:30 PM, Daniel Berlin via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: >> >> To

...In function `llvm::sys::PrintStackTrace(llvm::raw_ostream&)': > Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x24): undefined reference to `backtrace' > Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x254): undefined reference to `llvm::itaniumDemangle(char const*, char*, unsigned long*, int*)' > clang-8: error: linker command failed with exit code 1 (use -v to see invocation) > gmake[3]: *** [projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build.make:73: projects/compiler-rt/lib/xray/tests/unit/XRayTest-x8...

On Sun, Mar 4, 2018 at 12:33 AM, John McCall <rjmccall at apple.com> wrote: > On Mar 3, 2018, at 11:30 PM, Daniel Berlin via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > > To explain to others who didn't follow that thread: > > GDB currently does something amazingly stupid (and has since i wrote it) > to find the RTTI type. There were no other good options

...ring done     -- Generating done -- Build files have been writtento: /testlocation/llvm_lld/build   4.     But on running ‘make install’, following erroris observed: $ make install Scanning dependencies of targetLLVMDemangle [ 0%] Building CXX objectlib/Demangle/CMakeFiles/LLVMDemangle.dir/ItaniumDemangle.cpp.o [ 0%] Linking CXX static library ../libLLVMDemangle.a [ 0%] Built target LLVMDemangle Scanning dependencies of targetLLVMSupport [ 0%] Building CXX objectlib/Support/CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.o In file included from /testlocation/llvm_lld/llvm-stable/lib/Support/AMDGP...

...rings and performance improvements that I'd like to get through. After that, it might be interesting to try to replace the FastDemangle.cpp demangler in LLDB with this, to restore the one true demangler in the source tree. The FastDemangler.cpp is only partially completed, and calls out to ItaniumDemangle.cpp in llvm (which is a copy of cxa_demangle.cpp) if it fails to parse the symbol. Any thoughts here would be appreciated! Thanks, Erik -------------- next part -------------- commit e526dffc812b303734fbce5644f2d2ae4c4ca3dc Author: Erik Pilkington <erik.pilkington at gmail.com> Date: Thu...