search for: evaeryone

...x = call float @obj.x(i8* %obj); %y = call float @obj.y(i8* %obj); %sum = add float %x, %y ret float %sum } In either case, an optimization pass could trivially zero out the overhead with 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...

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

...e: %x = offsetx(%obj) %y = offsety(%obj) %sum = add float %x, %y ret float %sum Thanks, Nicolas > In either case, an optimization pass could trivially zero out the > overhead with 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 no...