[LLVMdev] 2nd attempt for a working patch for bug 2606

[Garrison Venn]

Hi Jeffrey,
On Feb 26, 2010, at 16:02, Jeffrey Yasskin wrote:

> [sidenote: Please try to avoid extraneous whitespace and line wrapping changes in your patches. It makes it harder to see what you're actually changing]
Sorry just saw some preexisting code was not in 80 columns.
> 
> On Fri, Feb 26, 2010 at 4:57 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote:
> Hi Olivier,
> 
> On Feb 25, 2010, at 14:10, Olivier Meurant wrote:
> 
>> Hi Garrison,
>> 
>> I finally come back from holidays and take time to watch your patch.
>> 
>> I must say that I largely prefer this version over the previous one ! I like the reuse of getLazyFunctionStub, but I don't know if the forceEmitFunctionStub is still needed ?
> 
> JIT::forceEmitFunctionStub(...) was created to bring its implementation into JITEmitter file scope as JITResolver and 
> therefore JITResolver::getLazyFunctionStub(...) are members of an anonymous namespace in that scope. However
> I can instead use a pre-existing method: getPointerToFunctionOrStub(...) which is declared in ExecutionEngine
> and overwritten in JIT (within JITEmitter file scope). ...
> 
> Have you tried the existing pending functions mechanism? I don't want to introduce stubs in eager compilation mode, and I don't think you have to.
I'm not sure I understand as forceEmitFunctionStub(...) merely calls getLazyFunctionStub(...) which uses the pending function mechanism. The
stubs are replaced at compile (JIT) time not at runtime. Is this not how call sites are currently treated? Is this what you are referring to?

Thanks for looking at this

Garrison

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100226/27f96e4a/attachment.html>