Re: JIT test crash

[Max Brister]

On Fri, Dec 28, 2012 at 10:39 PM, Max Brister <address@hidden> wrote:
> On Fri, Dec 28, 2012 at 9:27 PM, Michael Goffioul
> <address@hidden> wrote:
>> On Fri, Dec 28, 2012 at 4:04 PM, Max Brister <address@hidden> wrote:
>>>
>>> On Wed, Dec 26, 2012 at 7:20 AM, Michael Goffioul
>>> <address@hidden> wrote:
>>> > On Wed, Dec 26, 2012 at 12:01 AM, Max Brister <address@hidden> wrote:
>>> >>
>>> >> Well, there was recently a new version of LLVM, it would be nice if
>>> >> that just fixed the issue (I don't see anything relevant in the
>>> >> release notes though).
>>> >>
>>> >> If that doesn't work, then we should try implementing complex numbers
>>> >> as a llvm::ArrayType or llvm::StructureType internally in Octave.
>>> >> Currently, complex numbers are implemented with an llvm::VectorType,
>>> >> which LLVM emits vectorized assembly for. If I recall correctly, that
>>> >> was causing MSVC to emit bad instructions. I can prepare a patch to do
>>> >> this, if you want to try it.
>>> >>
>>> >> If that doesn't work, then we need to trace the execution of LLVM to
>>> >> figure out why bad code is being generated.
>>> >
>>> >
>>> > Note that IIRC, the problem was data alignment. GCC aligns by default on
>>> > 16-bytes boundary, MSVC on 4-bytes. If LLVM assumes GCC alignment, then
>>> > it
>>> > can emit bad vectorized code.
>>>
>>> Yes, hopefully avoiding the vectorized instructions will fix the
>>> issue. I'm not sure how much of a speedup we get by vectorizing
>>> operations on complex numbers anyways.
>>>
>>> I have attached a patch that *should* avoid these vectorized instructions.
>>
>>
>> Thanks, Max. Unfortunately, the JIT code does not compile anymore with MSVC
>> at the moment. My change
>>
>> http://hg.savannah.gnu.org/hgweb/octave/rev/fd8d1a616be1
>>
>> has been partially reverted by yours
>>
>> http://hg.savannah.gnu.org/hgweb/octave/rev/3f43e9d6d86e
>>
>> So I need to find a way to work around the issue, but it may be hard to
>> find. The actual problem is that <Cell.h> got included when compiling
>> Array-jit.cc (pulled from pt-jit.h -> symtab.h -> oct-obj.h -> Cell.h). The
>> class Cell is marked with dllexport and inherits from Array<octave_value>.
>> This makes MSVC to instantiate all Array<octave_value> methods. However, as
>> Array-jit.cc also includes <Array.cc>, it makes MSVC to try to instantiate
>> code that is not valid when T = octave_value.
>>
>> Michael.
>>
>
> Yes, I remember that issue. It turns out we don't need to include
> pt-jit.h, instead we only have to include jit-ir.h. I pushed a patch
> for this
> http://hg.savannah.gnu.org/hgweb/octave/rev/20f4a2399be0
>
> Do you know of a good way to check to automatically ensure I don't
> accidentally include Cell.h in Array-jit.h? This sounds like the sort
> of mistake I might accidentally make again.
>
> --
> Max Brister

I just remembered, I can use #ifdef to see if Cell.h has been
included. I pushed a change set that does this
http://hg.savannah.gnu.org/hgweb/octave/rev/500650d6ddf5

We shouldn't see the Cell.h inclusion error again.

-- 
Max Brister