From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Recent failures on buildfarm member hornet |
Date: | 2020-10-07 21:48:19 |
Message-ID: | 2397925.1602107299@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Noah Misch <noah(at)leadboat(dot)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
Attachment | Content-Type | Size |
---|---|---|
rearrange-makeOrderedSetArgs.patch | text/x-diff | 906 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2020-10-07 21:51:20 | Re: Two fsync related performance issues? |
Previous Message | Noah Misch | 2020-10-07 21:20:56 | Re: Recent failures on buildfarm member hornet |