llvm dev - Oct 2009 - [LLVMdev] Problem in InlineCost.h

There's a problem with LLVM version 2.5 compiled under G++ 4.1.2
which involves computing the cost of inlining a function. It works fine
in a debug build. However, the Release build seems to tickle a g++ bug.

Here is the code, from InlineCost.h:

  class InlineCost {
    enum Kind {
      Value,
      Always,
      Never
    };

    int Cost : 30;
    unsigned Type :  2;

    InlineCost(int C, int T) : Cost(C), Type(T) {
      assert(Cost == C && "Cost exceeds InlineCost
precision");
    }

If the cost C is negative, then the value retrieved for Cost is a large
positive value, causing the assertion to fail. Obviously, G++ has messed
up the bit field extraction. I tried changing the type of Cost to an
explicit
"signed int", but this doesn't help. 

It might be best to either extract this field with explicit masking and sign
extension, or just not use bit fields and waste a word. I've found in the
past
that other compilers (e.g. Sun) don't handle signed bit fields correctly. 
I fixed this problem by just rounding a negative cost up to zero, which
seems
to work, but I don't know if this has any nasty effect on the inlining
heuristics.

Regards -- Ken McMillan
 
-- 
View this message in context:
http://www.nabble.com/Problem-in--InlineCost.h-tp25979874p25979874.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.

Hi Ken,
> There's a problem with LLVM version 2.5 compiled under G++ 4.1.2
> which involves computing the cost of inlining a function. It works fine
> in a debug build. However, the Release build seems to tickle a g++ bug.
this is fixed in 2.6.

Ciao,

Duncan.