search for: tooloutputfil

There is no real technical requirement for this. Currently we work around the signal handlers by building with ENABLE_CRASH_OVERRIDES=NO, and carrying along the command line parsing code and ToolOutputFile isn’t really a big drain. This seemed to me like the cleanest way to accomplish a goal of mine. The goal I have is to be able to build an LLVM dylib and llc/opt/etc from the same CMake invocation where the dylib does not have crash overrides and signal handler hooks, but the tools do. There are...

...be this just isn’t the right separation. I can look into a solution to address our hackiness without creating a separate library. > > What other stuff do you think belongs in ToolsSupport that doesn't belong in Support? Looking back at the initial email, you have command line parsing and ToolOutputFile. > > We could split out command line parsing, but it doesn't seem worth it, given that we're still carrying regex support, Unicode conversion, dynamic library support, and other things that probably aren't absolutely necessary. > > What about splitting out a CrashRecovery...

...of functionality is the signal handlers. I'd like to propose migrating content that is specifically designed for tools into a new ToolsSupport library. My initial candidates for the new library would be; anything guarded by ENABLE_CRASH_OVERRIDES, and any functionality specific to tools (i.e. ToolOutputFile and eventually command line parsing— once it can be factored out). The primary goal of this is to make it easy for uses of LLVM that aren't command line tools to not include functionality that isn't required for that use case. Thoughts? -Chris

...> > On Oct 20, 2014, at 1:02 PM, Chris Bieneman <beanz at apple.com> wrote: > > There is no real technical requirement for this. Currently we work around > the signal handlers by building with ENABLE_CRASH_OVERRIDES=NO, and > carrying along the command line parsing code and ToolOutputFile isn’t > really a big drain. > > This seemed to me like the cleanest way to accomplish a goal of mine. The > goal I have is to be able to build an LLVM dylib and llc/opt/etc from the > same CMake invocation where the dylib does not have crash overrides and > signal handler hooks,...

> On Nov 6, 2014, at 3:00 PM, Reid Kleckner <rnk at google.com> wrote: > > On Thu, Nov 6, 2014 at 2:42 PM, Juergen Ributzka <juergen at apple.com <mailto:juergen at apple.com>> wrote: > I would have preferred the library to be moved out of the “Support” folder and have its own top-level library and include folder. > > +1, you will need to do this if you want

...02 PM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: >> >> There is no real technical requirement for this. Currently we work around the signal handlers by building with ENABLE_CRASH_OVERRIDES=NO, and carrying along the command line parsing code and ToolOutputFile isn’t really a big drain. >> >> This seemed to me like the cleanest way to accomplish a goal of mine. The goal I have is to be able to build an LLVM dylib and llc/opt/etc from the same CMake invocation where the dylib does not have crash overrides and signal handler hooks, but the too...

...docs on those fields indicate there is still a target default. How do I get the default relocation and codeModel? I'm still using the legacy::PassManager. Is there a new way to do the passes now? There docs still reference `tool_output_file*`*, but it appears the new name, in the header, is `ToolOutputFile`. https://llvm.org/doxygen/classllvm_1_1tool__output__file.html -- edA-qa mort-ora-y http://mortoray.com/ Creator of the Leaf language http://leaflang.org/ Streaming algorithms, AI, and design on Twitch https://www.twitch.tv/mortoray Twitter edaqa -------------- next part -----------...

2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org>: > Changing a header file somewhere and having to spend 10 minutes waiting > for a build leads to a lot of wasted developer time. > > The real culprit here is tablegen. Can we split support and ADT into two > - the parts that tablegen depends on and the parts that it doesn't? >

...pport/CommandLine.h" #include "llvm/Support/Debug.h" #include "llvm/Support/FormattedStream.h" #include "llvm/Support/ManagedStatic.h" #include "llvm/Support/PluginLoader.h" #include "llvm/Support/PrettyStackTrace.h" #include "llvm/Support/ToolOutputFile.h" #include "llvm/Support/Host.h" #include "llvm/Support/Signals.h" #include "llvm/Support/TargetRegistry.h" #include "llvm/Support/TargetSelect.h" #include "llvm/Target/TargetData.h" #include "llvm/Target/TargetMachine.h" #include &...

...neman <beanz at apple.com <mailto:beanz at apple.com>> wrote: >>>> >>>> There is no real technical requirement for this. Currently we work around the signal handlers by building with ENABLE_CRASH_OVERRIDES=NO, and carrying along the command line parsing code and ToolOutputFile isn’t really a big drain. >>>> >>>> This seemed to me like the cleanest way to accomplish a goal of mine. The goal I have is to be able to build an LLVM dylib and llc/opt/etc from the same CMake invocation where the dylib does not have crash overrides and signal handler ho...

