search for: add_llvm_tool

...ack (most recent call first): cmake/modules/LLVMConfig.cmake:27 (explicit_map_components_to_libraries) cmake/modules/LLVMConfig.cmake:20 (explicit_llvm_config) cmake/modules/AddLLVM.cmake:61 (llvm_config) cmake/modules/AddLLVM.cmake:78 (add_llvm_executable) tools/llvm-mc/CMakeLists.txt:3 (add_llvm_tool) Tom

...txt b/tools/llvm-ld/CMakeLists.txt index 2ae4a1d..257d1e9 100644 --- a/tools/llvm-ld/CMakeLists.txt +++ b/tools/llvm-ld/CMakeLists.txt @@ -1,4 +1,4 @@ -set(LLVM_LINK_COMPONENTS ipo scalaropts linker archive bitwriter) +set(LLVM_LINK_COMPONENTS ipo scalaropts instcombine linker archive bitwriter) add_llvm_tool(llvm-ld Optimize.cpp diff --git a/tools/opt/CMakeLists.txt b/tools/opt/CMakeLists.txt index 0570d0e..912acfa 100644 --- a/tools/opt/CMakeLists.txt +++ b/tools/opt/CMakeLists.txt @@ -1,4 +1,4 @@ -set(LLVM_LINK_COMPONENTS bitreader asmparser bitwriter instrumentation scalaropts ipo) +set(LLVM_LINK...

...ack (most recent call first): cmake/modules/LLVMConfig.cmake:27 (explicit_map_components_to_libraries) cmake/modules/LLVMConfig.cmake:20 (explicit_llvm_config) cmake/modules/AddLLVM.cmake:61 (llvm_config) cmake/modules/AddLLVM.cmake:78 (add_llvm_executable) tools/llvm-mc/CMakeLists.txt:3 (add_llvm_tool) On Aug 2, 2010, at 11:12 AM, Tom Care wrote: > Hi all, > > CMake seems to have broken in the last few days - or is it just me? > > tcare:llvm-release tcare$ make -j4 > -- Target triple: x86_64-apple-darwin10.5.0 > -- Native target architecture is X86 > -- Threads enabl...

...odules/LLVMConfig.cmake:41 (message): llvm-config failed for executable llc Call Stack (most recent call first): cmake/modules/LLVMConfig.cmake:5 (nix_llvm_config) cmake/modules/AddLLVM.cmake:16 (llvm_config) cmake/modules/AddLLVM.cmake:36 (add_llvm_executable) tools/llc/CMakeLists.txt:3 (add_llvm_tool) I'll see if I can find the cause of the problem myself, or does anyone have a suggestion about this? Thanks, Kevin André -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_llvm_bug.patch Type: application/octet-stream Size: 2292 bytes Desc: not avail...

Tom Care <tcare at apple.com> writes: > This was after starting with an empty build directory. It seems to > work if I omit -DLLVM_TARGETS_TO_BUILD=X86, but a few days ago this > was working with just this target. Yep. I can replicate the problem on Linux with mkdir foo && cd foo cmake -DLLVM_TARGETS_TO_BUILD=X86 ../llvm I'll investigate a bit.

Hi, attached is a patch to improve including targets other than X86 in CMake MSVC builds. When adding libs to link, rather than always using LLVMX86CodeGen and LLVMX86AsmPrinter, it grabs the correct ones. It also adds "force-link-ints" to the various TargetMachine cpp files, as well as X86AsmPrinter and PPCAsmPrinter. These are needed to be able to encourage the Win32 linker to

...ter CodeGen Core MC MCJIT Object OrcJIT Interpreter RuntimeDyld Coroutines IPO IRReader InstCombine Instrumentation MC ObjCARCOpts ScalarOpts Support Target TransformUtils Vectorize Passes ExecutionEngine ) # Support plugins. set(LLVM_NO_DEAD_STRIP 1) add_llvm_tool(opt AnalysisWrappers.cpp BreakpointPrinter.cpp Debugify.cpp GraphPrinters.cpp NewPMDriver.cpp PassPrinters.cpp PrintSCC.cpp opt.cpp DEPENDS intrinsics_gen ) export_executable_symbols(opt) if(WITH_POLLY AND LINK_POLLY_INTO_TOOLS) target_link_libraries(opt PRIVATE Polly) end...

Hey: I spent sometime debugging this, it seems like editing ``llvm/tools/opt.cpp`` and move ``cl::ParseCommandLineOptions(argc, argv, "llvm .bc -> .bc modular optimizer and analysis printer\n");`` to the beginning of main() solved it for me. I'm not sure if this is a bug on LLVM side Zhang ------------------ Original ------------------ From: "Viktor Was BSc via

...ssage): > llvm-config failed for executable lli > Call Stack (most recent call first): > cmake/modules/LLVMConfig.cmake:5 (nix_llvm_config) > cmake/modules/AddLLVM.cmake:16 (llvm_config) > cmake/modules/AddLLVM.cmake:36 (add_llvm_executable) > tools/lli/CMakeLists.txt:3 (add_llvm_tool) This doesn't surprise me. It's broken. > This reminds me that I have disabled some of the libraries that I > don't need for my compiler (such as ExecutionEngine and the JIT), and > I have deleted some other directories as well (like examples, > projects, and all of the au...

