Doble comprobación de Lock Singleton en C++11

¿Los siguientes datos de implementación de singleton están libres de carreras?

static std::atomic<Tp *> m_instance;
...

static Tp &
instance()
{
    if (!m_instance.load(std::memory_order_relaxed))
    {
        std::lock_guard<std::mutex> lock(m_mutex);
        if (!m_instance.load(std::memory_order_acquire))
        {
            Tp * i = new Tp;
            m_instance.store(i, std::memory_order_release);    
        }    
    }

    return * m_instance.load(std::memory_order_relaxed);
}

Es std::memory_model_acquire de la operación de carga superflua? ¿Es posible relajar aún más las operaciones de carga y almacenamiento cambiándolas a std::memory_order_relaxed? En ese caso, ¿es suficiente la semántica de acquire/release de std::mutex para garantizar su corrección, o también se requiere otro std::atomic_thread_fence(std::memory_order_release) para asegurar que las escrituras en la memoria del constructor sucedan antes de la tienda relajada? Sin embargo, es el uso de valla equivalente a tener la tienda con memory_order_release?

EDIT: Gracias a la respuesta de John, se me ocurrió la siguiente implementación que debería ser libre de carreras de datos. A pesar de que la carga interna podría ser no atómica en absoluto, decidí dejar una carga relajada en que no afecta el rendimiento. En comparación con tener siempre una carga externa con el orden de adquisición de memoria, la maquinaria thread_local mejora el rendimiento de acceder a la instancia de aproximadamente un orden de magnitud.

static Tp &
instance()
{
    static thread_local Tp *instance;

    if (!instance && 
        !(instance = m_instance.load(std::memory_order_acquire)))
    {
        std::lock_guard<std::mutex> lock(m_mutex);
        if (!(instance = m_instance.load(std::memory_order_relaxed)))
        {
            instance = new Tp; 
            m_instance.store(instance, std::memory_order_release);    
        }    
    }
    return *instance;
}