search for: targetselect

...riginal Message----- > From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of NAKAMURA Takumi > Sent: Saturday, July 21, 2012 8:05 PM > To: llvm-commits at cs.uiuc.edu > Subject: [llvm-commits] [llvm] r160610 - /llvm/trunk/lib/ExecutionEngine/TargetSelect.cpp > > Author: chapuni > Date: Sat Jul 21 22:04:57 2012 > New Revision: 160610 > > URL: http://llvm.org/viewvc/llvm-project?rev=160610&view=rev > Log: > ExecutionEngine/TargetSelect.cpp: Override default triple as LLVM_HOSTTRIPLE. > > In current implementation, JI...

So, I'm setting about trying to fix the layering of TargetSelect.h (& TargetRegistry.h, but haven't really got to its issues yet). The issues can be demonstrated fairly plainly by moving any/all of TargetSelect.h's functions out of line. Pretty much all programs in LLVM fail to link because libSupport doesn't actually depend on all the targets,...

...cfg file. Does that sound right? My concern is that I don't quite know how to predict what will happen on some of the buildbots aside from checking something in and seeing what happens. Hopefully any obvious problems will be caught in code review. Aside from the testing, it seems to me that TargetSelect should always use the Module target triple, and if it isn't compatible with the host environment then it will just fail. -Andy -----Original Message----- From: NAKAMURA Takumi [mailto:geek4civic at gmail.com] Sent: Tuesday, September 11, 2012 5:13 PM To: Kaylor, Andrew Cc: llvm-commits at cs...

...appen on some of the buildbots aside from checking something in and seeing what happens. Hopefully any obvious problems will be caught in code review. I can investigate failures if they happened in my builders. All of my builders are in my room :) > Aside from the testing, it seems to me that TargetSelect should always use the Module target triple, and if it isn't compatible with the host environment then it will just fail. It should be better that Target may be overridden. It was the reason why I tweaked TargetSelect(). ...Takumi

...functions are called > only once, etc. Though that does seem a little unfortunate on principle but > not much practical problem with it, I think. It'd be nice in theory to be > able to depend on the right library, have that bring in the right > dependencies, etc. > As designed, TargetSelect.h doesn't fit neatly into the normal way of arranging libraries. I'd mark it textual and leave it alone. Alternatively, we could make AllTargetsDescs and AllTargetsInfos and all the other synthetic libraries in CMake into real libaries and sink the bodies of these inline functions into eac...

