Re: Please build the JIT branch

[Max Brister]

On Sun, Jul 15, 2012 at 2:48 PM, Michael Goffioul
<address@hidden> wrote:
> On Sun, Jul 15, 2012 at 8:29 PM, Michael Goffioul
> <address@hidden> wrote:
>>
>> On Sat, Jul 14, 2012 at 6:07 PM, Michael Goffioul
>> <address@hidden> wrote:
>>>>
>>>>
>>>> > 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).
>>>
>>>
>>> I didn't disable ST(0)/ST(1), I just removed ST(1) as a possible return
>>> register. So {double,double} are now returned as a hidden pointer (while a
>>> single double is returned in ST(0), as it should be). I didn't test, but I'm
>>> wondering what LLVM will generate for code returning {float,float}. On
>>> x86-32 it should use EAX:EDX.
>>>
>>>>
>>>> This problem might also appear on 32bit linux. I have a machine
>>>> running 32bit linux and am trying it now.
>>>
>>>
>>> I wanted to try on my F16 box, but it only has LLVM 2.9. Is LLVM 3.0
>>> absolutely required? The configure script succeeded, but the compilation
>>> failed as it couldn't find llvm/Support/TargetSelect.h.
>>>
>>
>> I've upgraded to F17 (which uses llvm-3.0) and bingo! Exactly the same
>> crash. See attachment for the disassembled part of the code calling
>> octave_jig_cast_complex_any. It uses the same ST(0)/ST(1) to return the
>> {double,double} aggregate. I'm wondering whether this can be considered a
>> bug in LLVM, as this is definitely not x86-32 compatible.
>
>
> After some research, I found out that it looks like the calling convention
> to return C99 double complex under x86-64. I traced down the change in LLVM
> to this commit [1], but oddly enough the commit message mentions x86-64,
> while it actually touches x86-32 conventions.
>
> Max, do you have contacts with LLVM developers? It might be worth
> reporting/checking the issue. Personally, I don't have much time to follow
> that further.
>
> Michael.
>
> [1] https://llvm.org/viewvc/llvm-project?view=rev&sortby=log&revision=48632

Thank you for looking into this. Once I get some more time (probably
after octconf) I'll pick up where you left off.

Max Brister