[LLVMbugs] [Bug 14076] New: Problems highlighted by the TSVC loop benchmarks

[bugzilla-daemon at llvm.org]

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

             Bug #: 14076
           Summary: Problems highlighted by the TSVC loop benchmarks
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: hfinkel at anl.gov
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


On the general assumption that running the TSVC loops with floats should be
faster than running them with doubles, I suspect we have suboptimal code
generation for the following tests:

[from: http://llvm.org/perf/db_default/v4/nts/4826]

MultiSource/Benchmarks/TSVC/ControlLoops-dbl/ControlLoops-dbl     5.3408
MultiSource/Benchmarks/TSVC/ControlLoops-flt/ControlLoops-flt     6.6713

MultiSource/Benchmarks/TSVC/Reductions-dbl/Reductions-dbl     5.4195
MultiSource/Benchmarks/TSVC/Reductions-flt/Reductions-flt     8.6970


Also, while the double-precision code should be slower, as we're not
vectorizing, can it legitimately be 2x slower? If not, these also indicate a
problem:

MultiSource/Benchmarks/TSVC/Expansion-dbl/Expansion-dbl     7.1848
MultiSource/Benchmarks/TSVC/Expansion-flt/Expansion-flt     4.3780

MultiSource/Benchmarks/TSVC/LoopRestructuring-dbl/LoopRestructuring-dbl    
8.3210
MultiSource/Benchmarks/TSVC/LoopRestructuring-flt/LoopRestructuring-flt    
4.2134

These also seems questionable:

MultiSource/Benchmarks/TSVC/NodeSplitting-dbl/NodeSplitting-dbl     8.5494
MultiSource/Benchmarks/TSVC/NodeSplitting-flt/NodeSplitting-flt     5.5331

MultiSource/Benchmarks/TSVC/Symbolics-dbl/Symbolics-dbl     4.9180
MultiSource/Benchmarks/TSVC/Symbolics-flt/Symbolics-flt     3.5667

When these tests are run on my POWER7 (powerpc64) machine, the timing on the
tests is as I would expect: the float and double versions take approximately
the same amount of time to execute, with the double-precision version generally
taking slightly more time. As a result, I suspect that these problems are
specific to x86 codegen.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.