[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

[Nick Lewycky]

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?

Nick