llvm dev - Oct 2009 - [LLVMdev] Should LLVM JIT default to lazy or non-lazy?

2009/10/28 Chandler Carruth <chandlerc at
google.com>:
> Surviving new and different uses
> *is* the purpose of a good interface.
I don't have much to add to this interesting discussion, just like to
remind people that changes in the default behaviour are only
acceptable (IMHO) when everybody (but a few legacy code) is NOT using
(or should not use) the current default behaviour.

The counter example (and a good point when not to change the default
even when it's dangerous) is the strcpy() in the libc. It's dangerous,
malicious, bearing stupid, but still there. You have the strncpy (and
all associated variants) but it's not compulsory nor the default
behaviour.

Creating another method (getLazyFunctionPointer) or passing a boolean,
enum, whatever seems like the best course of action right now.

I understand that passing lots of Function*s to the JIT and only
generating what's really executed would be "nice" but (as was
pointed
out before) this is signal of bad code. You should only pass to the
JIT what's really going to be executed, and I guess it's not that hard
to do the "lazy evaluation" on your side.

My 2 cents...

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

On Oct 28, 2009, at 1:10 PM, Renato Golin wrote:
> Creating another method (getLazyFunctionPointer) or passing a boolean,
> enum, whatever seems like the best course of action right now.
>

I think that this is a great idea.  Instead of making "lazy or not" be
a policy maintained by the JIT, why don't we approach this as a bug in  
the current API.  Perhaps we should remove getPointerToFunction() and  
introduce two new methods (one lazy and one eager)?

-Chris

A performance argument in favor of lazy JIT:

If you're creating functions that contain calls to large amounts of
seldom-used code, (or takes the address of a ton of functions, only a
few of which end up being used) then lazy JIT is a win regardless of
how carefully you only JIT what you want to call.  I'm not sure how
frequent a use case this is, though.

2009/10/28 Chris Lattner <clattner at apple.com>:
> I think that this is a great idea.  Instead of making "lazy or
not" be a
> policy maintained by the JIT, why don't we approach this as a bug in
the
> current API.  Perhaps we should remove getPointerToFunction() and introduce
> two new methods (one lazy and one eager)?
Didn't want to sound too radical, but that'd be my approach... ;)

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

On Wed, Oct 28, 2009 at 1:32 PM, Chris Lattner <clattner at apple.com>
wrote:
> On Oct 28, 2009, at 1:10 PM, Renato Golin wrote:
>> Creating another method (getLazyFunctionPointer) or passing a boolean,
>> enum, whatever seems like the best course of action right now.
>>
>
>
> I think that this is a great idea.  Instead of making "lazy or
not" be
> a policy maintained by the JIT, why don't we approach this as a bug in
> the current API.  Perhaps we should remove getPointerToFunction() and
> introduce two new methods (one lazy and one eager)?
That'd work for me. I just care that it's not easy to stumble into the
thread-unsafe option (and that I have an obvious place to put the
comment). I think I'll need to add the lazy/eager choice to
getPointerToGlobal() and getOrEmitGlobalVariable() too since they can
call into the code generator.
I'd lean toward adding an enum parameter instead of additional
function names since most of the operation will be the same internally
anyway. Does that sound good?