Re: Please build the JIT branch

[Michael Goffioul]

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