Re: Please build the JIT branch

[Ben Abbott]

On Jul 22, 2012, at 3:27 PM, Ben Abbott wrote:

> On Jul 22, 2012, at 2:11 PM, Max Brister wrote:
> 
>> On Sun, Jul 22, 2012 at 1:01 PM, Ben Abbott <address@hidden> wrote:
>>> 
>>> On Jul 22, 2012, at 1:41 PM, Max Brister wrote:
>>> 
>>>> On Sun, Jul 22, 2012 at 11:58 AM, Ben Abbott <address@hidden> wrote:
>>>>> 
>>>>> On Jul 20, 2012, at 10:14 AM, Max Brister wrote:
>>>>> 
>>>>>> On Tue, Jul 17, 2012 at 6:25 AM, Ben Abbott <address@hidden> wrote:
>>>>>>> 
>>>>>>> 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
>>>>>> 
>>>>>> Sorry for the delay. That approach will not work, as the developers
>>>>>> source from savanah does not search for llvm. I have attached a patch
>>>>>> that changes configure.ac to disable HAVE_LLVM (even when LLVM is
>>>>>> found). Then it call llvm::getGlobalContext () in octave_main. This
>>>>>> should show us if LLVM is an issue, or it is my code.
>>>>>> 
>>>>>> Max Brister
>>>>>> <llvm_check.patch>
>>>>> 
>>>>> I've been having trouble running configure on the default branch since 
>>>>> JIT was merged.  WIth Carlo's recent changes, I'm able to configure 
>>>>> again! I've tried three cases.
>>>>> 
>>>>>      (1) Building without LLVM_CONFIG results in a working octave.
>>>>> 
>>>>>      (2) Building with LLVM_CONFIG and without your patch 
>>>>> (llvm_check.patch)  crashes.
>>>>> 
>>>>>      (3) Building with LLVM_CONFIG and with your patch (llvm_check.patch) 
>>>>> also crashes.
>>>> 
>>>> Ok, so this crash looks like it's unrelated to my code. There might be
>>>> a problem with how I'm linking to llvm though.
>>>> 
>>>>> I'm unfamiliar with LLVM. I have several versions of gcc development 
>>>>> tools installed on my Mac (gcc-4.2, gcc-4.4, gcc-4.5, and gcc-4.6).  
>>>>> Might LLVM be sensitive to compiler choice?
>>>> 
>>>> I'm not sure. It might also be an issue with the compiler flags in my
>>>> config script. Your original error message had a failure in
>>>> std::string::assign, so maybe LLVM is compiled with a different
>>>> version of libstdc++ (this is just a wild guess). Can you see if the
>>>> LLVM examples compile and run? (http://llvm.org/releases/)
>>> 
>>> I don't see any example at the link.
>> 
>> If you download the LLVM 3.0 release
>> (http://llvm.org/releases/3.0/llvm-3.0.tar.gz). The examples should be
>> in the examples directory. I wonder if compiling LLVM with gcc-4.5
>> will fix your issue, or is it already compiled with gcc-4.5?
>> 
>>> Linking to more than one libstdc++ may be the case as I have Apple's gcc as 
>>> well as gcc-4.4, gcc-4.5, and gcc-4.6 from MacPorts installed.  However, 
>>> looking at the Octave executable as well as liboctinterp.dylib, 
>>> liboctave.dylib, and libcruft.dylib, the only libstdc++ I see is the one 
>>> associated with gcc-4.5.
>>> 
>>> $ otool -L src/.libs/octave
>>> src/.libs/octave:
>>>       /usr/local/lib/octave/3.7.0+/liboctinterp.1.dylib (compatibility 
>>> version 2.0.0, current version 2.1.0)
>>>       /usr/local/lib/octave/3.7.0+/liboctave.1.dylib (compatibility version 
>>> 2.0.0, current version 2.1.0)
>>>       /opt/local/lib/libfltk_gl.1.3.dylib (compatibility version 1.3.0, 
>>> current version 1.3.0)
>>>       /opt/local/lib/libfltk.1.3.dylib (compatibility version 1.3.0, 
>>> current version 1.3.0)
>>>       /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
>>> version 159.1.0)
>>>       /opt/local/lib/libhdf5.7.dylib (compatibility version 8.0.0, current 
>>> version 8.3.0)
>>>       /opt/local/lib/libfontconfig.1.dylib (compatibility version 7.0.0, 
>>> current version 7.0.0)
>>>       /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current 
>>> version 8.1.0)
>>>       /opt/local/lib/libfreetype.6.dylib (compatibility version 15.0.0, 
>>> current version 15.1.0)
>>>       /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current 
>>> version 1.2.7)
>>>       /opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current 
>>> version 1.0.6)
>>>       /opt/local/lib/libexpat.1.dylib (compatibility version 8.0.0, current 
>>> version 8.0.0)
>>>       /opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current 
>>> version 10.0.0)
>>>       /opt/local/lib/libxcb.1.dylib (compatibility version 3.0.0, current 
>>> version 3.0.0)
>>>       /opt/local/lib/libXau.6.dylib (compatibility version 7.0.0, current 
>>> version 7.0.0)
>>>       /opt/local/lib/libXdmcp.6.dylib (compatibility version 7.0.0, current 
>>> version 7.0.0)
>>>       /usr/local/lib/octave/3.7.0+/libcruft.1.dylib (compatibility version 
>>> 2.0.0, current version 2.0.0)
>>>       /opt/local/lib/libmetis.dylib (compatibility version 0.0.0, current 
>>> version 0.0.0)
>>>       /opt/local/lib/libqrupdate.1.dylib (compatibility version 0.0.0, 
>>> current version 0.0.0)
>>>       /opt/local/lib/libfftw3.3.dylib (compatibility version 7.0.0, current 
>>> version 7.2.0)
>>>       /opt/local/lib/libfftw3f.3.dylib (compatibility version 7.0.0, 
>>> current version 7.2.0)
>>>       /opt/local/lib/libreadline.6.2.dylib (compatibility version 6.0.0, 
>>> current version 6.2.0)
>>>       /opt/local/lib/libncurses.5.dylib (compatibility version 5.0.0, 
>>> current version 5.0.0)
>>>       /opt/local/lib/libpcre.1.dylib (compatibility version 2.0.0, current 
>>> version 2.0.0)
>>>       /opt/local/lib/gcc45/libstdc++.6.dylib (compatibility version 7.0.0, 
>>> current version 7.14.0)
>>>       /opt/local/lib/gcc45/libgfortran.3.dylib (compatibility version 
>>> 4.0.0, current version 4.0.0)
>>>       /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 
>>> (compatibility version 1.0.0, current version 17.0.0)
>>>       
>>> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
>>>  (compatibility version 1.0.0, current version 41.0.0)
>>>       /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 
>>> (compatibility version 1.0.0, current version 1.0.0)
>>>       /System/Library/Frameworks/AGL.framework/Versions/A/AGL 
>>> (compatibility version 1.0.0, current version 1.0.0)
>>>       /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current 
>>> version 1105.0.0)
>>>       /opt/local/lib/gcc45/libgcc_s.1.dylib (compatibility version 1.0.0, 
>>> current version 1.0.0)
>> 
>> I also do not see LLVM in the list. Is LLVM getting included by some
>> other mechanism?
>> 
>> Max Brister
> 
> My llvm is installed in /opt/local/libexec/llvm-3.0 with subdirectories /bin, 
> /lib, and /include.  The dylibs in /lib are ...
> 
>       /opt/local/libexec/llvm-3.0/lib/BugpointPasses.dylib
>       /opt/local/libexec/llvm-3.0/lib/LLVMHello.dylib
>       /opt/local/libexec/llvm-3.0/lib/libLLVM-3.0.dylib
>       /opt/local/libexec/llvm-3.0/lib/libLTO.dylib
>       /opt/local/libexec/llvm-3.0/lib/libprofile_rt.dylib
> 
> There are a lot of static libs there as well.  When I configure with 
> LLVM_CONFIG, my configure.status includes the following (I modified LLVM_LIBS 
> below to make it easier to read).
> 
> S["LLVM_LIBS"]="-lLLVMXCoreCodeGen -lLLVMTableGen -lLLVMSystemZCodeGen"\
> " -lLLVMSparcCodeGen -lLLVMPTXCodeGen -lLLVMPowerPCCodeGen 
> -lLLVMMSP430CodeGen"\
> " -lLLVMMipsCodeGen -lLLVMMCJIT -lLLVMRuntimeDyld -lLLVMObject"\
> " -lLLVMMCDisassembler -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMSystemZDesc"\
> " -lLLVMSystemZInfo -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMPowerPCDesc"\
> " -lLLVMPowerPCInfo -lLLVMPowerPCAsmPrinter -lLLVMPTXDesc -lLLVMPTXInfo"\
> " -lLLVMPTXAsmPrinter -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter"\
> " -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter 
> -lLLVMMBlazeDisassembler"\
> " -lLLVMMBlazeAsmParser -lLLVMMBlazeCodeGen -lLLVMMBlazeDesc 
> -lLLVMMBlazeAsmPrinter"\
> " -lLLVMMBlazeInfo -lLLVMLinker -lLLVMipo -lLLVMInterpreter 
> -lLLVMInstrumentation"\
> " -lLLVMJIT -lLLVMExecutionEngine -lLLVMDebugInfo -lLLVMCppBackend"\
> " -lLLVMCppBackendInfo -lLLVMCellSPUCodeGen -lLLVMCellSPUDesc 
> -lLLVMCellSPUInfo"\
> " -lLLVMCBackend -lLLVMCBackendInfo -lLLVMBlackfinCodeGen -lLLVMBlackfinDesc"\
> " -lLLVMBlackfinInfo -lLLVMBitWriter -lLLVMX86Disassembler 
> -lLLVMX86AsmParser"\
> " -lLLVMX86CodeGen -lLLVMX86Desc -lLLVMX86AsmPrinter -lLLVMX86Utils 
> -lLLVMX86Info"\
> " -lLLVMAsmParser -lLLVMARMDisassembler -lLLVMARMAsmParser -lLLVMARMCodeGen"\
> " -lLLVMARMDesc -lLLVMARMAsmPrinter -lLLVMARMInfo -lLLVMArchive 
> -lLLVMBitReader"\
> " -lLLVMAlphaCodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser"\
> " -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils"\
> " -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMCore -lLLVMAlphaDesc 
> -lLLVMAlphaInfo"\
> " -lLLVMMC -lLLVMSupport"
> S["LLVM_LDFLAGS"]="-L/opt/local/libexec/llvm-3.0/lib"
> S["LLVM_CPPFLAGS"]="-isystem /opt/local/libexec/llvm-3.0/include"
> S["LLVM_CXXFLAGS"]=""
> S["LLVM_CONFIG"]="/opt/local/bin/llvm-config-mp-3.0"
> 
> The LLVM_LIBS each match static libs. So which explains why they aren't 
> listed by otool -L.
> 
> Ben

I tried LLVM_CONFIG again today and am able to build and run Octave.  I'll do 
some testing as I have time.

Ben