[llvm-commits] [llvm] r85295 - in /llvm/trunk: docs/tutorial/LangImpl4.html docs/tutorial/OCamlLangImpl4.html include/llvm/ExecutionEngine/ExecutionEngine.h lib/ExecutionEngine/ExecutionEngine.cpp lib/ExecutionEngine/JIT/JIT.cpp lib/ExecutionEngi

[Evan Cheng]

On Oct 27, 2009, at 9:45 PM, Nick Lewycky wrote:

> Evan Cheng wrote:
>> On Oct 27, 2009, at 2:11 PM, Jeffrey Yasskin wrote:
>>> On Tue, Oct 27, 2009 at 1:54 PM, Evan Cheng  
>>> <evan.cheng at apple.com>  wrote:
>>>> On Oct 27, 2009, at 1:30 PM, Jeffrey Yasskin wrote:
>>>>
>>>>> Author: jyasskin
>>>>> Date: Tue Oct 27 15:30:28 2009
>>>>> New Revision: 85295
>>>>>
>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=85295&view=rev
>>>>> Log:
>>>>> Change the JIT to compile eagerly by default as agreed in
>>>>> http://llvm.org/PR5184, and beef up the comments to describe  
>>>>> what  both
>>>>> options
>>>>> do and the risks of lazy compilation in the presence of threads.
>>>> Hi Jeffrey,
>>>>
>>>> In the future I'd prefer API changes be agreed upon by the greater
>>>> community, not just in a bugzilla report.
>>> Sorry about that. Do you want me to revert this until we can ping   
>>> llvmdev?
>>>
>>>> Lazy compilation is being used by some important clients. They  
>>>> will  be
>>>> caught off guard by this change. Does this change lli default   
>>>> behavior?
>>> No, it doesn't change lli's default, although that was an accident  
>>> on
>>> my part (maybe a fortunate accident). I did ping llvmdev last week
>>> asking people who use the lazy JIT to look at the bug report, but I
>>> can see how people who don't use threads with the JIT would think it
>>> didn't apply to them.
>> Sorry, I have been too busy with other things so I didn't follow  
>> the  thread.
>> The patch changed DisableLazyCompilation to EnableLazyCompilation,   
>> which is minor but it's a API change nevertheless.  That means  
>> clients  which are using 2.6 have to change their code in order to  
>> test against  tot. Unless this is absolutely necessary, I'd prefer  
>> not to change it.
>
> Hey Evan, since when did "it's an API change" become a reason not to  
> modify LLVM?
>
> If your concern is that it wasn't discussed enough in advance or  
> trumpeted/advertised enough after landing, fine -- but if the change  
> is for the better then it should go in, and out of tree users get to  
> update their own code. Does that sound like the LLVM we both know?

I am not opposed to modifying API for a good reason. I am not  
convinced there is a good one here. I believe lazy compilation should  
still be the default behavior for JIT. If it's not thread safe, then  
clients who want JIT safety should fix it.

Evan

>
> Nick