similar to: [LLVMdev] MCJIT handling of linkonce_odr

Hi Keno, The part that scares me a bit is > and then adjust the other methods to not > bail out two quickly when encountering a weak symbol. I would very much appreciate if you could implement this; I don't have enough knowledge of the MCJIT nor llvm CodeGen internals... I will happily try it out and provide you with feedback, though! :-) Thank you *so* much for your fast reaction!

Hi, This is a question on how to resolve weak symbols from the binary for symbols that are also llvm::Module-local. Currently, the JIT seems to favor resolving to module-local symbols over existing symbols: $ cat symbols.cxx extern "C" int printf(const char*,...); template <class T> struct StaticStuff { static T s_data; }; template <class T> T

On 7/16/19 6:04 AM, Richard W.M. Jones wrote: > A Closure is a list of (usually one, but can be more) closures. In C > there is also a singe ‘void *user_data’ parameter which is passed by > the caller into the function and through as the first parameter of > each callback invocation. > > By grouping the previously separate Opaque and Callback* parameters > together we can

Hi, what to do, if the kernel hangs on boot time with: megaraid: ABORTING-1 cmd=12 <c=0 t=0 l=0> megaraid: ABORTING-1[d7] fw owner Konrad Naumann _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

Hi, we want to implement a C++ interpreter using LLVM and clang, to replace our existing one <http://root.cern.ch/drupal/content/cint> that is used as part of a data handling and analysis environment <http://root.cern.ch>. We plan to keep the set of features that our current interpreter offers, e.g. calls into and out of libraries, dynamic scoping, unloading of code, and a prompt. I

2009/8/31 Axel Naumann <Axel.Naumann at cern.ch>: > we want to implement a C++ interpreter using LLVM and clang Isn't clang going on that direction anyway? cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm

[RFC because generated OCaml code needs the same treatment, but I ran out of time to play with that. At least 'make -C python check' passes, although coverage is not complete yet, as there is no python/t/5XX-pread-structured-callback.py...] [Also RFC because I'm not sure if the use of a record type for 'callback' is the best approach or most idiomatic OCaml - but hey, it

https://bugs.freedesktop.org/show_bug.cgi?id=89186 Bug ID: 89186 Summary: Artifacts after waking up from suspend Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee:

Posting now that I got something to compile (at the expense of breaking OCaml bindings), but I'm open to ideas on how to improve it. Eric Blake (2): generator: Tweak print_c_arg_list to take alternate first arg RFC: generator: Handle shared callbacks in Python generator/generator | 556 ++++++++++++++++++++++---------------------- 1 file changed, 280 insertions(+), 276 deletions(-) --

Hi, is there an option to build LLVM's libs (and maybe clangs, but that's for later :-) as shared libraries? It's not --enable-shared :-) If it doesn't exist: is there any interest to have it? It would reduce my build time considerably... Cheers, Axel.

Mutable (Int n) => int *n This can currently only be used for callback arguments of type int (not for other types, nor for any ordinary function arguments), but it could be implemented more generally in future. --- generator/generator | 75 +++++++++++++++++++++++++++++++++++++-------- 1 file changed, 63 insertions(+), 12 deletions(-) diff --git a/generator/generator b/generator/generator

Indeed, an awesome project and an excellent report! Code size doesn't really get much attention, so the level of detail and the strong roadmap is refreshing. Hopefully, the project will provide execution times along with code-size > reductions. > I doubt it. Outlining will (almost?) always make for slower code due to a lot more calls being made. But that's ok for embedded targets,

Hi, I ran into a problem migrating cling (finally!) to MCJIT: When an ("outer") MCJIT's finalization / llvm::RuntimeDyldImpl::resolveExternalSymbols() is called and a symbol is not known, cling can help by loading the suitable library and providing the symbol. It compiles the relevant C++ header as part of loading the library. This compilation emits symbols through the MCJIT. That

A Closure is a list of (usually one, but can be more) closures. In C there is also a singe ‘void *user_data’ parameter which is passed by the caller into the function and through as the first parameter of each callback invocation. By grouping the previously separate Opaque and Callback* parameters together we can avoid the awkward situation where we have to scan through the argument list to try

As before, but this one has working Python bindings. OCaml still TBD. Rich.

Axel Naumann <Axel.Naumann at cern.ch> writes: > is there an option to build LLVM's libs (and maybe clangs, but that's > for later :-) as shared libraries? It's not --enable-shared :-) If it > doesn't exist: is there any interest to have it? It would reduce my > build time considerably... With cmake it is BUILD_SHARED_LIBS http://www.llvm.org/docs/CMake.html

Hi Óscar, On 2009-10-08 00:49, Óscar Fuentes wrote: > Axel Naumann <Axel.Naumann at cern.ch> writes: >> is there an option to build LLVM's libs (and maybe clangs, but that's >> for later :-) as shared libraries? > > With cmake it is BUILD_SHARED_LIBS > > http://www.llvm.org/docs/CMake.html Great! So I must use CMake instead of configure / make to get

Hi Andrew, Thanks for this great work and presentation, I've also a huge interest in code size reduction. I already looked at the first IR Outliner proposal, and I really like your more general approach. I wanted to look at the impact on ARM targets, and managed to apply your patchset up to D87311 (the remaining ones which are related to call instructions and GEP need to be reworked to be

----- Original Message ----- > From: "Eric Christopher" <echristo at gmail.com> > To: "Reid Kleckner" <rnk at google.com>, "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Tuesday, November 29, 2016 11:34:56 AM > Subject: Re: [llvm-dev] RFC: Add an "interposible" linkage

On Mon, Oct 5, 2009 at 8:27 PM, Axel Naumann <Axel.Naumann at cern.ch> wrote: > Hi, > > #include "JIT.h" will do. Thanks. That was exactly what I needed to progress to the next error ("Unable to find target for this triple (no targets are registered)") As soon as I get this front-end working with the trunk, I'll start submitting patches that add calls to