similar to: DeclarationName and the StringRef.

On 12/21/2016 5:01 AM, Umesh Kalappa via llvm-dev wrote: > To context was , > > Basic requirement was to append extra string to the decl name and > update all his references to the updated name. , > > So we are constructing the DeclarationName instance as stated below > code snap. > and from DeclarationName instance ,we are constructing the > DeclarationNameInfo

Hi Guys , We have the function that accepts StringRef and construct the DeclarationName instance . Currenlty we are achieving the same as ,the code snap void appendExtern(StringRef Sr) { char *ExternChar = const_cast<char *> (Sr.data()); *Ptr =reinterpret_cast<void *>(ExternChar); this->ExternName = DeclarationName::getFromOpaquePtr(Ptr); } There is, any better way of

Hi everyone, TL;DR: With current pending patches applied in compiler-rt and llvm, and trunk clang, you can build your application with XRay tracing enabled on Linux with tracing enabled before main starts, and logging stops when the main thread exits. Just a quick update, I have some patches under review that when applied cleanly to LLVM and compiler-rt allows for building applications with XRay

Hello everyone! After I've checked out Clang and Compiler-RT repositories, I receive this error during compilation: llvm[5]: Compiling PathDiagnostic.cpp for Debug+Asserts build /media/data/dev/llvm/llvm/tools/clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp: In member function 'bool {anonymous}::CompareDiagnostics::operator()(const clang::ento::PathDiagnostic*, const

Hi Vadim, which compiler are you using to to the build, what platform are you on, how did you configure LLVM, clang etc ? Ciao, duncan. On 09/09/12 03:36, Vadim Khoptynets wrote: > Hello everyone! > > After I've checked out Clang and Compiler-RT repositories, I receive this error > during compilation: > > llvm[5]: Compiling PathDiagnostic.cpp for Debug+Asserts build >

Hi all， Clang use a hash table to store all its identifiers. The hash table definition is: typedef llvm::StringMap<IdentifierInfo*, llvm::BumpPtrAllocator> HashTableTy; HashTableTy HashTable; Can anyone explain the mechnism of handling the name string key collision for me? Is there a IdentifierInfo objects chain or list for variable or function with the same name? Thanks very much!

> > I'm not sure we would want to store the MCInst(s) in the AST. After we're > done with semantic checking and we've created the IR representation (with > inputs, outputs, clobbers, constraints, etc.), I don't think there's a > reason for the MCInst(s) to persist. > I was assuming that MCInst would already provide a lot of the needed information, like

Hi All, We have populated info in the Clang Sema i.e class Sema (include/clang/Sema/Sema.h) and like to propagate the same to Clang Codegen . Currently we are propagating through ASTContext ,where we have duplicating fields info and operation in the Sema and ASTContext . Any better way of doing the same ? Thank you ~Umesh

On Aug 6, 2012, at 1:03 PM, João Matos wrote: > 1. How is clang going to discover the input operands, output operands, > constraints, and clobbered registers? > > The approach you described sounds good to me. Reusing all the work done in the LLVM MC layer seems the right approach. Glad you agree. We really shouldn't be replicating information in the frontend; this very error

On 2016年12月22日 15:37, via llvm-dev 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

I've hit this weird compiler error when building llvm/clang $ clang --version clang version 2.9 (trunk 125254) Target: x86_64-apple-darwin10 Thread model: posix Source rev is 125326 $ make llvm[1]: Compiling APFloat.cpp for Release build llvm[1]: Compiling APInt.cpp for Release build llvm[1]: Compiling APSInt.cpp for Release build llvm[1]: Compiling Allocator.cpp for Release build llvm[1]:

Hi, a downstream consumer of llvm I'm currently working provides the following two functions: static bool StringHasAllOf(const llvm::StringRef &s, const char *which); static bool StringHasAnyOf(const llvm::StringRef &s, std::initializer_list<const char *> which, size_t &where); https://github.com/apple/swift-lldb/blob/stable/source/Target/SwiftLanguageRuntime.cpp#L691

> curiosity question: how much more efficient (vague question, I know) > is the StringRef + SmallVector than a good (eg: libc++) std::string > implementation? I know, for example, that Visual C++ 2010's > std::string does perform the small string optimization which I guess > is what SmallVector is doing. > > - David Problem is, there are REALLY bad std::string

> Perhaps, I suppose, I'm not sure just how portable llvm code is. Very portable AFAICT. I'm even going to port it to my hobbyist OS once C++ rtti is totally gone in the llvm code base.

>> Perhaps, I suppose, I'm not sure just how portable llvm code is. > > Very portable AFAICT. I'm even going to port it to my hobbyist OS once C++ > rtti is totally gone in the llvm code base. Sorry, I meant source portable to different compilers (ie: which compilers does llvm compile on & how many have really poor std::string implementations). - David

> [diff attached] Updated diff with test fix. (since this broke a test (printing chars as numerical values, rather than characters) it's possible this change is a bad idea & it could break the product code itself. Though strangely I wasn't able to do character concatenation without my change, so I have a sneaking suspicion that while the test passed, it didn't actually expose

Hi, Dipanjan, On 28 April 2017 at 16:32, Dipanjan Das via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I am wriitng an LLVM pass to insert instrumentation at certain points of the > program. I want to pass the `StringRef` obtained from `getName()` as a > parameter to a function `func(char* s)`. I can allocate some space on stack > using `AllocaInst` to generate an `alloca`

Hi, Why is StringRef not an ArrayRef<char> extension? That might simplify some interfaces. Cheers, Paweł -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151105/ef56dcdc/attachment.html>

> Problem is, there are REALLY bad std::string implementations out there in > widely used c++ runtimes. No doubt - though widely used to build llvm/clang? Perhaps, I suppose, I'm not sure just how portable llvm code is. > StringRef/Twine is efficient everywhere. Yep - I'm just pedantic about having a tidy codebase, and duplicate code to workaround bad implementations when

On Jul 24, 2011, at 6:31 PM, David Blaikie wrote: >>> This keeps things simple & seems to be "good enough" to me, but we >>> could perhaps do better (at the very least, again, if we did do >>> better, we could go back & remove TwineString & again fix all the >>> places that fail to compile with whatever new hotness we invent) >>