From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Minor codegen silliness in ExecInterpExpr() |
Date: | 2017-09-28 22:47:20 |
Message-ID: | 20170928224720.lqasb3kyb2j73tpk@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-09-28 18:39:03 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2017-09-28 16:21:34 -0400, Tom Lane wrote:
> >> We could save a pointless register spill
> >> and reload if there were a temporary variable in there,
>
> > Makes sense. Do you want to make it so, or shall I?
>
> I just finished testing a patch, as attached. On my machine (again,
> not latest gcc: 4.4.7 on RHEL6 x86_64), it reduces the code size of
> execExprInterp.o by a fraction of a percent, and it seems to offer
> a slight benefit in "pgbench -S" performance although I'd not put
> much stock in that being reproducible.
Cool.
> + * Note: the reason for using a temporary variable "d", here and in
> + * other places, is that some compilers think "*op->resvalue = f();"
> + * requires them to evaluate op->resvalue into a register before
> + * calling f(), just in case f() is able to modify op->resvalue
> + * somehow. The extra line of code can save a useless register spill
> + * and reload, on architectures without many registers.
I'd remove the "without many registers" bit - that's really more an
functioncall ABI question (#caller vs #callee saved registers) than
about the actual architecture.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-09-28 22:52:28 | Re: Binary search in fmgr_isbuiltin() is a bottleneck. |
Previous Message | Peter Geoghegan | 2017-09-28 22:44:59 | Re: The case for removing replacement selection sort |