[llvm-bugs] [Bug 37358] New: SIMD Misoptimization during "Promote 'by reference' arguments to scalars on SCC"

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=37358

            Bug ID: 37358
           Summary: SIMD Misoptimization during "Promote 'by reference'
                    arguments to scalars on SCC"
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: alex at crichton.co
                CC: llvm-bugs at lists.llvm.org

Created attachment 20270
  --> https://bugs.llvm.org/attachment.cgi?id=20270&action=edit
failing IR

We've got an upstream bug in rust-lang/rust at
https://github.com/rust-lang/rust/issues/50154 where LLVM at opt-level=3 is
mis-optimizing promotion of an argument passed by reference to pass-by-value.
The attached IR exhibits the difference by looking at:


    $ opt -O2 tmp.ll -S | grep '^define.*m256'
    define internal fastcc void @_mm256_cmpgt_epi16(<4 x i64>* nocapture, <4 x
i64>* nocapture readonly %a, <4 x i64>* nocapture readonly %b) unnamed_addr #2
{
    $ opt -O3 tmp.ll -S | grep '^define.*m256'
    define internal fastcc void @_mm256_cmpgt_epi16(<4 x i64>* nocapture, <4 x
i64> %a.val, <4 x i64> %b.val) unnamed_addr #2 {



Note that at opt-level=2 the two arguments to this function continue to be
passed by reference, but at opt-level=3 they're promoted to being passed by
value. In this situation the target function, `_mm256_cmpgt_epi16`, has the
"avx2" feature enabled. The caller, `baseline`, does not have any extra target
features enabled (aka doesn't have "avx2" available). This means that if
attempting to pass by value this'll be an ABI mismatch at codegen time,
producing invalid results on optimized IR.

Using opt-bisect-limit I found that this happens during the "Promote 'by
reference' arguments to scalars on SCC" pass. Are we correct in thinking that
this optimization shouldn't happen? Or is this a valid optimization that we'll
need to work around on rustc's end?

-- 
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/20180507/c95156e2/attachment.html>