similar to: TargetSelect.h and layering

Displaying 20 results from an estimated 700 matches similar to: "TargetSelect.h and layering"

2017 Dec 07
2
TargetSelect.h and layering
Could you guys clarify one thing for me? It sounds like the idea is that the current model of configuring the selection of targets would go away, to be replaced by an all-or-native-only switch. Sometimes I like to configure X86+ARM because that reduces rebuild time and still gets me the vast majority of debug-info tests. Or maybe you're using "all" as a shorthand for "all
2017 Dec 07
2
TargetSelect.h and layering
My only alternate ideas are: a) To heck with this only a single target thing. b) Autogenerate the entire file and library support as part of the build and have the various functions "defined" in the appropriate libraries. I don't really think a) is feasible, and b) is a bit of a stretch too. :\ -eric On Mon, Dec 4, 2017 at 5:37 PM David Blaikie <dblaikie at gmail.com>
2017 Nov 28
2
TargetSelect.h and layering
On Tue, Nov 28, 2017 at 11:23 AM, David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Alternatively we can really say this header is a textual header - it's > included generally only once in a whole program, the functions are called > only once, etc. Though that does seem a little unfortunate on principle but > not much practical problem with it, I think.
2012 Sep 12
2
[LLVMdev] [llvm-commits] [llvm] r160610 - /llvm/trunk/lib/ExecutionEngine/TargetSelect.cpp
Andy, Yes, it was wrong, as long as RemoteTarget is available for the target. If you would revert it, please consider then; - non-MCJIT stuff - Running different environment on the JIT e.g.) --build=--host=i686-linux --target=x86_64-linux - Host-incapable target on the JIT e.g.) --build=--host=x86_64-linux ---target=i686-mingw32 If JIT is unavailable for the default target, tests
2017 Nov 28
1
TargetSelect.h and layering
On Tue, Nov 28, 2017 at 11:27 AM Reid Kleckner <rnk at google.com> wrote: > On Tue, Nov 28, 2017 at 11:23 AM, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Alternatively we can really say this header is a textual header - it's >> included generally only once in a whole program, the functions are called >> only once, etc. Though
2012 Sep 12
0
[LLVMdev] [llvm-commits] [llvm] r160610 - /llvm/trunk/lib/ExecutionEngine/TargetSelect.cpp
Hi Takumi, I'm a bit confused as to what is supposed to happen in the cross building scenarios. For instance, if host=x86_64-linux and target=i686-mingw32, what should the MCJIT tests do? Should they be suppressed because the architectures don't match? If so, what about the case where host=x86_64-linux and target=x86_64-mingw32? I'm modifying the MCJIT tests so that they will
2012 Sep 13
1
[LLVMdev] [llvm-commits] [llvm] r160610 - /llvm/trunk/lib/ExecutionEngine/TargetSelect.cpp
2012/9/13 Kaylor, Andrew <andrew.kaylor at intel.com>: > I'm a bit confused as to what is supposed to happen in the cross building scenarios. For instance, if host=x86_64-linux and target=i686-mingw32, what should the MCJIT tests do? Should they be suppressed because the architectures don't match? If so, what about the case where host=x86_64-linux and target=x86_64-mingw32?
2013 Feb 18
1
[LLVMdev] [llvm-c] Proposal: Make LLVMInitializeNativeTarget and co. non-inline
Hi, when building llvm as a shared library LLVMInitializeNativeTarget and co. (located in llvm/Support/TargetSelect) will not get exported as symbol into the shared library, because they are static inline. Since they are functions defined in the C API no one else inside LLVM calls them, which results in them not being exported. This is, of course, no problem for C programs using the C API,
2012 May 13
1
[LLVMdev] Unable to link in X86AsmParser.cpp into lli
Hi, Using the trunk of svn. I'm trying to get inline-asm working on X86. So I added call to: > InitializeNativeTargetAsmParser() during initialization. However, this causes a linking error: > llvm[2]: Linking Debug+Asserts executable lli > /local/mnt/workspace/ashoknn/crd/neo/llvm/proto/llvmsvn/build/tools/lli/Debug+Asserts/lli.o: In function
2014 Apr 11
2
[LLVMdev] Proposal: Move host CPU auto-detection out of the TargetMachine
On Fri, Apr 11, 2014 at 3:58 PM, Jim Grosbach <grosbach at apple.com> wrote: > > Now, one additional thing we could do (outside the scope of this proposal) > is also implement a fuzzer of some kind to look for target tests that don’t > have an explicit arch/feature/whatever setting on the RUN line and run it > with all available -mcpu= values and see if it still passes (which
2012 May 14
0
[LLVMdev] MCJIT
On 5/14/2012 10:40 AM, Ashok Nalkund wrote: >> >> Hm. OK, that's odd. It should change which constructor gets called in EngineBuilder::create() (which is in lib/ExecutionEngine/ExecutionEngine.cpp). Are you perhaps calling setUseMCJIT(true) after having already called create()? Can you step through EngineBuilder::create() and see what's happening there? >> >> -Jim
2012 May 14
2
[LLVMdev] MCJIT
On May 14, 2012, at 11:12 AM, Ashok Nalkund <ashoknn at qualcomm.com> wrote: > On 5/14/2012 10:40 AM, Ashok Nalkund wrote: >>> >>> Hm. OK, that's odd. It should change which constructor gets called in EngineBuilder::create() (which is in lib/ExecutionEngine/ExecutionEngine.cpp). Are you perhaps calling setUseMCJIT(true) after having already called create()? Can
2012 May 14
2
[LLVMdev] MCJIT
On 5/14/2012 10:28 AM, Jim Grosbach wrote: > > On May 14, 2012, at 10:21 AM, Ashok Nalkund<ashoknn at qualcomm.com> wrote: > >> On 5/14/2012 9:51 AM, Jim Grosbach wrote: >>> >>>>> >>>>> If you're hitting that code, you're running the old JIT (which does indeed not support inline assembly), not the MCJIT. >>>>>
2010 Aug 03
2
[LLVMdev] llvm/Config/config.h namespace problem
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 such common macros. Thus, an
2009 Jun 17
0
[LLVMdev] Segmentation fault - Kaleidoscope
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
2010 Aug 03
0
[LLVMdev] llvm/Config/config.h namespace problem
"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
2012 May 09
2
[LLVMdev] Null pointer dereference
Hi all, Writing my own LLVM client I've noticed a potential null pointer dereference in EngineBuilder::selectTarget. The class has an optional pointer to the ErrorStr, which can be initialzied through setErrorStr() method. Although, it's strictly optional, selectTarget doesn't verify its value before assignment. Please find patch for branch release_31, revision 155051 attached. -
2009 Jun 17
10
[LLVMdev] Segmentation fault - Kaleidoscope
On Jun 17, 2009, at 9:46 AM, Paul Melis wrote: > FWIW, I'm also suddenly experiencing segfaults in code that used to > work > a few days ago (I'm using svn). This may be unrelated to the problem > described below, but perhaps it's the same thing. > > In my case it seems that creating an ExecutionEngine has changed. I > used > to do > > Module* Mod
2010 Aug 02
2
[LLVMdev] Problem building llvm after r109996 (Add InitializeNativeTargetAsmPrinter())
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()’:
2018 May 11
2
About Error: Interpreter has not been linked in
Hello, When I try to create execution engine I do get "*Interpreter has not been linked in.*" error and EngineBuilder returns NULL. Here is the line I use to create execution engine: auto executionEngine = llvm::EngineBuilder(std::move(m_module)).setErrorStr(&error).create(); Here are all headers I have included: #include "llvm/ADT/STLExtras.h" #include