Re: Please build the JIT branch

[Ben Abbott]

On Jul 16, 2012, at 4:55 PM, Max Brister wrote:

> On Fri, Jul 13, 2012 at 6:27 AM, Ben Abbott <address@hidden> wrote:
>> On Jul 12, 2012, at 11:13 PM, Max Brister wrote:
>> 
>>> On Thu, Jul 12, 2012 at 8:18 PM, Ben Abbott <address@hidden> wrote:
>>>> 
>>>> On Jul 12, 2012, at 7:52 PM, Ben Abbott wrote:
>>>> 
>>>>> On Jul 10, 2012, at 6:00 PM, Max Brister wrote:
>>>>> 
>>>>>> JIT is still pretty limited, it will not compile loops with any
>>>>>> function calls, even builtin functions (except for sin, cos, and exp).
>>>>>> It also only supports linear matrix indexing. For an example of a
>>>>>> function which can be compiled, see
>>>>>> http://jit-octave.blogspot.com/2012/06/realistic-test.html.
>>>>>> 
>>>>>> Max Brister
>>>>> 
>>>>> Using macports on MacOS 10.7, I did a quick build (without worrying about 
>>>>> LLVM)
>>>>> 
>>>>> With JIT
>>>>> 
>>>>>     A = gen_test (1000000);
>>>>>     K = 500;
>>>>>     Vectorized: 1.274 sec
>>>>>     Loopy: 4.875 sec
>>>>> 
>>>>> With 3.7.0+
>>>>> 
>>>>>     A = gen_test (1000000);
>>>>>     K = 500;
>>>>>     Vectorized: 5.944
>>>>>     Loopy: 16.063
>>>>> 
>>>>> I'll try again with LLVM_CONFIG=/opt/local/bin/llvm-config-mp-3.0
>>>>> 
>>>>> Ben
>>> 
>>> It's odd that there was any change at all between the JIT branch
>>> (without being able to find llvm) and 3.7.0+. The JIT branch compiled
>>> without llvm should be mostly the same as 3.7.0+. Almost all of the
>>> code I have added is inside
>>> #ifdef LLVM_FOUND
>>> ....
>>> #endif // LLVM_FOUND
>>> 
>>> Maybe this is a fluke?
>> 
>> I didn't check, but I have an automated backup that may have been running 
>> with 3.7.0
>> 
>>>> With LLVM_CONFIG set to the above, I see ...
>>>> 
>>>> octave(56971,0x7fff70d62960) malloc: *** error for object 0x106a4c620: 
>>>> pointer being freed was not allocated
>>>> *** set a breakpoint in malloc_error_break to debug
>>>> 
>>>> Program received signal SIGABRT, Aborted.
>>>> 0x00007fff850fece2 in __pthread_kill ()
>>>> (gdb) bt
>>>> #0  0x00007fff850fece2 in __pthread_kill ()
>>>> #1  0x00007fff856e57d2 in pthread_kill ()
>>>> #2  0x00007fff856d6a7a in abort ()
>>>> #3  0x00007fff8573584c in free ()
>>>> #4  0x00000001069e2685 in std::string::assign ()
>>>> #5  0x0000000100b4297c in global constructors keyed to a () at 
>>>> basic_string.h:500
>>>> #6  0x00007fff5fc0fda6 in 
>>>> __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE
>>>>  ()
>>>> #7  0x00007fff5fc0faf2 in 
>>>> __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE
>>>>  ()
>>>> #8  0x00007fff5fc0d2e4 in 
>>>> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
>>>>  ()
>>>> #9  0x00007fff5fc0d27d in 
>>>> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
>>>>  ()
>>>> #10 0x00007fff5fc0e0b7 in 
>>>> __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE
>>>>  ()
>>>> #11 0x00007fff5fc034dd in __dyld__ZN4dyld24initializeMainExecutableEv ()
>>>> #12 0x00007fff5fc0760b in 
>>>> __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
>>>> #13 0x00007fff5fc01059 in __dyld__dyld_start ()
>>>> (gdb)
>>>> 
>>>> Ben
>>> 
>>> The stack trace is not very clear, but it looks like something bad is
>>> happening during static initialization. I should probably get rid of
>>> these static variables anyways. Can you try the attached patch? If I
>>> am right it should fix problem.
>>> 
>>> I might be a bit slow to respond the next few days. I have to prepare
>>> for and get to OctConf!
>>> 
>>> Max Brister
>>> <static_init.patch>
>> 
>> I don't see any change
>> 
>> done
>> octave(88684,0x7fff70d62960) malloc: *** error for object 0x106a4b620: 
>> pointer being freed was not allocated
>> *** set a breakpoint in malloc_error_break to debug
>> 
>> Program received signal SIGABRT, Aborted.
>> 0x00007fff850fece2 in __pthread_kill ()
>> (gdb) bt
>> #0  0x00007fff850fece2 in __pthread_kill ()
>> #1  0x00007fff856e57d2 in pthread_kill ()
>> #2  0x00007fff856d6a7a in abort ()
>> #3  0x00007fff8573584c in free ()
>> #4  0x00000001069e1685 in std::string::assign ()
>> #5  0x0000000100b4287c in global constructors keyed to a () at 
>> basic_string.h:500
>> #6  0x00007fff5fc0fda6 in 
>> __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE
>>  ()
>> #7  0x00007fff5fc0faf2 in 
>> __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE
>>  ()
>> #8  0x00007fff5fc0d2e4 in 
>> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
>>  ()
>> #9  0x00007fff5fc0d27d in 
>> __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
>>  ()
>> #10 0x00007fff5fc0e0b7 in 
>> __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE
>>  ()
>> #11 0x00007fff5fc034dd in __dyld__ZN4dyld24initializeMainExecutableEv ()
>> #12 0x00007fff5fc0760b in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ 
>> ()
>> #13 0x00007fff5fc01059 in __dyld__dyld_start ()
>> (gdb)
> 
> I'm not sure what is happening here. If the statics I'm initializing
> do not cause any issue and Octave runs by its self, I wonder if this
> problem is caused by llvm? Does just linking llvm into Octave without
> using jit at all cause this problem?
> 
> Max Brister

What is the best way for me to test that? Do I simply add the part below to 
./configure when building the developer's sources from Savannah?

        LLVM_CONFIG=/opt/local/bin/llvm-config-mp-3.0

Ben