On Sun, Sep 4, 2016 at 12:42 PM, Emre Hasegeli <e...@hasegeli.com> wrote: >> The first patch fails to apply due to bit-rot. That's easy enough >> to correct, but then it runs into warnings on make: > > Rebased and fixed.
These patches apply and build on top of 5c609a74 with no problems, but `make check` finds differences per the attached. Please investigate why the regression tests are failing and what the appropriate response is. >> Something to consider before posting new version -- should we >> change some of those macros to static inline (in the .h files) to >> avoid double-evaluation hazards? They might perform as well or >> even better that way, and remove a subtle programmer foot-gun. > > One reason to keep them as macros is that they are currently > supporting both float4 and float8. Currently they look like this: > > FLOAT_EQ(val1, val2) > FLOAT_PL(result, val1, val2) > > I guess if we would use inline functions, they would look like: > > FLOAT8_EQ(val1, val2) > result = FLOAT8_PL(val1, val2) > > Result would need to be defined again in the function to be checked > for overflow. I think this way would be more developer-friendly. I > have gone some trouble to allocate the result to be able to use the > macros. Do you know if the performance of both would be the same? In one case where I was concerned that a static inline definition would not perform as well as a macro, I went so far as to compare the compiled code for both at a number of call sites in an optimized build and found that a reasonably current gcc generated *identical* code for both. Of course, this will not always be the case -- in particular for macros which require multiple evaluations of one or more parameters and they are not simple literals. In such cases, the static inline often benchmarks faster because the results from the potentially expensive expression can be stored on the stack or in a register, and just referenced again. > I am not much experienced in C. If you think that inline functions > are better suited, I can rework the patches. I suspect that they will be as fast or faster, and they eliminate the hazard of multiple evaluation, where a programmer might not be aware of the multiple evaluation or of some side-effect of an argument. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Description: Binary data
-- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers