[LLVMbugs] [Bug 3741] New: Scalar replacement of Aggregates doesn't handle "byval" parameters.

[bugzilla-daemon at cs.uiuc.edu]

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

           Summary: Scalar replacement of Aggregates doesn't handle "byval"
                    parameters.
           Product: new-bugs
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: fvbommel at wxs.nl
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=2674)
 --> (http://llvm.org/bugs/attachment.cgi?id=2674)
A testcase. Only three loads and three stores should be produced after opt
-instcombine -scalarrepl.

Consider the following C code:
-----
typedef struct Type {
    long a, b, c;
} Type;

Type foo(Type t) {
    // Type u = t;
    // #define t u
    t.a += t.b;
    t.b += t.c;
    return t;
}
-----
Compiling this with llvm-gcc (-O0) and running 'opt -instcombine -scalarrepl'
over it produces the attached bitcode.
Note that the first two stores (to t.a and t.b) are completely redundant and
would obviously have been deleted if 't' had been represented as an alloca
instead of a byval parameter. (What's more, running 'opt -std-compile-opts'
instead only deletes one of them; -dse removes the store to t.b but not the one
to t.a)

I've tested this theory by uncommenting the first two lines in foo() to tell
llvm-gcc to copy the parameter to an alloca and use that instead. This change
produces only three stores (as opposed to the original 5) after 'opt
-instcombine -scalarrepl'.

I think this should be remedied by having scalar replacement of aggregates
treat byval parameters identical to allocas, since they have the exact same
properties except that they can't be deleted and don't have an undef value
before first being stored to.
(Or if that wouldn't work because of type issues, by introducing a pass that
does for byval parameters what scalarrepl does for allocas)


(There are also 7 loads in the original bitcode as opposed to 3 in the
alloca'ing one, but with '-std-compile-opts' the 4 extra ones are removed by
-gvn)


-- 
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.