search for: memorybufferref

....cpp:4766) ==29299== by 0x1CCE2C2: llvm::LLParser::ParseDeclare() (LLParser.cpp:444) ==29299== by 0x1CCC15A: llvm::LLParser::ParseTopLevelEntities() (LLParser.cpp:276) ==29299== by 0x1CCBFBF: llvm::LLParser::Run() (LLParser.cpp:74) ==29299== by 0x1CC59D8: llvm::parseAssemblyInto(llvm::MemoryBufferRef, llvm::Module&, llvm::SMDiagnostic&, llvm::SlotMapping*) (Parser.cpp:31) ==29299== by 0x1CC5C16: llvm::parseAssembly(llvm::MemoryBufferRef, llvm::SMDiagnostic&, llvm::LLVMContext&, llvm::SlotMapping*) (Parser.cpp:41) ==29299== by 0x158C59E: llvm::parseIR(llvm::MemoryBufferRe...

...C2: llvm::LLParser::ParseDeclare() (LLParser.cpp:444) >> ==29299== by 0x1CCC15A: llvm::LLParser::ParseTopLevelEntities() >> (LLParser.cpp:276) >> ==29299== by 0x1CCBFBF: llvm::LLParser::Run() (LLParser.cpp:74) >> ==29299== by 0x1CC59D8: llvm::parseAssemblyInto(llvm::MemoryBufferRef, >> llvm::Module&, llvm::SMDiagnostic&, llvm::SlotMapping*) (Parser.cpp:31) >> ==29299== by 0x1CC5C16: llvm::parseAssembly(llvm::MemoryBufferRef, >> llvm::SMDiagnostic&, llvm::LLVMContext&, llvm::SlotMapping*) (Parser.cpp:41) >> ==29299== by 0x158C59E:...

...t = true; bool AllowIsolation = true; bool TerminalServerAware = true; bool LargeAddressAware = false; bool HighEntropyVA = false; // This is for debugging. bool DebugPdb = false; bool DumpPdb = false; }; extern Configuration *Config; void writeImportLibrary(); void parseModuleDefs(MemoryBufferRef MB); } // namespace coff } // namespace lld //========================================================================= This is so that I can write the following user code: // writes the output to dll_path with .dll replaced with .lib void ZigLLDDefToLib(Buf *def_contents, Buf *dll_path) {...

...are = false; >> bool HighEntropyVA = false; >> >> // This is for debugging. >> bool DebugPdb = false; >> bool DumpPdb = false; >> }; >> >> extern Configuration *Config; >> >> void writeImportLibrary(); >> void parseModuleDefs(MemoryBufferRef MB); >> >> } // namespace coff >> } // namespace lld >> >> //========================================================== >> =============== >> >> >> >> >> This is so that I can write the following user code: >> >> >>...

Hi, All I m not sure if this question has been asked or not. I'd like cache the MCJIT compiled object into memory buffer so it can be reused later. I followed the Andy Kaylor's example wrote an inherited class from ObjectCache and use raw_fd_ostream to save the cache and load the cache from a file. I checked raw_ostream and its subclass, maybe I am wrong but I don't see one is fit to

...;> // This is for debugging. >>>> bool DebugPdb = false; >>>> bool DumpPdb = false; >>>> }; >>>> >>>> extern Configuration *Config; >>>> >>>> void writeImportLibrary(); >>>> void parseModuleDefs(MemoryBufferRef MB); >>>> >>>> } // namespace coff >>>> } // namespace lld >>>> >>>> //========================================================== >>>> =============== >>>> >>>> >>>> >>>> >>...

...cache to my run-time. I've implemented the object cache as follow: class EngineObjectCache : public llvm::ObjectCache { private: std::unordered_map<std::string, std::unique_ptr<llvm::MemoryBuffer>> CachedObjs; public: virtual void notifyObjectCompiled(const llvm::Module *M, llvm::MemoryBufferRef Obj) { auto id = M->getModuleIdentifier(); auto iter = CachedObjs.find(id); if (iter == CachedObjs.end()) { auto buf = llvm::MemoryBuffer::getMemBufferCopy(Obj.getBuffer(), Obj.getBufferIdentifier()); CachedObjs.insert(std::make_pair(id, std::move(buf))); } }; virtual std::unique_ptr<llvm::Me...

...s were used. // Given a bitcode file followed by garbage, get the size of the actual // bitcode. This only works correctly with some kinds of garbage (in // particular, it will work if the bitcode file is followed by zeros, or if // it's followed by another bitcode file). size_t GetBitcodeSize(MemoryBufferRef Buffer) { const unsigned char *BufPtr = reinterpret_cast<const unsigned char *>(Buffer.getBufferStart()); const unsigned char *EndBufPtr = reinterpret_cast<const unsigned char *>(Buffer.getBufferEnd()); if (isBitcodeWrapper(BufPtr, EndBufPtr)) { const unsigned char...

On Wed, Feb 10, 2016 at 10:50 AM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> Is this change indeed intended as a visible API change to source code generating references to argument list values? If so, can you point me to a description of how I should change our code? Should I bug someone else about this problem? Should this API change be documented in

...basic design should work in such case too. The function signature would be something like: bool link(ArrayRef<LinkerArg> CommandLineArgs, MemoryBuffer &OutputFile, std::string &ErrorMsg); where the return value indicates success/failure. LinkerArg is a union type of StringRef and MemoryBufferRef. The result is returned as OutputFile memory buffer. If it prints out any message, ErrorMsg will hold it. (I want to point out that the function "bool link(ArrayRef<const char*> args, raw_ostream& diagnostics, ArrayRef<unique_ptr<MemoryBuffer>> inputs)" doesn't...

...tion signature would be something like: >> >> bool link(ArrayRef<LinkerArg> CommandLineArgs, MemoryBuffer >> &OutputFile, std::string &ErrorMsg); >> >> where the return value indicates success/failure. LinkerArg is a union >> type of StringRef and MemoryBufferRef. The result is returned as OutputFile >> memory buffer. If it prints out any message, ErrorMsg will hold it. >> >> (I want to point out that the function "bool link(ArrayRef<const char*> >> args, raw_ostream& diagnostics, ArrayRef<unique_ptr<MemoryBuffer...

...::object::ObjectFile&, llvm::DWARFContext&, llvm::Twine, llvm::raw_ostream&)>::operator()(llvm::object::ObjectFile&, llvm::DWARFContext&, llvm::Twine, llvm::raw_ostream&) const /usr/include/c++/5/functional:2268:0 #27 0x0000000000415377 handleBuffer(llvm::StringRef, llvm::MemoryBufferRef, std::function<bool (llvm::object::ObjectFile&, llvm::DWARFContext&, llvm::Twine, llvm::raw_ostream&)>, llvm::raw_ostream&) /home/linux/llvm-7/llvm/tools/llvm-dwarfdump/llvm-dwarfdump.cpp:472:0 #28 0x0000000000415ae2 handleFile(llvm::StringRef, std::function<bool (llvm::obj...

...&, llvm::Twine, >> llvm::raw_ostream&)>::operator()(llvm::object::ObjectFile&, >> llvm::DWARFContext&, llvm::Twine, llvm::raw_ostream&) const >> /usr/include/c++/5/functional:2268:0 >> #27 0x0000000000415377 handleBuffer(llvm::StringRef, >> llvm::MemoryBufferRef, std::function<bool (llvm::object::ObjectFile&, >> llvm::DWARFContext&, llvm::Twine, llvm::raw_ostream&)>, llvm::raw_ostream&) >> /home/linux/llvm-7/llvm/tools/llvm-dwarfdump/llvm-dwarfdump.cpp:472:0 >> #28 0x0000000000415ae2 handleFile(llvm::StringRef, std::...

...d by garbage, get the size of the actual >> // bitcode. This only works correctly with some kinds of garbage (in >> // particular, it will work if the bitcode file is followed by zeros, or >> if >> // it's followed by another bitcode file). >> size_t GetBitcodeSize(MemoryBufferRef Buffer) { >> const unsigned char *BufPtr = >> reinterpret_cast<const unsigned char *>(Buffer.getBufferStart()); >> const unsigned char *EndBufPtr = >> reinterpret_cast<const unsigned char *>(Buffer.getBufferEnd()); >> if (isBitcodeWrapper(...

...m::raw_ostream&)>::operator()(llvm::object::ObjectFile&, >>>> llvm::DWARFContext&, llvm::Twine, llvm::raw_ostream&) const >>>> /usr/include/c++/5/functional:2268:0 >>>> #27 0x0000000000415377 handleBuffer(llvm::StringRef, >>>> llvm::MemoryBufferRef, std::function<bool (llvm::object::ObjectFile&, >>>> llvm::DWARFContext&, llvm::Twine, llvm::raw_ostream&)>, llvm::raw_ostream&) >>>> /home/linux/llvm-7/llvm/tools/llvm-dwarfdump/llvm-dwarfdump.cpp:472:0 >>>> #28 0x0000000000415ae2 handleFil...

