[LLVMbugs] [Bug 13633] New: powerpc64 extra stores into parameter save area for register-passed struct

[bugzilla-daemon at llvm.org]

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

             Bug #: 13633
           Summary: powerpc64 extra stores into parameter save area for
                    register-passed struct
           Product: new-bugs
           Version: trunk
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: wschmidt at linux.vnet.ibm.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


On powerpc64-unknown-linux-gnu, the 64-bit PowerPC ELF Application Binary
Interface Supplement(see
http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html) states
that, "The first eight doublewords mapped to the parameter save area are never
stored in the parameter save area by the calling function."  In the following
example, the parameter "s" is passed r8:r9, but is also stored into the two
doublewords beginning at offset 40 of the parameter save area (offset 88 of the
stack frame).  The example is based on Figure 3-18 from the ABI:

typedef struct {
  int a;
  double dd;
} sparm;

extern void
func (int, double, int, long double, sparm, double, sparm, int, double);

void
test_struct_3 (void)
{
  sparm s, t;
  int c, d, e;
  long double ld;
  double ff, gg, hh;

  s.a = 0;
  s.dd = 2.5;
  t.a = 3;
  t.dd = 5.2;
  c = 23;
  d = 99;
  e = 127;
  ff = 1.6;
  gg = 1.7;
  hh = 1.8;

  func (c, ff, d, ld, s, gg, t, e, hh);
}

LLVM generates:

.L.test_struct_3:
    mflr 0
    std 31, -8(1)
    std 0, 16(1)
    stdu 1, -256(1)
    mr 31, 1
    li 3, 0
    stw 3, 232(31)
    li 4, 4097
    sldi 4, 4, 50
    li 3, 3
    std 4, 240(31)
    stw 3, 216(31)
    lis 4, 16404
    ori 4, 4, 52428
    sldi 4, 4, 32
    oris 4, 4, 52428
    ori 4, 4, 52429
    li 3, 23
    std 4, 224(31)
    stw 3, 212(31)
    li 3, 99
    stw 3, 208(31)
    li 3, 127
    stw 3, 204(31)
    lis 4, 16377
    lis 5, 16379
    lis 6, 16380
    ori 4, 4, 39321
    ori 5, 5, 13107
    ori 6, 6, 52428
    sldi 4, 4, 32
    sldi 5, 5, 32
    sldi 6, 6, 32
    oris 4, 4, 39321
    oris 5, 5, 13107
    oris 6, 6, 52428
    ori 4, 4, 39322
    ori 5, 5, 13107
    ori 6, 6, 52429
    std 4, 168(31)
    addi 4, 31, 176
    std 5, 160(31)
    std 6, 152(31)
    lfd 3, 8(4)
    lfd 2, 176(31)
    lfd 4, 160(31)
    lwz 5, 208(31)
    lfd 1, 168(31)
    lwz 3, 212(31)
    lwz 4, 204(31)
    ld 6, 240(31)
    ld 7, 232(31)
    std 6, 96(1)          <-- Extra
    std 7, 88(1)          <-- stores
    ld 6, 224(31)
    ld 7, 216(31)
    std 6, 120(1)
    std 7, 112(1)
    lis 6, .LCPI0_0 at ha
    lfd 5, .LCPI0_0 at l(6)
    ld 9, 240(31)
    ld 8, 232(31)
    std 4, 128(1)
    bl func
    nop
    addi 1, 1, 256
    ld 0, 16(1)
    ld 31, -8(1)
    mtlr 0
    blr 

This is not tremendously serious but is wasteful and is technically not
compliant with the ABI.

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