[LLVMdev] overflow + saturation stuff

Chris Lattner clattner at apple.com
Mon Feb 9 20:49:43 PST 2009


On Feb 9, 2009, at 8:20 AM, Dan Gohman wrote:

>
> On Feb 8, 2009, at 11:33 AM, Chris Lattner wrote:
>
>>
>> On Feb 8, 2009, at 8:58 AM, Dan Gohman wrote:
>>
>>> Hi Chris,
>>>
>>> Would it be better to split add into multiple opcodes instead of
>>> using
>>> SubclassData bits?
>>
>> No, I don't think so.  The big difference here is that (like type)
>> "opcode" never changes for an instruction once it is created.  I
>> expect that optimizations would want to play with these (e.g. convert
>> them to 'undefined' when it can prove overflow never happens) so I
>> think it is nice to not have it be in the opcode field.
>
> Why is this?  If SubclassData can be modified, why not SubclassID too?
> Having it const may help guard against something accidentally changing
> it to an opcode that would require a different subclass, but it's a
> private
> member, so modifications to it could be fairly effectively controlled.

There is no technical reason, it just provides a more clear API and  
makes it easier to reason about.  For example since SubclassID can't  
change, you don't have issues where you'd need to change the actual  
class of the impl.

-Chris



More information about the llvm-dev mailing list