Re: Please build the JIT branch

[Max Brister]

On Fri, Jul 13, 2012 at 11:36 AM, Michael Goffioul
<address@hidden> wrote:
> On Fri, Jul 13, 2012 at 3:58 PM, Michael Goffioul
> <address@hidden> wrote:
>>
>> On Fri, Jul 13, 2012 at 2:30 PM, Michael Goffioul
>> <address@hidden> wrote:
>>>
>>> On Fri, Jul 13, 2012 at 12:37 PM, Michael Goffioul
>>> <address@hidden> wrote:
>>>>
>>>> If you inspect how the stack is constructed before calling
>>>> octave_jit_cast_complex_any, you can see that:
>>>> - 24 bytes are allocated on the stack (02CB00E9, that's 3 double's,
>>>> let's call them d1, d2 and d3)
>>>> - EAX is copied at the top of the stack, at this point EAX is the
>>>> "octave_base_value* obv" argument, so it's basically the first argument of
>>>> the function; it occupies the location d1 on the stack
>>>> - after octave_jit_cast_complex_any call, results are pulled from the
>>>> stack at location d2 and d3
>>>>
>>>> This does not correspond to the ABI MSVC is using. Instead of pushing a
>>>> hidden pointer on the top of the stack (as it should do), it allocates the
>>>> memory for the returned complex value on the stack and *after* the regular
>>>> function arguments. Of course, when octave_jit_cast_complex_any tries to
>>>> access obv, it points to invalid memory and crashes.
>>>
>>>
>>> My analysis is not entirely correct. From the assembly calling
>>> octave_jit_cast_complex_any, it looks like only one argument is pushed on
>>> the stack (no hidden pointer) and the function is expected to return 2
>>> double values on the x87 stack. These 2 doubles are then popped from the x87
>>> stack, stored temporarily in d2 and d3, then packed into XMM0. Still, this
>>> is incompatible with how MSVC compiles octave_jit_cast_complex_any.
>>
>>
>> Maybe an interesting reading...
>> http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-November/011293.html

This seems to be a little out of date. LLVM does allow for aggregate
values to be passed as atomic values now, however I think the problem
pointed in that post exists (it's unclear to LLVM how multiple values
should be returned).

> For the record, I finally got it working. I had to hack the calling
> conventions in LLVM to disable the use of ST(0)/ST(1) registers to return
> multiple floating-point values. Then the generated assembly is compatible
> with MSVC ABI. What I don't understand is why that problem does not occur on
> 32-bits Linux. AFAIK the ABI to return aggregates are the same (except for
> who's popping the hidden pointer argument).

Thank you for looking into this. Calling conventions are a real pain.
I'm not sure if disabling ST(0)/ST(1) is a good long term solution as
we might run into issues trying to return some other type. I should
look at clang to see how they handle this issue (this might take some
time though).

This problem might also appear on 32bit linux. I have a machine
running 32bit linux and am trying it now.

Max Brister