Displaying 4 results from an estimated 4 matches for "getlazyfunctionpoint".
Did you mean:
getlazyfunctionpointer
2009 Oct 28
4
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
...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...
2009 Oct 28
0
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
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 rem...
2009 Oct 28
0
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
On Wed, Oct 28, 2009 at 12:21 PM, Evan Cheng <evan.cheng at apple.com> wrote:
> On Oct 28, 2009, at 10:07 AM, Chandler Carruth wrote:
>> From where I sit, this boils down to a very simple question (modulo
>> Chris's point): Either choice will surprise some users. Which surprise
>> is worse? Personally, I'd always prefer correct but slow behavior by
>>
2009 Oct 28
5
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
On Oct 28, 2009, at 10:07 AM, Chandler Carruth wrote:
> From where I sit, this boils down to a very simple question (modulo
> Chris's point): Either choice will surprise some users. Which surprise
> is worse? Personally, I'd always prefer correct but slow behavior by
> default, and explicitly enabling dangerous (but in some cases fast)
> behavior.
The behavior is only