On 2020-06-10 14:15, Amit Khandekar wrote:
Well, how do we make sure we keep it that way? How do we prevent some
random rearranging of the code or some random compiler change to break
this again?
I believe the compiler rearranges the code segments w.r.t. one another
when those are independent of each other. I guess the compiler is able
to identify that. With our case, it's the for loop. There are some
variables used inside it, and that would prevent it from moving the
for loop. Even if the compiler finds it safe to move relative to
surrounding code, it would not spilt the for loop contents themselves,
so the for loop will remain intact, and so would the vectorization,
although it seems to keep an unrolled version of the loop in case it
is called with smaller iteration counts. But yes, if someone in the
future tries to change the for loop, it would possibly break the
auto-vectorization. So, we should have appropriate comments (patch has
those). Let me know if you find any possible reasons due to which the
compiler would in the future stop the vectorization even when there is
no change in the for loop.
We normally don't compile with -O3, so very few users would get the
benefit of this. We have CFLAGS_VECTOR for the checksum code. I
suppose if we are making the numeric code vectorizable as well, we
should apply this there also.
I think we need a bit of a policy decision from the group here.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
