This doesn't look related to llc's instructions. When I generate
assembly using either llc or clang, they both use _pow; if I then compiled the
assembly with gcc the results are identical to compiling the C source with gcc.
So Eli's response that lli is using a different library than gcc and Visual
Studio looks correct. The only option then is to use another library instead of
llvm.pow.f64 - for my case this is easy because my actual use is generating LLVM
bytecode directly rather than using clang.
-----Original Message-----
From: Frits van Bommel [mailto:fvbommel at gmail.com]
Sent: Saturday, February 12, 2011 5:14 AM
To: Dimitry Andric
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] pow operator on Windows
On Sat, Feb 12, 2011 at 1:06 PM, Dimitry Andric <dimitry at andric.com>
wrote:> On 2011-02-12 12:34, David Given wrote:
>> You might want to look at the generated machine code to see how they
>> differ. If this *is* the problem, you can tell gcc to use a particular
>> instruction set with -mfpmath=386 or -mfpmath=sse.
>
> I think you mean -mfpmath=387, instead. :)
>
> Btw, this option is also not supported by clang... any idea how it could
> be implemented, if at all?
Shouldn't be that hard for 32-bit x86 since -mattr=-sse already works
when passed to llc (but not clang) so you should be able to just copy
that code.
For x86-64 it's trickier, as the calling convention uses SSE registers
so -mattr=-sse ICEs when returning floats etc. ("LLVM ERROR: SSE
register return with SSE disabled").
This would need either
a) a more selective option to disable SSE *math* only (but allow use
of SSE registers for parameters and return values), or
b) change the calling convention to use x87 registers instead. This
which would require recompiling anything that accepts or returns
floating-point numbers, including printf(), sqrt() and friends, etc.