[llvm-bugs] [Bug 47884] New: missed optimization initializing an aggregate return value by a sequence of stores

[via llvm-bugs]

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

            Bug ID: 47884
           Summary: missed optimization initializing an aggregate return
                    value by a sequence of stores
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: richard-llvm at metafoo.co.uk
                CC: llvm-bugs at lists.llvm.org

Testcase:

struct Foo {
    char a;
    long b;
    char c;
    long d;
};

Foo foo1() {
    Foo f;
    f.a = 0;
    f.b = 0;
    f.c = 0;
    f.d = 0;
    return f;
}

We currently emit this as four stores to the sret parameter (1 byte, 8 byte, 1
byte, 8 byte). It would be more efficient to combine some of these stores
together.

In order for that to be correct, we'll need the frontend to tell the middle-end
that certain bytes of the sret parameter are known to be undef on entry to the
function. This seems like a general attribute we could reasonably apply to a
pointer parameter to a function, for example:

define void @foo(%struct.Foo* noalias sret(%struct.Foo) undef(32) align 8
%agg.result) {

... to indicate that the first 32 bytes reachable through %agg.result can be
assumed to be undef on entry to the function.

(We can't in general assume that sret(%T) implies that the full size of %T is
undef; that's not true in C++ due to the possibility of tail padding reuse.)

-- 
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/20201016/e60269db/attachment.html>