[llvm-bugs] [Bug 39654] New: On x86-64, RAX is unnecessarily preserved when returning member of struct containing couple of floats

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Nov 13 16:33:28 PST 2018


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

            Bug ID: 39654
           Summary: On x86-64, RAX is unnecessarily preserved when
                    returning member of struct containing couple of floats
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows XP
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: s.hesp at oisyn.nl
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org,
                    neeilans at live.com, richard-llvm at metafoo.co.uk

Compiler Explorer link: https://godbolt.org/z/9-TCNN

Consider the following code:
====================
using type = float;

struct Data
{
    type a, b;
};

type _a, _b;
__attribute__((noinline)) Data GetData() { return {_a, _b}; }

auto FirstMember()
{
    return GetData().a;
}
====================

For FirstMember(), this will generate (with -O):
  push rax
  call GetData()
  pop rax
  ret

If you change 'type' to 'double', this will just turn into a tail call:
  jmp GetData() # TAILCALL

When changing 'type' to 'double' AND returning 'b' rather than 'a', we see the
preservation of RAX again:
  push rax
  call GetData()
  movaps xmm0, xmm1
  pop rax
  ret

I suspect it has to do with the rule that a function should return a pointer to
the returned struct according to the x86-64 ABI, but I don't think that applies
here as the struct is returned fully in SSE registers.

Note that it does NOT try to preserve RAX when compiling without optimizations.

-- 
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/20181114/c471f6db/attachment.html>


More information about the llvm-bugs mailing list