相关疑难解决方法(0)

我一直在挖掘Linux内核的某些部分,发现这样的调用:

if (unlikely(fd < 0))
{
    /* Do something */
}

要么

if (likely(!err))
{
    /* Do something */
}

我找到了它们的定义:

#define likely(x)       __builtin_expect((x),1)
#define unlikely(x)     __builtin_expect((x),0)

我知道它们是为了优化,但它们是如何工作的？使用它们可以预期性能/尺寸减少多少？至少在瓶颈代码中(当然在用户空间中)是否值得麻烦(并且可能失去可移植性).

例:

if (almost_always_false_condition) {
       // do something
}

有没有办法建议编译器在99%的条件下将是假的.条件计算需要大约60个周期进行检查,编译器本身无法在编译时计算.

(gcc 4.3)

我碰巧写了一个if-else语句,条件在大多数时候都是假的(检查是否分配了静态指针).编译器优化哪一个会更好？或者他们是平等的？该函数将被调用很多次,因此优化其性能至关重要.

void foo() {
  static int * p = NULL;
  if (p == NULL) {
     p = (int *) malloc( SIZE * sizeof(int)); 
  }
  //do something here
} 

void foo() {
  static int * p = NULL;
  if (p != NULL) {
    //do something here 
  } else {
    p = (int *) malloc( SIZE * sizeof(int));  
    //do something
  }
}

是否有任何方法可以向编译器表明您知道特定变量的值必须在代码中的某个特定范围内,以帮助编译器进行优化？我正在编写一个库,可以在编译时知道一些变量的范围,如果它能以某种方式将这些信息传递给编译器,那么编译器就可以使用它进行优化,这将是非常好的.我想为任何能够工作的编译器添加支持,即使它不能用于所有编译器(听起来像某些编译器可以作为扩展的东西,但我没有发现任何).我知道我可以这样写:

if(x < COMPILE_TIME_MIN or x > COMPILE_TIME_MAX)
    return;
// compiler will assume for code below that x is in range COMPILE_TIME_MIN..COMPILE_TIME_MAX

但那是运行时检查.也许有一些技巧让编译器在没有这种检查的情况下对范围做出假设？