Re: Please build the JIT branch

[Max Brister]

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