為什麼編譯器最佳化會破壞這個 64 位元交換功能？

為什麼最佳化會降低這個函數的效能

在一次程式設計專業的大學講座中，一位講師提出了一個讓學生感到困惑的函數：

inline u64 Swap_64(u64 x)
{
    u64 tmp;
    (*(u32*)&tmp)       = Swap_32(*(((u32*)&x)+1));
    (*(((u32*)&tmp)+1)) = Swap_32(*(u32*) &x);

    return tmp;
}

最初，功能運作順利，但在啟用高最佳化等級後，它變得惰性。這種行為背後的原因在於嚴格別名規則的概念。

嚴格別名違規

提供的程式碼違反了嚴格別名規則，該規則規定物件只能是透過相容的指標類型存取。在這種情況下，u32 和 u64 指標指向可能重疊的內存，但編譯器假設它們代表不同的物件。這個假設允許它優化對臨時變數 tmp 的賦值，從而使函數無效。

為什麼會發生最佳化

允許編譯器基於假設來最佳化程式碼關於指標行為。由於 u32 和 u64 是不同的類型，編譯器假定它們不指向同一內存，並且透過 u32 指標所做的更改不會影響 tmp 的值。此優化導致了觀察到的行為。

保留函數行為的解決方案

為了防止程式碼被最佳化，指標類型應與存取的資料類型相符。一種方法是使用聯合直接存取位元：

typedef union
{
  uint32_t u32;
  uint16_t u16[2];
} U32;

uint32_t swap_words(uint32_t arg)
{
  U32 in;
  uint16_t lo;
  uint16_t hi;

  in.u32    = arg;
  hi        = in.u16[0];
  lo        = in.u16[1];
  in.u16[0] = lo;
  in.u16[1] = hi;

  return (in.u32);
}

透過使用聯合，我們確保指標和資料類型相容，防止編譯器最佳化預期的變更。

以上是為什麼編譯器最佳化會破壞這個 64 位元交換功能？的詳細內容。更多資訊請關注PHP中文網其他相關文章！