tree ddb7d53229c8c157070315db9882dd746128aefe
parent 72990df072a56996612169f07c5752a6924288bb
author Koakuma <koachan@protonmail.com> 1705267731 +0700
committer GitHub <noreply@github.com> 1705267731 -0500
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJlpFITCRBK7hj4Ov3rIwAACcwIAHc7Wbo3WoXlgK+Bpygeygj+
 ah8diSBkw0FZr/aRRzMmVwgcOwpohe79QXWbuxg/pUHFJbeOOqnGfOJRs95EIHKF
 xD2t+eXe66s+TOg8gmSliVkjJ/RvGyzTZltLkSIUcSXrUNEl5nQtaicrC38enPWj
 LKlIjYBvn9nYQkAr30AVRwctQ9V4Zw7qiEBNSOXAFUfdvd4+Gvp5N/Xn6GnfD9/o
 E+PetA6Mfqc1dJhxPoR1J2EZY6Uv0VS5xiWq7abRgMEHw9Ed0EgOZgycCNmcWveL
 +64fiP1DrMqelsz3CnGp7EZXXdeXAZGkNLd/zlzI8zSGU/EZR1H9K7XbrwvqVgg=
 =DYPS
 -----END PGP SIGNATURE-----
 

[SPARC] Prefer RDPC over CALL to implement GETPCX for 64-bit target (#77196)

On 64-bit target, prefer usng RDPC over CALL to get the value of %pc.
This is faster on modern processors (Niagara T1 and newer) and avoids polluting
the processor's predictor state.

The old behavior of using a fake CALL is still done when tuning for classic
UltraSPARC processors, since RDPC is much slower there.

A quick pgbench test on a SPARC T4 shows about 2% speedup on SELECT loads,
and about 7% speedup on INSERT/UPDATE loads.