[llvm-commits] [PATCH][FAST-MATH] recognize fp negation

[Shuxin Yang]

>
>
> Now, BinaryOperator is quite special because the specific binary 
> operators don't get their own instruction classes. I think this is 
> generally a good thing to limit the interface creep of the IR, but at 
> some point it might be reasonable to introduce subclasses for 
> particular instructions where there are a large number of useful 
> predicates which are only relevant to a *single* operation. I don't 
> think we're there yet though. As long as the predicate methods on 
> BinaryOperator make sense for more than one operation, I think they're 
> totally reasonable.
>
I agree in general that the functions which are not applicable to large 
# of instructions should not creep into class BinaryOperator.

  However, engineering is a not a matter of black-&-white, it is a 
matter of degree. There is no absolute true or false...
I personally think the original author made right calls by defining 
"isNeg()" and "isFNeg()" in BinaryOperator.
I think these two functions, in some senses,  remedy the "defect" that 
the IR doesn't have Negation operator.

We don't have many such IR "defect" . I personally think BinaryOperator 
is a convenient place to remedy
such "defects"/inconveniences.  Unless BinaryOperator is a extremely 
terrible place for is*Neg(), I prefer
there stay where they are today.

   That said, I don't strong objection to moving these 2 functions to 
other place either.