[LLVMbugs] [Bug 17286] New: using memory operand form of division would save on code size

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=17286

            Bug ID: 17286
           Summary: using memory operand form of division would save on
                    code size
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: kkhoo at perfwizard.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following x86 codegen uses 2 vector load instructions (vmovupd) followed by
a reg-reg vector division instruction (vdivpd). It would be better to use the
memory operand form of the division instruction to save on code size; there are
4 extra bytes for the redundant load instruction.

In more complicated scenarios, it could also ease register pressure.

According to "iaca" (
http://software.intel.com/en-us/articles/intel-architecture-code-analyzer ),
the code should perform identically. However, based on my testing on a Sandy
Bridge system, the smaller code also benchmarks slightly faster (4% faster for
the smaller code).

$ ./clang -v
clang version 3.4 (trunk 190938)
Target: x86_64-apple-darwin11.4.2
Thread model: posix

$ cat div.c 
void foo(double *restrict x, double *restrict y) {
    int i;
    for (i=0; i<2; i++) {
        x[i] = x[i] / y[i];
    }
}

$ ./clang -S -o - -O3 -fomit-frame-pointer -march=corei7-avx div.c 
    .section    __TEXT,__text,regular,pure_instructions
    .globl    _foo
    .align    4, 0x90
_foo:                                   ## @foo
    .cfi_startproc
## BB#0:                                ## %entry
    vmovupd    (%rsi), %xmm0
    vmovupd    (%rdi), %xmm1
    vdivpd    %xmm0, %xmm1, %xmm0
    vmovupd    %xmm0, (%rdi)
    ret

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130919/14e5ad0f/attachment.html>