[LLVMdev] overflow + saturation stuff

[Dan Gohman]

Hi Chris,

Would it be better to split add into multiple opcodes instead of using
SubclassData bits?  Compare this:

    switch (I->getOpcode()) {
    case Instruction::Add: {
       switch (cast<Add>(I)->getOverflowBehavior()) {
       case AddInstruction::Wrapping:
          // ...
       case AddInstruction::UndefinedSigned:
          // ...
       case AddInstruction::UndefinedUnsigned:
          // ...
       }
    }
    }

with this:

    switch (I->getOpcode()) {
    case Instruction::Add:
      // ...
    case Instruction::SAdd_Open:
       // ...
    case Instruction::UAdd_Open:
       // ...
       break;
    }

I'm not sure about the name "Open"; fixed-size integers are "closed"  
under
wrapping and saturating add, so "open" sort of suggests an alternative,
and is concise.  But regardless, a one-level switch seems more  
convenient
than a two-level one.

It's a little less convenient in the case of code that wants to handle  
all the
flavors of add the same way, but it still seems worth it.

Encoding might be a concern, as Sub, Mul, Div, and Rem would all have
variants, but there are plenty of bits in SubclassID, and it doesn't  
look like
the bitcode representation uses packed opcode fields.

Dan

On Feb 7, 2009, at 2:17 PM, Chris Lattner wrote:

> Edwin was asking about how we should handle PR3328, how we should make
> GEP respect -fwrapv etc.  I wrote up some thoughts here if anyone is
> interested:
> http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev