[PATCH] D62699: [InlineCost] Add support for UnaryOperator

Thu May 30 15:15:11 PDT 2019

efriedma added a comment.

> FMul seems like a good first attempt. Maybe a cost of XOR by constant is better, but they're probably pretty similar anyway.

We're talking about the difference in cost between a runtime call and a xor by a constant; those are not really similar.

================
Comment at: llvm/lib/Analysis/InlineCost.cpp:1131
+  // is expensive, this may eventually become a library call. Treat the cost
+  // as such.
+  if (I.getType()->isFloatingPointTy() &&
----------------
cameron.mcinally wrote:
> craig.topper wrote:
> > efriedma wrote:
> > > Is this actually true?  fneg should be one or two native instructions for almost every combination of type/target, even ones that don't have native floating-point support.
> > Probably not. But it is the answer we would have gotten for fsub -0.0, %x.  Should we exclude both forms of writing fneg from this?
> This seems like a good check to have around for a general UnaryOperator. Of course there's only one right now, but who knows in the future...
We probably should treat "fsub -0.0, %x" the same way, yes.

It probably doesn't makes sense to try to predict the costs of future unary operators that don't current exist.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62699/new/

https://reviews.llvm.org/D62699