octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JIT test crash


From: Max Brister
Subject: Re: JIT test crash
Date: Fri, 28 Dec 2012 22:39:35 -0700

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]