similar to: Build libLTO.a instead of libLTO.dylib with Cmake

Hi, I have some questions about the compilation of the llvm. First, why the majority of the results of compilation are static library ( *.a files in the $(LLVM_HOME)/Release+Asserts/lib/), Why don't generate dynamic link library (.so files in the directory). The exception is the file libLTO.a and libLTO.so, why the library LTO were generated for static and dynamic both? How to control the

On Tue, May 1, 2018 at 10:52 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > Hi Vivek, > > > > Have you read the mailing list threads on this topic? I don’t believe > we’re quite ready to make the switch yet. There was a discussion last > October about what was left to be done. I’m sure it has been discussed > since then too. Here’s a link to the start of

Hi Vivek, bisect and optnone are certainly low hanging fruit in terms of implementation. On the other hand they need a cleaner design than they have now. E.g., OptBisect today is a managed static, which we absolutely should get rid of. Instead, bisect functionality can be much more cleanly implemented on top of the debug counters! While the function call for optnone doesn't strike me as

Hello LLVM-Devs, I am trying to get some starting points for working on following new pass manager related bugs: https://bugs.llvm.org/show_bug.cgi?id=28322 [PM] Remove use of old PM in the middle-end. https://bugs.llvm.org/show_bug.cgi?id=28323 [PM] Use new PM in production for Clang, LLD, libLTO, etc. middle-end https://bugs.llvm.org/show_bug.cgi?id=28321 [PM] Remove use of old PM in the

Hi, For lllvm 3.7 and before BUILD_SHARED_LIBS=ON would produce versioned shared libs like libLLVMLTO.so (symlink) libLLVMLTO.so.3.7 (symlink) libLLVMLTO.so.3.7.0 (real file) now it just builds an unversioned libLLVMLTO.so file which I believe is a problem because when a program links to llvm it generates a runtime dependency on libLLVMLTO.so instead of libLLVMLTO.so.3.7.0 which will break

As a point of clarification, optnone is already being handled by the pass itself in the legacy implementation. The skip[IR unit] functions are provided by the pass base classes, and the attribute is checked there. This happens any time the legacy wrapper is run, no matter how it is run. Regarding the opt-bisect design, I’m not particularly fond of the managed static either, but I do want to

Hello, LTO is currently the only library which is always built as shared, even under Windows. This actually seems to lead to failure using LLVM in another project under Windows, at least for me (the error message complains about "LTO-NOTFOUND.OBJ"). Switching it to a static library fixes the issue (again, at least for me under Windows). The change was made in:

Hello all, After reading OptBisect and DebugCounter related code and playing bit around it I have following simple design: - Add a debug counter for opt-bisect. Initilize it against option -opt-bisect-limit=<limit>. - DebugCounter is a singleton class so can be accessed by both new and legacy passmanager. We may need few more static method like getCounterIdForName(std::string &Name)

Hi Vivek, can you elaborate why you're looking for a one-size-fits-all solution? What is the noteworthy benefit over adding a new-pm specific implementation? Several changes you mention are purely for the benefit of supporting the legacy PM (which already has a working, tried, and tested solution). E.g. `getCounterIdForName`, the FIXMEs you mention, and the callbacks. All of these are

Hi Vivek, Have you read the mailing list threads on this topic? I don’t believe we’re quite ready to make the switch yet. There was a discussion last October about what was left to be done. I’m sure it has been discussed since then too. Here’s a link to the start of the October discussion. http://lists.llvm.org/pipermail/llvm-dev/2017-October/118280.html If you’d like to get involved, one

Is there a particular method one should used to build the libLTO.dylib from the llvm svn on darwin9? Unless I am confused, it seems that libLTO.dylib gets built when I do a configure and make directly in the llvm svn tree but not when I created separate llvm_objdir directory and execute configure and make within it. Thanks in advance for any clarifications. Jack

I puzzled out that the --with-pic option was required to cause the libLTO.dylib to be built. I must have done a make before directly in the lto tools subdirectory when I was building directly in the source tree. Jack

I'm trying to do a simple build from the git 8.0.0 sources. The sources seem to build OK but a link step fails from running out of memory. I need some clues how to figure out where the bottleneck might be. The cmake command is: cmake -G Ninja                                          \     -DLLVM_TARGETS_TO_BUILD=X86                         \    

Hello all, I'm a research assistant at the University of Wisconsin and we're trying to come up with a general way to run our whole program analysis over programs that may use different methods to perform the build. I saw some discussion that liblto could be used for this (and safecode successfully did it) for llvm 2.6 - 3.0, but that doesn't seem to be working the same way with llvm

Dear LLVMers, I'm currently working on creating an alternate libLTO.so that will run some whole-program analysis and transforms of mine during the final linking of an executable. The idea is for it to link all of the bitcode files together, run the regular LTO passes, and then run my passes. For Linux, I should be able to get the Gold linker to load my libLTO.so instead of the standard

Hi all, libLTO is exposing a very “stable” (in the sense of immutable) C API to be used by linkers (and binutils tools) that manipulate bitcode (like when performing LTO). I’m looking into relaxing the stability concern and design a policy for this API that would allow to deprecate and remove some the APIs exposed here. The MacOS linker (ld64) is one the users of libLTO, but there are others

Hi LLVM-Devs, When I try to configure LLVM v6.0 RC2 (SVN Rev #324869) on Windows (I haven't yet had a chance to try on Linux), I get a series of errors such as this: CMake Error at cmake/modules/AddLLVM.cmake:1333 (add_dependencies): The dependency target "(" of target "check-all" does not exist. Call Stack (most recent call first): CMakeLists.txt:937

Hi, We have been investigating an issue when running LTO with our proprietary linker, which links against libLTO dynamically. The issue is that when we pass -time-passes via the lto_codegen_debug_options function in the LTO C API, no time information is produced during compilation. The reason for this is that time information is stored in state owned by a ManagedStatic instance, and is only

Hi all, I just svn-updated the 2.5 branch on my machine and I noticed this warning during the build. *** Warning: Linking the shared library /home/maurice/installation/llvm/Debug/lib/libLTO.la against the non-libtool *** objects /home/maurice/installation/llvm/Debug/lib/LLVMCppBackend.o /home/maurice/installation/llvm/Debug/lib/LLVMMSIL.o /home/maurice/installation/llvm/Debug/lib/LLVMCBackend.o

On Saturday, March 4, 2017, Ryan Taylor <ryta1203 at gmail.com> wrote: > Why you can't still expand it through MUL with a Custom lowering? Or am I > missing something? > > Yes we can but problem occurs when we know that it is shift with constant value than if we return ISD::MUL with constant imm operand than LLVM will convert it to SHL again because the constant will be