search for: getfield

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 the codegen part (don't know yet if it would be in the target dependent or target independent p...

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 intrinsic. The > intrinsic would be only valid if we jit, and would be lowered only in > the codegen part (don't know yet if it would be in the target &...

...ally 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) 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: public class One {...

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 actually prefer get/insert *element* but ins...

...no need to modify LLVM. On 2007-11-05, at 23:27, Nicolas Geoffray wrote: > Hi evaeryone, > > 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 > the codegen part (don't know yet if it would be in the target &...

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 'get/insertvalue' are pretty generic, and am welcome to >> suggestions. Get/set *field* imply that this applies only to >> structs, >> but it also works wit...

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

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 only to structs, > but it also works with arrays. I would actually prefer get/in...

...e: > 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 'get/insertvalue' are pretty generic, and am welcome >>> to suggestions. Get/set *field* imply that this applies only to >>> structs, but it also works wit...

...-05, at 23:27, Nicolas Geoffray wrote: > > >> Hi evaeryone, >> >> 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 >> the codegen part (don't know yet if it wo...

...ld is non zero. > > Now, the three syntaxes: > > 1. Current API, purely functional > code: https://reviews.llvm.org/D81580 > > uint8_t Storage = 0; > using Amount = Bitfield<unsigned, 0, 4>; > > setField<Amount>(Storage, true); > unsigned Value = getField<Amount>(Storage); > bool Cond = testField<Amount>(Storage); > > 2. A more Object Oriented API > code: https://reviews.llvm.org/D82058 > > uint8_t Storage = 0; > using Amount = Bitfield<unsigned, 0, 4>; > > bitfield<Amount>(Storage) = true;...

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

...3 4 5 Can anyone offer any advice? I'm open to using a different OO system if that's deemed advisable, I'm not very familiar with any of them. Note that in my real (non-toy) application, I'll need arbitrary methods to be able to read & write data to the object, so simple getField() and setField() accessors won't be sufficient. Thanks. -- Ken Williams Research Scientist The Thomson Corporation Eagan, MN

...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>:0x...

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