search for: getfields

Hi everyone, 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 intrinsic. The intrinsic would be only valid if we jit, and would be lowered only in

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

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 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

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 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

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

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 =

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 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

Hi all, This is a potentially very stupid question about MySQL <-> R interaction, but I have not been able to solve it. I'm just trying to connect R to my MySQL databse, and gets this: > library(RMySQL) Loading required package: methods > m <- dbDriver("MySQL") > con <- dbConnect(m,group="testdb") Process R segmentation fault at Wed Oct 16 07:04:30

Hi, I've got a long-running project whose data fits nicely into data.frame objects in R. As I accumulate more and more functions, I decided to switch to an OO approach so I can organize things better. Looking around at the various approaches to OO R, I came across R.oo, which seems nice. Where I'm currently stuck is getting my objects to be mutable. For example, in the following toy

...ough HashMap values iterator # while(itr.hasNext()) System.out.println(itr.next()); So, I took a stab at the ruby version: # I have a java hashmap called fields that was created using iText thusly reader = pdfreader.new( "pdf_file.pdf" ) @form = reader.getAcroFields() fields = @form.getFields() # this is a hashmap of all fields on form fields._classname # entere in irc displays: java.util.HashMap # So, following the java code above c = fields.values() itr = c.iterator() while itr.hasNext() p itr.next() end Instead of getting the field names, I get #<#<Class:0x2d47d74>:0x2...

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: > >

...fmtvprint.c fprint.c print.c runeseprint.c runesmprint.c runesnprint.c runevseprint.c seprint.c smprint.c snprint.c sprint.c vfprint.c vseprint.c vsmprint.c vsnprint.c dofmt.c dorfmt.c errfmt.c fcallfmt.c fltfmt.c fmt.c fmtfd.c fmtlock.c fmtprint.c fmtquote.c fmtrune.c fmtstr.c fmtvprint.c exits.c getfields.c pow10.c print.c qsort.c rune.c runestrlen.c seek.c strdup.c strtoll.c utflen.c utfrrune.c utfrune.c utfecpy.c utflen.c utfnlen.c utfrrune.c utfrune.c strecpy.c llvm-ar crvs /usr/local/inferno/MacOSX/386/lib/lib9.a dirstat-posix.o rerrstr.o errstr-posix.o getuser-posix.o charstod.o cleanname.o cre...