similar to: [LLVMdev] Hooking the global symbol resolver

Hi Jonathan, In the context of a static compiler, I would recommend that you implement your own “on the side” symbol table in order to track this state and perform on-demand instantiation as required. It is worthwhile to consider the LLVM module to be a passive output sink, not an active object. The JIT compiler, by contrast, is an active object, cooperating with its environment via

On Thu, 2008-03-27 at 07:44 -0400, Gordon Henriksen wrote: > In the context of a static compiler, I would recommend that you > implement your own “on the side” symbol table in order to track this > state and perform on-demand instantiation as required. It is > worthwhile to consider the LLVM module to be a passive output sink, > not an active object. I think I understand what you

"Jonathan S. Shapiro" <shap at eros-os.com> writes: [snip] > if (!(sym = llvm_resolve_global(GlobalScope, symName))) > some_failure_action(); > > it would now look something like: > > sym = llvm_resolve_global(GlobalScope, symName); > if (!sym && frontend_has_symbol_generator > && frontend_generate_symbol(symname)) >

On Wed, 2008-03-26 at 23:48 +0100, Óscar Fuentes wrote: > "Jonathan S. Shapiro" <shap at eros-os.com> writes: > My front-end is very similar to yours in the feature of the multiple > instantiations on demand, etc. Oscar: after you have a chance to read my recent reply to Gordon, would you be kind enough to let me know whether you still believe the situations are similar.

"Jonathan S. Shapiro" <shap at eros-os.com> writes: [snip] > 4. Is there a better/cleaner approach? What other options should I > consider? My front-end is very similar to yours in the feature of the multiple instantiations on demand, etc. One thing I learnt about LLVM is that it's philosophy is to be a friendly backend for frontends, but whatever your frontend

On Tue, Apr 4, 2017 at 12:36 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > On 2017-Apr-04, at 12:12, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >>

Hi, I'm trying to use a list of symbols as one of the values to be substituted in a substitute expression, but I can't figure out how to write the correct expression for my problem. Let me illustrate a simple example of what I'm trying to do. The following code snippet will evaluate to '5': symname <- 'foo' foo <- 5 expr <- substitute(c(expr), list(expr =

On Tue, 2008-05-06 at 23:18 -0700, Chris Lattner wrote: > > 1) Is there a way to declare an integer type in the IR that represents > > "an int the same size as a pointer" without specifying exactly the > > size > > of a pointer? > > No. Chris: There are other languages that specify a "word" type along these lines. Would it be worth considering

Michael, Overall the code looks good. 80-cols: 2046 FMF.UnsafeAlgebra = 0 != (Record[OpNum] & (1 << bitc::FMF_UNSAFE_ALGEBRA)); 2047 FMF.NoNaNs = 0 != (Record[OpNum] & (1 << bitc::FMF_NO_NANS)); 2048 FMF.NoInfs = 0 != (Record[OpNum] & (1 << bitc::FMF_NO_INFS)); 2049 FMF.NoSignedZeros = 0 !=

On May 6, 2008, at 11:49 PM, Jonathan S. Shapiro wrote: > On Tue, 2008-05-06 at 23:18 -0700, Chris Lattner wrote: >>> 1) Is there a way to declare an integer type in the IR that >>> represents >>> "an int the same size as a pointer" without specifying exactly the >>> size >>> of a pointer? >> >> No. > > Chris: > >

Another round of improved patches, and a patch for documentation changes to LangRef. * Make comments more up to date * Use 'arcp' instead of 'ar' * Use logical || Still based off of r168110 On Nov 15, 2012, at 3:31 PM, Michael Ilseman <milseman at apple.com> wrote: > > On Nov 15, 2012, at 3:23 PM, Joe Abbey <joe.abbey at gmail.com> wrote: >

Hi, On 2020-09-25 16:38:41 -0700, Andres Freund via llvm-dev wrote: > On 2020-09-24 16:34:30 -0700, Lang Hames wrote: > > If anyone wants to check out the OrcV1 removal branch and provide feedback > > now is the time. Otherwise I will aim to land the work in the mainline > > early next week. > > I'm trying to get it to work with postgres. Unfortunately this week

Hi, Not sure whether this matches your use case, but the Orc-based JIT used in LLI appears to be using `llvm::orc::LocalCXXRuntimeOverrides` (http://llvm.org/doxygen/classllvm_1_1orc_1_1LocalCXXRuntimeOverrides.html) to override `__cxa_atexit`: https://github.com/llvm-mirror/llvm/blob/release_50/tools/lli/OrcLazyJIT.h#L74

Hi all, I've been looking into how to make llvm bitcode files smaller. There is one simple change that appears to shrink linked bitcode files by about 15%. See this spreadsheet for some rough data: https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E The change is in how operand ids are encoded in bitcode files. Rather than use an "absolute

>>> Please add a generous block comment to >>> llvm/include/llvm/Bitcode/LLVMBitCodes.h above the new enum >>> explaining >>> what the difference is though. :) >> > > Should have said: > >> Should I take the same approach to the encoding of pointer types in >> the types table? PointerTypes are a bit easier. The code to write them

I've stumbled upon a small bug/inconsitency in do_External and do_dotcall: Here's an example: % LC_ALL=C R --vanilla < symname-bug.R R version 2.8.0 (2008-10-20) *snip* > options(error=expression(0)) > ## Call 'R_GD_nullDevice' with incorrect parameter count: > .Call("R_GD_nullDevice", 1) Error in .Call("R_GD_nullDevice", 1) :

On 2008-05-07, at 03:05, Chris Lattner wrote: > On May 6, 2008, at 11:49 PM, Jonathan S. Shapiro wrote: > >> There are other languages that specify a "word" type along these >> lines. Would it be worth considering adding such a type to the IR, >> or is there a reason not to do so that I am failing to see? > > What would this be used for? How is it

Hi Jan, > I've been looking into how to make llvm bitcode files smaller. There is one > simple change that appears to shrink linked bitcode files by about 15%. See > this spreadsheet for some rough data: > > https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E the improvement is wonderful! ... > In any case, the patch is attached if

On Nov 24, 2007, at 7:47 PM, Christopher Lamb wrote: > > On Nov 21, 2007, at 6:22 PM, Chris Lattner wrote: > >> On Wed, 21 Nov 2007, Christopher Lamb wrote: >>>> Unlike alignment and volatility, I think that the address space >>>> qualifier >>>> should be represented explicitly in the type system. The >>>> reason for this

This is not, strictly speaking, an LLVM issue, but it is an implementation matter that a compiler using LLVM needs to handle. I've got resolutions for other platforms, but I'm not seeing how to get this done for PowerPC, and I'ld appreciate suggestions or pointers. For BitC procedures that require an environment pointer, our general approach has been to construct a heap-allocated