...ects/raw_char_ostream_speed/CMakeLists.txt =================================================================== --- projects/raw_char_ostream_speed/CMakeLists.txt (revision 0) +++ projects/raw_char_ostream_speed/CMakeLists.txt (working copy) @@ -0,0 +1,7 @@ +set(LLVM_LINK_COMPONENTS + Support +) + +add_llvm_tool(raw_char_ostream + raw_char_ostream_speed.cpp +) Index: projects/raw_char_ostream_speed/raw_char_ostream_speed.cpp =================================================================== --- projects/raw_char_ostream_speed/raw_char_ostream_speed.cpp (revision 0) +++ projects/raw_char_ostream_speed/raw...

...LLVM_USE_INTEL_JITEVENTS ) > ) > endif( LLVM_USE_INTEL_JITEVENTS ) > > +if( LLVM_USE_PERF ) > + set(LLVM_LINK_COMPONENTS > + ${LLVM_LINK_COMPONENTS} > + DebugInfoDWARF > + PerfJITEvents > + Object > + ) > +endif( LLVM_USE_PERF ) > + > add_llvm_tool(lli > lli.cpp > OrcLazyJIT.cpp > diff --git a/tools/lli/lli.cpp b/tools/lli/lli.cpp > index 0823ff469de..9e488a293e2 100644 > --- a/tools/lli/lli.cpp > +++ b/tools/lli/lli.cpp > @@ -546,6 +546,8 @@ int main(int argc, char **argv, char * const *envp) { >...

Having something like this available in tree would definitely be useful. For simplicity, why don't we start with support for the second style? This is the long term useful one and would be a good starting point for getting the code in tree. Can you give a pointer to the patch so that I can assess the rough complexity? If it's simple enough, I'd be happy to help get it reviewed

Patch for review. On Mon, Aug 21, 2017 at 11:45 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> wrote: > Ping. > > Still working on preparing code for review. Will have a patch for review > ready in the coming days. > > PL > > On Tue, Aug 15, 2017 at 12:06 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> > wrote: > >> Hi, >> >> >>

Hi, On 2016-12-29 13:17:50 -0800, Philip Reames wrote: > Having something like this available in tree would definitely be > useful. Cool. > For simplicity, why don't we start with support for the second style? This > is the long term useful one and would be a good starting point for getting > the code in tree. Works for me. > Can you give a pointer to the patch so that

I don't think we should make flush virtual. Why do you need to do it? Can't you set up the base class to write to use the tail of the memory region as the buffer? On 24 April 2015 at 06:46, Yaron Keren <yaron.keren at gmail.com> wrote: > Hi, > > Is this what you're thinking about? > The code is not tested yet, I'd like to know if the overall direction and >

Could you dig into why: + raw_ostream &write(unsigned char C) override { + grow(1); + *OutBufCur++ = C; + return *this; + } Is 3 times as fast as raw_svector_ostream? I don't see a good reason why that should be any faster than: raw_ostream &operator<<(char C) { if (OutBufCur >= OutBufEnd) return write(C); *OutBufCur++ = C; return *this; }

...>>>> >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150522/ee08391a/attachment.html> -------------- next part -------------- set(LLVM_LINK_COMPONENTS Support ) add_llvm_tool(raw_svector_ostream_speed raw_svector_ostream_speed.cpp ) -------------- next part -------------- Index: include/llvm/Support/raw_ostream.h =================================================================== --- include/llvm/Support/raw_ostream.h (revision 237261) +++ include/llvm/Support/raw_ost...