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