incompatible return of small struct in 32-bit PowerPC BSD

Quuxplusone commented 5 years ago


Bugzilla Link	PR40736
Status	RESOLVED FIXED
Importance	P normal
Reported by	George Koehler (kernigh@gmail.com)
Reported on	2019-02-14 18:38:10 -0800
Last modified on	2020-05-28 16:54:45 -0700
Version	7.0
Hardware	Macintosh OpenBSD
CC	chmeeedalf@gmail.com, hfinkel@anl.gov, llvm-bugs@lists.llvm.org, marklmi26-fbsd@yahoo.com, nemanja.i.ibm@gmail.com
Fixed by commit(s)
Attachments	`llvm-9-sret-1.diff` (10741 bytes, text/plain) `llvm-9-sret-2.diff` (10237 bytes, text/plain) `llvm-9-sret-3.diff` (11792 bytes, text/plain) `llvm-9-sret-4.diff` (12467 bytes, text/plain)
Blocks
Blocked by
See also

clang 7.0.1 and gcc use incompatible conventions to return a small struct (of
up to 8 bytes) in my PowerBook G4 running OpenBSD/macppc, where gcc is the main
compiler and clang is a recent arrival.  This causes my qt5 built with clang to
crash when trying to call my libxcb built with gcc.  Functions like
xcb_intern_atom() return a cookie as a 4-byte struct containing an unsigned int.

llvm/lib/Target/PowerPC provides the RetCC_PPC convention, but I don't see
where it returns structs.  llvm and clang are returning structs in memory, with
the caller passing in r3 a pointer to the return area.  gcc in OpenBSD returns
smaller structs in registers r3 and r4.  gcc in NetBSD/macppc seems like
OpenBSD.  I don't know what happens in FreeBSD.

There are 2 versions of the ELF ABI (called "SVR4" in llvm):

- System V ABI: PowerPC Processor Supplement (1995)
- Power Architecture 32-bit ABI Supplement 1.0 (2011)
  It added features like secure PLT and thread-local storage.
  Search for Power-Arch-32-bit-ABI-supp-1.0-Unified.pdf

The later ABI from 2011, in section 3.2.5 Return Values, said,

> ATR-LINUX: Aggregates or unions of any length will be returned in a storage
> buffer allocated by the caller. The caller will pass the address of this
> buffer as a hidden first argument in r3, causing the first explicit argument
> to be passed in r4. This hidden argument is treated as a normal formal
> parameter, and corresponds to the first doubleword of the parameter save
> area.
>
> ATR-EABI: Aggregates or unions whose size is less than or equal to eight
> bytes shall be returned in r3 and r4, as if they were first stored in memory
> area and then the low-addressed word were loaded in r3 and the
> high-addressed word were loaded into r4. Bits beyond the last member of the
> structure or union are not defined.

Larger structs in ATR-EABI get returned like in ATR-LINUX.  llvm and clang
follow ATR-LINUX.  gcc in OpenBSD is almost like ATR-EABI, but (in my big-
endian PowerPC) takes the undefined bytes from before the first member, not
"beyond the last member of the structure or union".

I compiled this code with -S in clang 7.0.1 and in gcc:

struct s1 { char c; };
struct s4 { char c[4]; };
struct s7 { char c[7]; };
struct s8 { char c[8]; };
struct s9 { char c[9]; };
struct sd { double d; };
struct s1 ret1(struct s1 *s) { return *s; }
struct s4 ret4(struct s4 *s) { return *s; }
struct s7 ret7(struct s7 *s) { return *s; }
struct s8 ret8(struct s8 *s) { return *s; }
struct s9 ret9(struct s9 *s) { return *s; }
struct sd retd(struct sd *s) { return *s; }

In clang, all these functions get the return area in r3, and the parameter s in
r4, so they copy the correct number of bytes from where r4 points to where r3
points.  In gcc, all but ret9() get the parameter in r3, and copy bytes from
where r3 points to r3 itself, or to r3 and r4.

I now show instructions from
$ egcc -O2 -fno-stack-protector -S retxam.c

This is gcc 8.2.0 with OpenBSD's patches.  Older versions of gcc in NetBSD and
OpenBSD write different instructions but seem to get the same result.  I add my
own comments and change 3 to %r3.

ret1 in gcc:
lbz %r3, 0(%r3)  # r3 = 0.0.0.c

ret4 in gcc:
lwz %r3, 0(%r3)  # r3 = c0.c1.c2.c3

ret7 in gcc:
lhz %r8, 4(%r3)             # r8 = 0.0.c4.c5
lwz %r7, 0(%r3)             # r7 = c0.c1.c2.c3
rlwinm %r6, %r8, 8, 8, 15   # r6 = 0.c4.0.0
lbz %r4, 6(%r3)             # r4 = 0.0.0.c6
slwi %r10, %r7, 24          # r10 = c3.0.0.0
rlwinm %r8, %r8, 8, 16, 23  # r8 = 0.0.c5.0
or %r9, %r10, %r6           # r9 = c3.c4.0.0
srwi %r3, %r7, 8            # r3 = 0.c0.c1.c2
or %r9, %r9, %r8            # r9 = c3.c4.c5.0
or %r4, %r9, %r4            # r4 = c3.c4.c5.c6

ret7 in gcc looks overly long.  I would try to avoid the rotations by using
misaligned loads: lwz %r4, 3(%r3) and lhz *, 1(%r3)

ret8 in gcc:
lwz %r4, 4(%r3)  # r4 = c4.c5.c6.c7
lwz %r3, 0(%r3)  # r3 = c0.c1.c2.c3

ret9 in gcc:
lwz %r7, 0(%r4)   # r7 = c0.c1.c2.c3
lwz %r8, 4(%r4)   # r8 = c4.c5.c6.c7
lbz %r10, 8(%r4)  # r10 = 0.0.0.c8
stw %r7, 0(%r3)   # r3[0..3] = c0.c1.c2.c3
stw %r8, 4(%r3)   # r3[4..7] = c4.c5.c6.c7
stb %r10, 8(%r3)  # r3[8] = c8

retd in gcc is exactly like ret8: it puts the struct's 8-byte double in r3 and
r4, not in a floating-point register.

Right now, I can compile clang from llvm-project.git master, but I can't run
it, so I don't know how it returns structs.  I am able to run OpenBSD's package
of clang 7.0.1.

Quuxplusone commented 5 years ago

Attached llvm-9-sret-1.diff (10741 bytes, text/plain): draft 1, incomplete, sret-in-reg for callee but not caller

Quuxplusone commented 5 years ago

Attached llvm-9-sret-2.diff (10237 bytes, text/plain): draft 2, incomplete, small sret IR pass

Quuxplusone commented 5 years ago

Attached llvm-9-sret-3.diff (11792 bytes, text/plain): draft 3, small sret in PPCTargetLowering

Quuxplusone commented 5 years ago

Attached llvm-9-sret-4.diff (12467 bytes, text/plain): draft 4, new comment with examples of returned small structs