similar to: [LLVMdev] Dynamic (JIT) type resolution

Nicholas, I guess you're trying to solve the fragile base-class problem by deferring field offset calculations until JIT compilation time? Perhaps I'm missing something, but can't you accomplish this by using external constants in the source program, to be supplied at JIT/link time? external constant i32 @obj.x.offs; external constant i32 @obj.y.offs; define

On Nov 5, 2007, at 8:27 PM, Nicolas Geoffray wrote: > I would like to implement an equivalent mechanism of function > callbacks > in the JIT, but for fields. Typically in Java, when you compile a > method, there may be some instructions (getfield, putfield) that > depend > on a type which is not yet resolved. > > I think the best way to do this in LLVM is to add an

Hi Gordon, Gordon Henriksen wrote: > Nicholas, > > I guess you're trying to solve the fragile base-class problem by > deferring field offset calculations until JIT compilation time? > > No. I'm deferring field offset calculation until /execution /time. > Perhaps I'm missing something, but can't you accomplish this by using > external constants in

Chris Lattner wrote: > > I don't think this is really the right way to go. Can you give an > example snippet of Java code that would need this and what you are > proposing? With a concrete example that shows how the lazy class > loading stuff works we can talk about different possibilities, > > Field operations in Java (getfield, putfield, getstatic, putstatic)

On Tue, 6 Nov 2007, Nicolas Geoffray wrote: > Field operations in Java (getfield, putfield, getstatic, putstatic) do > _not_ need what I'm proposing. What I'm proposing is just performance > related (just like method patching in callbacks is an optimization in > order to not call the callback everytime). > > Here's a simple example: consider class One: > >

Hello R experts I am googling and reading around, however, I can't get it working (perhaps because I do not understand much C, however, I'll give it a try). I am trying to include C++ code into an R routine, where the C++ code looks: #include <iostream> using namespace std; void foo (double* x, double* y, double* out) { out[0] = x[0] + y[0]; } Back in R, the command R CMD

On Apr 27, 2008, at 10:58 AM, Talin wrote: > I would certainly make use of this in my frontend. > > I suggest the names "getfield" and "setfield" for the two operations, > I agree that 'get/insertvalue' are pretty generic, and am welcome to suggestions. Get/set *field* imply that this applies only to structs, but it also works with arrays. I would

Dear R-experts! I am currently running a meta-analysis with the help of the great metafor package. However I have some difficulties setting up my raw data to enter it to the meta-analysis models. I have a group of subjects that have been measured in two continuous variables (A & B). I have the information about the mean of the two variables, the group size (n) and the standard deviations of

On Apr 27, 2008, at 12:49 PM, Nick Lewycky wrote: > Chris Lattner wrote: >> On Apr 27, 2008, at 10:58 AM, Talin wrote: >> >>> I would certainly make use of this in my frontend. >>> >>> I suggest the names "getfield" and "setfield" for the two >>> operations, >>> >> >> I agree that

I would certainly make use of this in my frontend. I suggest the names "getfield" and "setfield" for the two operations, since (to me anyway) "insert" implies adding something new, as opposed to overwriting an existing value. Chris Lattner wrote: > Hi all, > > For anyone interested, I posted two new ideas for changes to the LLVM > IR. The first is

Chris Lattner wrote: > On Apr 27, 2008, at 10:58 AM, Talin wrote: > >> I would certainly make use of this in my frontend. >> >> I suggest the names "getfield" and "setfield" for the two operations, >> > > I agree that 'get/insertvalue' are pretty generic, and am welcome to > suggestions. Get/set *field* imply that this applies

On 2008-04-27, at 15:56, Chris Lattner wrote: > On Apr 27, 2008, at 12:49 PM, Nick Lewycky wrote: > >> Chris Lattner wrote: >> >>> On Apr 27, 2008, at 10:58 AM, Talin wrote: >>> >>>> I would certainly make use of this in my frontend. >>>> >>>> I suggest the names "getfield" and "setfield" for the two

BGB wrote: > ok, here is another option then: > the stub is set up to manually modify the code near the return address (may > be arch specific and require spiffy use of assembler). > > That's not another option. That's what I want to do. > now, how you would go about implementing this is up to you. > And I need to know if I can currently do that with LLVM.

TL;DR: Have support in ADT for typed values packing into opaque scalar types - Code & design choices: https://reviews.llvm.org/D81580 - Usage: https://reviews.llvm.org/differential/changeset/?ref=2005337&whitespace=ignore-most - Example of rewrite: https://reviews.llvm.org/D81662 *CONTEXT* There are places in LLVM where we need to pack typed fields into opaque values. For instance,

Hi Guillaume, Thanks for the RFC. I'm generally +1 on the concept. Making bit field manipulation easier seems like a good overall goal given its prevalence in LLVM. As for the syntax, I tend to prefer that we don't pollute the namespace. Have you considered pushing the methods into the Bitfield class? Maybe something like: ``` uint8_t Storage = 0; using Amount =

Hi all, For anyone interested, I posted two new ideas for changes to the LLVM IR. The first is basically a cleanup, the second is a major new feature: Eliminating the 'Void' Type: http://nondot.org/sabre/LLVMNotes/EliminatingVoid.txt Aggregates as First Class Values: http://nondot.org/sabre/LLVMNotes/FirstClassAggregates.txt Thanks to Dan Gohman for convincing me that aggregates

Dear list, Given a linear mixed model (from lme4) I want to 1) first change the input dataset and then 2) change the model formula. I want this to happen in a function call; Please see below. Options 1) and 2) below work whereas 3) fails with the message > foo() Error in is.data.frame(data) : object 'beets2' not found Question: What is it one must to in case 3) to have R look

Hi all, I'm having trouble understanding how llvm determines if pointers alias. Consider the following two functions that each do a redundant load: define float @A(float * noalias %ptr1) {   %ptr2 = getelementptr float* %ptr1, i32 1024   %val1a = load float* %ptr1   store float %val1a, float* %ptr2   %val1b = load float* %ptr1   ret float %val1b } define float @B(float * noalias %ptr1,

quite some speed improvement indeed. attached the updated patch to apply to svn/trunk. j -------------- next part -------------- A non-text attachment was scrubbed... Name: theora-mmx.patch.gz Type: application/x-gzip Size: 8648 bytes Desc: not available Url : http://lists.xiph.org/pipermail/theora-dev/attachments/20040824/5a5f2731/theora-mmx.patch-0001.bin

Hello (Heinrich), I did not know I could do this. It doesn't seem to be documented anywhere. Thought this would be helpful to the fraction of the community using package R.oo. Note the call of a setMethodS3 method, xOne, in the setConstructorS3. This is extremely useful if xOne (in this case) is a very complex method (that you always want to be called every time you create a new object). If I