...; only once, etc. Though that does seem a little unfortunate on principle but >> not much practical problem with it, I think. It'd be nice in theory to be >> able to depend on the right library, have that bring in the right >> dependencies, etc. >> > > As designed, TargetSelect.h doesn't fit neatly into the normal way of > arranging libraries. > Not sure about that - yeah, it's a bit of the degenerate case, for sure. But in a build system like Google's, where a lib has other lib dependencies (whereas in the LLVM CMake build it seems libs don't depe...

...for "all configured targets" which would be just fine. Thanks --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Chandler Carruth via llvm-dev Sent: Wednesday, December 06, 2017 5:14 PM To: Eric Christopher Cc: llvm-dev; Richard Smith Subject: Re: [llvm-dev] TargetSelect.h and layering FWIW, I think the end state we'll end up wanting is what you describe in your email: fine grained dependencies and something like libLLVM{AllTargets,NativeTarget}{AsmPrinters,AsmParsers,Descs,Disassemblers,Infos} I think the "Native" thing can be solved by having a CM...

...unfortunate on principle but >>>> not much practical problem with it, I think. It'd be nice in theory to be >>>> able to depend on the right library, have that bring in the right >>>> dependencies, etc. >>>> >>> >>> As designed, TargetSelect.h doesn't fit neatly into the normal way of >>> arranging libraries. >>> >> >> Not sure about that - yeah, it's a bit of the degenerate case, for sure. >> >> But in a build system like Google's, where a lib has other lib >> dependencies (w...

...--cxxflags > --ldflags --libs core jit native` -o bug > > I noticed something very recently changed w.r.t. the way LLVM's > libraries are built (no more .o files). Could this have something to > with it? I *just* changed this. :) For JIT applications, please include llvm/Target/TargetSelect.h and call the llvm::InitializeNativeTarget() function before creating an EE. -Chris

Hi, The LLVM headers llvm-c/Target.h and llvm/Target/TargetSelect.h include the header llvm/Config/config.h, which defines common macros, such as PACKAGE_BUGREPORT. If a project that uses LLVM includes any of these headers, the project's own macros of the same names can be redefined. Most advice I have seen says that installed headers should never define...

Hello, Maybe my version (LLVM 2.5) is incomplete... now get this error: toy.cpp:11:38: error: llvm/Target/TargetSelect.h: No such file or directory How can I get this file? Regards, Juan Carlos On Wed, Jun 17, 2009 at 12:51 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jun 17, 2009, at 9:46 AM, Paul Melis wrote: > > > FWIW, I'm also suddenly experiencing segfaults in code th...

"Joel E. Denny" <jdenny at etinternational.com> writes: > The LLVM headers llvm-c/Target.h and llvm/Target/TargetSelect.h include > the header llvm/Config/config.h, which defines common macros, such as > PACKAGE_BUGREPORT. If a project that uses LLVM includes any of these > headers, the project's own macros of the same names can be redefined. > > Most advice I have seen says that installed hea...

...se_31, revision 155051 attached. - Yury -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120509/c147de15/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: TargetSelect.patch Type: application/octet-stream Size: 488 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120509/c147de15/attachment.obj>

Hello, After I try making a clean build and got the following error: llvm[3]: Compiling EDDisassembler.cpp for Release build In file included from /llvm/include/llvm/Target/TargetSelect.h:38, from /llvm/lib/MC/MCDisassembler/EDDisassembler.cpp:37: /llvm/stage1/include/llvm/Config/AsmPrinters.def: In function ‘void LLVMInitializeX86TargetAsmPrinter()’: /llvm/stage1/include/llvm/Config/AsmPrinters.def:27: error: redefinition of ‘void LLVMInitializeX86TargetAsmPrinte...

...Instructions.h" #include "llvm/IR/LLVMContext.h" #include "llvm/IR/Module.h" #include "llvm/IR/Type.h" #include "llvm/IR/Verifier.h" #include "llvm/Support/Casting.h" #include "llvm/Support/ManagedStatic.h" #include "llvm/Support/TargetSelect.h" #include "llvm/Support/raw_ostream.h" And here is the simple IR code that I'm trying to JIT compile and execute in memory: ; ModuleID = 'Program' source_filename = "Program" define i32 @fib(i32) { entry: %i = alloca i32 store i32 %0, i32* %i ret i32...

...cutionEngine/CMakeFiles/LLVMExecutionEngine.dir/ExecutionEngineBindings.cpp.o lib/ExecutionEngine/CMakeFiles/LLVMExecutionEngine.dir/GDBRegistrationListener.cpp.o lib/ExecutionEngine/CMakeFiles/LLVMExecutionEngine.dir/SectionMemoryManager.cpp.o lib/ExecutionEngine/CMakeFiles/LLVMExecutionEngine.dir/TargetSelect.cpp.o lib/libLLVMCore.so.3.7.0svn lib/libLLVMMC.so.3.7.0svn lib/libLLVMObject.so.3.7.0svn lib/libLLVMRuntimeDyld.so.3.7.0svn lib/libLLVMSupport.so.3.7.0svn -Wl,-rpath,"\$ORIGIN/../lib" && : lib/ExecutionEngine/CMakeFiles/LLVMExecutionEngine.dir/ExecutionEngineBindings.cpp.o: In f...

Chris Lattner wrote: > For JIT applications, please include llvm/Target/TargetSelect.h and > call the llvm::InitializeNativeTarget() function before creating an EE. Couldn't the EE creation functions do this call automatically if no target has been set yet, instead of just returning a null pointer? For the sake of backward compatibility. -- Dr. Albert Gr"af Dept. o...

...ionEngine.h" #include "llvm/ExecutionEngine/JIT.h" #include "llvm/LLVMContext.h" #include "llvm/Module.h" #include "llvm/PassManager.h" #include "llvm/Analysis/Verifier.h" #include "llvm/Target/TargetData.h" #include "llvm/Target/TargetSelect.h" #include "llvm/Transforms/Scalar.h" #include "llvm/Support/IRBuilder.h" ) Any help? -- View this message in context: http://old.nabble.com/Installing-the-Library-tp29167350p29167350.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

I have cleaned up the code somewhat that Olivier wrote and split up the patch into three pieces. This first is to make the MCJIT not have to initialize all asm printers, but only the native one. - Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0018_nativeasmprinterinit.patch Type: text/x-diff Size: 12993 bytes Desc: not available URL:

Hi Jan, Applied with edits in r109996, thanks! I wasn't happy about the change to add "Target" everywhere -- I just added a local hack in TargetSelect.h to workaround this. We should really change the definition of LLVM_NATIVE_TARGET, but I am not in a configure hacking mood. - Daniel On Wed, Jul 28, 2010 at 10:39 AM, Jan Sjodin <jan_sjodin at yahoo.com> wrote: > I have cleaned up the code somewhat that Olivier wrote and split up the...