...LowLevelTypeImpl.h > MachO.def > MachO.h > MipsABIFlags.h > OnDiskHashTable.h > PluginLoader.h > Registry.h > ScopedPrinter.h > SMLoc.h > Solaris.h > SourceMgr.h > SpecialCaseList.h > TargetParser.h > TargetRegistry.h > TargetSelect.h > TarWriter.h > ToolOutputFile.h > TrigramIndex.h > TypeName.h > Valgrind.h > Wasm.h > YAMLParser.h > YAMLTraits.h > > > So, as a very crude first attempt, you call the first group of stuff > "Base", the second group "Support", and add a dependency from Support to > Base. Th...

Guillermo, > I'm sorry I forgot to mention I am compiling the bitcode using the JIT. The > actual error, I get when I'm trying to get the function to the pointer. I'm > using a custom front end that translates Android's Dalvik bytecode into LLVM > bitcode based on Android ICS's modified LLVM version. ARM JIT is broken in many ways. So, what you're seeing is

...LowLevelTypeImpl.h > MachO.def > MachO.h > MipsABIFlags.h > OnDiskHashTable.h > PluginLoader.h > Registry.h > ScopedPrinter.h > SMLoc.h > Solaris.h > SourceMgr.h > SpecialCaseList.h > TargetParser.h > TargetRegistry.h > TargetSelect.h > TarWriter.h > ToolOutputFile.h > TrigramIndex.h > TypeName.h > Valgrind.h > Wasm.h > YAMLParser.h > YAMLTraits.h > YAML Parser as well. -- Mehdi > > > So, as a very crude first attempt, you call the first group of stuff > "Base", the second group "Support", and add a...

...Pool.cpp.o CMakeFiles/LLVMSupport.dir/StringSaver.cpp.o CMakeFiles/LLVMSupport.dir/StringRef.cpp.o CMakeFiles/LLVMSupport.dir/SystemUtils.cpp.o CMakeFiles/LLVMSupport.dir/TargetParser.cpp.o CMakeFiles/LLVMSupport.dir/ThreadPool.cpp.o CMakeFiles/LLVMSupport.dir/Timer.cpp.o CMakeFiles/LLVMSupport.dir/ToolOutputFile.cpp.o CMakeFiles/LLVMSupport.dir/Triple.cpp.o CMakeFiles/LLVMSupport.dir/Twine.cpp.o CMakeFiles/LLVMSupport.dir/Unicode.cpp.o CMakeFiles/LLVMSupport.dir/YAMLParser.cpp.o CMakeFiles/LLVMSupport.dir/YAMLTraits.cpp.o CMakeFiles/LLVMSupport.dir/raw_os_ostream.cpp.o CMakeFiles/LLVMSupport.dir/raw_ostre...

....cpp for Release build llvm[1]: Compiling TargetRegistry.cpp for Release build llvm[1]: Compiling ThreadLocal.cpp for Release build llvm[1]: Compiling Threading.cpp for Release build llvm[1]: Compiling TimeValue.cpp for Release build llvm[1]: Compiling Timer.cpp for Release build llvm[1]: Compiling ToolOutputFile.cpp for Release build llvm[1]: Compiling Triple.cpp for Release build llvm[1]: Compiling Twine.cpp for Release build llvm[1]: Compiling Valgrind.cpp for Release build llvm[1]: Compiling circular_raw_ostream.cpp for Release build llvm[1]: Compiling raw_os_ostream.cpp for Release build llvm[1]: Comp...

...; separation. I can look into a solution to address our hackiness without >> creating a separate library. >> > > What other stuff do you think belongs in ToolsSupport that doesn't belong > in Support? Looking back at the initial email, you have command line > parsing and ToolOutputFile. > > We could split out command line parsing, but it doesn't seem worth it, > given that we're still carrying regex support, Unicode conversion, dynamic > library support, and other things that probably aren't absolutely necessary. > > What about splitting out a Crash...

hacker cling wrote: > Hello all, > I was playing with LLVM pass. I changed the > lib/Transforms/Hello/Hello.cpp 's content to be my own pass. Then I make > install the pass and use an example test1.c to see whether it works or > not. When I run example using the following command: > clang -emit-llvm test1.c -c -o test1.bc > opt -load

Hello all, I was playing with LLVM pass. I changed the lib/Transforms/Hello/Hello.cpp 's content to be my own pass. Then I make install the pass and use an example test1.c to see whether it works or not. When I run example using the following command: clang -emit-llvm test1.c -c -o test1.bc opt -load ../build_llvm/Debug+Asserts/lib/LLVMHello.so -hello < test1.bc > /dev/null It

Hi, I'm sorry I forgot to mention I am compiling the bitcode using the JIT. The actual error, I get when I'm trying to get the function to the pointer. I'm using a custom front end that translates Android's Dalvik bytecode into LLVM bitcode based on Android ICS's modified LLVM version. Thanks, On Mon, Feb 20, 2012 at 7:55 PM, James Molloy <James.Molloy at arm.com>

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, >> >> >>