[PATCH] D62521: [IRBuilder] Add CreateFNegFMF(...) to the IRBuilder

[Cameron McInally via Phabricator via llvm-commits]

cameron.mcinally added a comment.

In D62521#1521599 <https://reviews.llvm.org/D62521#1521599>, @craig.topper wrote:

> So my thought is that using UnaryOperator::CreateFNeg is only safe if we only use it when we started with an fneg. Or that the we are sure all passes downstream of whichever passes uses this can handle the presence of an fneg instruction in IR even if they don't know how to optimize it. Basically I'm concerned with sudden introduction of fnegs into IR before all passes are ready. But if we started with an fneg then it must have been testing IR and not clang produced IR.


That is a good point.

So we can't say, right now, that producing the unary FNeg is relatively optimal, but I would think that it's fairly functional from the existence of `ISD::FNEG` in ISel. If targets didn't support that, we'd see failures already (or they're untested).

I guess my concern is that producing a binary FNeg in this new function pushes the goal posts back. New uses of this function may need to be optimized later, which may be even more work. We also know that there will be no regressions, so why not move forward.

That said, I could see the argument that CreateFNeg(...) + separate code to copy FMF does not function the same as CreateFNegFMF(...).

I don't feel particularly strongly about this either way though...


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

https://reviews.llvm.org/D62521