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
- rearrange-makeOrderedSetArgs.patch (text/x-diff) patch
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
-
Fix optimization hazard in gram.y's makeOrderedSetArgs(), redux.
- abfce4e46870 9.5.24 landed
- eb48619d01d7 9.6.20 landed
- 9f3d3fb8702b 10.15 landed
- e3868c7d59d4 11.10 landed
- 8b231d975328 12.5 landed
- dc14aa038e20 13.1 landed
- 8d2a01ae12cd 14.0 landed
-
Improve pg_list.h's linitial(), lsecond() and co macros
- cc99baa43e0e 14.0 cited