Hi all, I am observing an excessive use of xmm registers in the output assembly produced by x86 backend. Basically, for a code like this double test(double a, double b) { double c; c = 1.0 + sin (a + b*b); return c; } llc produced somthing like.... movsd 16(%ebp), %xmm0 mulsd %xmm0, %xmm0 addsd 8(%ebp), %xmm0 movsd %xmm0, (%esp) ....... fstpl -8(%ebp movsd -8(%ebp), %xmm0 addsd .LC1, %xmm0 movsd %xmm0, -8(%ebp) fldl -8(%ebp) LLVM Backend is using xmms it involves a lot of register moves. llc has one option -mcpu=686, where output does not use xmm but it disables some other instructions also. Is there any fine grain optimization flag like ( -mfpmath = 387 which is present in gcc) which would just instruction backend to use fpstack instead of SSE instructions and still not limit the instructions Thanks --Kapil . -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100607/2ae7d924/attachment.html>
On Jun 7, 2010, at 10:04 AMPDT, kapil anand wrote:> > LLVM Backend is using xmms it involves a lot of register moves. llc > has one option -mcpu=686, where output does not use xmm but it > disables some other instructions also. Is there any fine grain > optimization flag like ( -mfpmath = 387 which is present in gcc) > which would just instruction backend to use fpstack instead of SSE > instructions and still not limit the instructions-mattr=-sse Note that this doesn't change the calling convention; in particular, the only supported calling convention for 64-bit x86 uses SSE, so you'll get an error if you use the above for a function returning double in 64-bit mode.
Maybe Matching Threads
- [Codegen bug in LLVM 3.8?] br following `fcmp une` is present in ll, absent in asm
- [LLVMdev] Suboptimal code due to excessive spilling
- [LLVMdev] Suboptimal code due to excessive spilling
- [LLVMdev] llvm.x86.sse2.sqrt.pd not using sqrtpd, calling a function that modifies ECX
- Finding caller-saved registers at a function call site