GNU内置函数`__builtin_unreachable`如何在这段代码中起作用？

Question

I have a code snippet in my project in which the __builtin_unreachable function has been used but I don't know why it is needed here.

And I read from GNU __builtin_unreachable , it seems that the __builtin_unreachable function is used to inform the compiler this line will never be reached during the CPU run time, so that a lot of complains in compilation can be prevented in advance. But I am not understood why this feature is needed in this code snippet, it seems nothing will happen by removing the __builtin_unreachable .

# define ATHCONTAINERS_ASSUME(x) do { if (!(x)) __builtin_unreachable(); } while(0)


inline
void*
AuxVectorData::Cache::getDataArray (SG::auxid_t auxid,
                                    AuxVectorData& parent)
{
  // This function is important for performance.
  // Be careful when changing it.

  void* ptr = cachePtr (auxid);
  if (ATHCONTAINERS_UNLIKELY (ptr == 0)) {
    // We don't have the variable cached.
    // Call the out-of-line routine to get it cached.
    ptr = parent.getDataOol (auxid, false);

    // These inform the compiler of what the previous call did.
    // They tell the optimizer that it can now assume that this cache
    // entry is valid.
    ATHCONTAINERS_ASSUME (ptr != 0); 
    ATHCONTAINERS_ASSUME (cachePtr (auxid) != 0); 
    ATHCONTAINERS_ASSUME (cachePtr (auxid) == ptr);
  }
  return ptr;
}

Answer 1

ATHCONTAINERS_ASSUME tells the compiler that its argument x cannot be false. This relieves the compiler from having to generate any code to accommodate the possibility that x is false. For example, when the compiler sees ATHCONTAINERS_ASSUME (ptr != 0) it can assume ptr is not null, and any code which contradicts that assumption can be optimized away, as it would be undefined behavior.

For example, since getDataArray() is inline , the compiler can know at every call site that the returned pointer will never be null. So if a caller does this:

if (void* p = cache.getDataArray(aux, parent))
    memcpy(p, "OK", 2);

The compiler can generate code which directly writes "OK" without performing the null check.

Answer 2

That's pretty interesting, and new to me.

My best understanding, from the documentation you linked to which says:

If control flow reaches the point of the __builtin_unreachable() , the program is undefined.

So basically the macro reaches undefined behavior if the condition is false. Thus, the compiler is assumed to be able to optimize based on the assumption that that doesn't happen, ie the conditions are not false.

I'd be interested in comparing the result from building the code with and without those macros, to further understand what actual difference it makes.

Relying on this to get some kind of optimization to happen seems kind of "brittle" to me, since it assumes a lot about the internal functioning of the compiler.

Answer 3

As the code comment indicates, it tells stories to the optimizer.

The first thing this tells, is that the compiler can assume that the return value is not a null pointer. It would probably improve the readability of the code if another gcc extension would be used instead, namely __attribute__((__returns_nonnull__)) . Adding this to the interface of getDataArray would also guarantee that property, even if the the compiler decides that he can't inline it for whatever reason.

But it is telling more than that. It also tells (or tries to tell) that future calls to cachePtr with the same parameter will return the same result.

All these properties would probably better be guaranteed by removing the unused parent parameter (to avoid aliasing analysis) and by also adding __attribute__((__const__)) to getDataArray .