Re: Recent failures on buildfarm member hornet

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
Cc: David Rowley <dgrowleyml@gmail.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2020-10-07T21:48:19Z
Lists: pgsql-hackers

Attachments

Noah Misch <noah@leadboat.com> writes:
> On Thu, Oct 08, 2020 at 09:15:12AM +1300, David Rowley wrote:
>> It would be interesting to see gram.s from both cc99baa4~1 and cc99baa4.

> Attached.  Both generated like this:

Hm.  I'm too lazy to go bone up on PPC64 ABI conventions, but this does
look suspiciously like the compiler is doing what I feared:

GOOD:

	lwa        r31,4(r27)            # fetching list_length(directargs) ?
	.line	16295
	ori        r3,r27,0x0000
	bl         .list_concat{PR}
	ori        r0,r0,0x0000
	std        r3,112(SP)
	.line	16295
	extsw      r3,r31		# ... and passing it to makeInteger
	bl         .makeInteger{PR}
	ori        r0,r0,0x0000

BAD:

	ori        r3,r31,0x0000
	bl         .list_concat{PR}
	ori        r0,r0,0x0000
	std        r3,112(SP)
	.line	16288
	lwa        r3,4(r31)            # fetching list_length(directargs) ?
	bl         .makeInteger{PR}
	ori        r0,r0,0x0000

(I'm confused about why the line numbers don't match up, since cc99baa4
did not touch gram.y.  But whatever.)

I'm tempted to propose the attached small code rearrangement, which
might dissuade the compiler from thinking it can get away with this.
While I concur with your point that an old xlc version might not be
that exciting, there could be other compilers doing the same thing
in the future.

			regards, tom lane

Commits

  1. Fix optimization hazard in gram.y's makeOrderedSetArgs(), redux.

  2. Improve pg_list.h's linitial(), lsecond() and co macros