MSVC中microbenchmarks的優化障礙：告訴優化器你有clobber內存？

Question

Chandler Carruth在他的CppCon2015 talk中引入了兩個函數，可用於對優化器進行細粒度抑制。他們寫微觀基準是非常有用的，優化器不會簡單地導致無意義。

void clobber() { 
    asm volatile("" : : : "memory"); 
} 

void escape(void* p) { 
    asm volatile("" : : "g"(p) : "memory"); 
}  

這些使用內聯彙編語句來更改優化器的假設。

clobber中的彙編語句聲明其中的彙編代碼可以讀寫內存中的任何位置。實際彙編代碼是空的，但優化器不會查看它，因爲它是asm volatile。它相信，當我們告訴它代碼可能在內存中的任何地方都可以讀寫。這有效地防止優化器在調用clobber之前重新排序或丟棄內存寫入，並在調用clobber＆dagger;之後強制讀取內存。

escape中的那個，另外使指針p對組裝塊可見。同樣，由於優化器不會查看實際的內聯彙編代碼，因此代碼可能爲空，並且優化器仍然會假定該塊使用指針p指向的地址。這有效地強制任何p點在內存中，而不是在寄存器中，因爲程序集塊可能執行從該地址讀取。 （這很重要，因爲clobber函數不會強制讀取或寫入編譯器決定放入寄存器的任何內容，因爲clobber中的彙編語句沒有聲明任何特別的內容必須對於組裝）。

所有這些都是在沒有任何其他代碼直接由這些「障礙」生成的情況下發生的。它們純粹是編譯時的工件。

這些使用GCC和Clang支持的語言擴展。有沒有辦法在使用MSVC時有類似的行爲？

---

＆dagger;爲了理解優化器爲什麼要這樣想，想象一下，如果程序集塊是一個循環，爲內存中的每個字節加1。

Answer 1

我用以下來代替escape。

#ifdef _MSC_VER 
#pragma optimize("", off) 
template <typename T> 
inline void escape(T* p) { 
    *reinterpret_cast<char volatile*>(p) = 
     *reinterpret_cast<char const volatile*>(p); // thanks, @milleniumbug 
} 
#pragma optimize("", on) 
#endif 

這不是完美的，但它足夠接近我想。

不幸的是，我沒有辦法效仿clobber。

Answer 2

鑑於your approximation of escape()，你也應該罰款與clobber()以下近似（注意，這是一個想法草案，推遲了一些解決方案的功能nextLocationToClobber()的實現）：

// always returns false, but in an undeducible way 
bool isClobberingEnabled(); 

// The challenge is to implement this function in a way, 
// that will make even the smartest optimizer believe that 
// it can deliver a valid pointer pointing anywhere in the heap, 
// stack or the static memory. 
volatile char* nextLocationToClobber(); 

const bool clobberingIsEnabled = isClobberingEnabled(); 
volatile char* clobberingPtr; 

inline void clobber() { 
    if (clobberingIsEnabled) { 
     // This will never be executed, but the compiler 
     // cannot know about it. 
     clobberingPtr = nextLocationToClobber(); 
     *clobberingPtr = *clobberingPtr; 
    } 
} 

---

UPDATE

問題：你將如何保證isClobberingEnabled返回false「以不可誘導的方式」？當然，將定義放在另一個翻譯單元中會很簡單，但是在啓用LTCG的那一刻，該策略就會失敗。你有什麼想法？

答：我們可以採取一個難以證明從數論性質，例如，Fermat's Last Theorem的優勢：

bool undeducible_false() { 
    // It took mathematicians more than 3 centuries to prove Fermat's 
    // last theorem in its most general form. Hardly that knowledge 
    // has been put into compilers (or the compiler will try hard 
    // enough to check all one million possible combinations below). 

    // Caveat: avoid integer overflow (Fermat's theorem 
    //   doesn't hold for modulo arithmetic) 
    std::uint32_t a = std::clock() % 100 + 1; 
    std::uint32_t b = std::rand() % 100 + 1; 
    std::uint32_t c = reinterpret_cast<std::uintptr_t>(&a) % 100 + 1; 

    return a*a*a + b*b*b == c*c*c; 
}