Re: Please build the JIT branch

[Max Brister]

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?

>
> 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
Description: Binary data