...f>, uint64_t> + CFGProfile; bool AllowMultipleDefinition; bool AsNeeded = false; bool Bsymbolic; diff --git a/ELF/Driver.cpp b/ELF/Driver.cpp index 263ba7b..04740db 100644 --- a/ELF/Driver.cpp +++ b/ELF/Driver.cpp @@ -600,6 +600,23 @@ static std::vector<StringRef> getLines(MemoryBufferRef MB) { return Ret; } +static void readCallGraph(MemoryBufferRef MB) { + DenseMap<std::pair<StringRef, StringRef>, uint64_t> Ret; + std::vector<StringRef> Lines = getLines(MB); + for (StringRef L : Lines) { + SmallVector<StringRef, 3> Fields; + L.split(Fields, &...

A rebased version of the lld patch is attached. Cheers, Rafael On 31 July 2017 at 15:11, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > Tobias Edler von Koch <tobias at codeaurora.org> writes: > >> Hi Rafael, >> >> On 07/31/2017 04:20 PM, Rafael Avila de Espindola via llvm-dev wrote: >>> However, do we need to start with

Hi all, I'm implementing interleaved source in assembly output. Early reviews raised the concern that the current implementation will be opening files (using a llvm::MemoryBuffer) that are likely to be in the memory of the front end (commonly clang but I think we want this to be front end agnostic). I'm now exploring ideas to avoid reopening files and let LLVM reuse the files the FE had

> Also, one of the other possible motivations of using LLD directly from Clang would be to avoid process overhead on operating systems where that is a much more significant part of the compile time cost. We could today actually take the fork out of the Clang driver because the Clang frontend *is* designed in this way. But we would also need LLD to work in this way. Then go change clang and

...k/MachOLinkGraphBuilder.cpp:502 #7 0x000000010668d16c in llvm::jitlink::MachOLinkGraphBuilder::buildGraph() at /Users/igorgomon/dev/third-party/llvm-project/llvm/lib/ExecutionEngine/JITLink/MachOLinkGraphBuilder.cpp:36 #8 0x000000010666cd08 in llvm::jitlink::MachOJITLinker_arm64::buildGraph(llvm::MemoryBufferRef) at /Users/igorgomon/dev/third-party/llvm-project/llvm/lib/ExecutionEngine/JITLink/MachO_arm64.cpp:493 #9 0x00000001066236bc in llvm::jitlink::JITLinkerBase::linkPhase1(std::__1::unique_ptr<llvm::jitlink::JITLinkerBase, std::__1::default_delete<llvm::jitlink::JITLinkerBase> >) at /User...