Page MenuHomePhabricator

[IRBuilder] Add CreateFNegFMF(...) to the IRBuilder
ClosedPublic

Authored by cameron.mcinally on May 28 2019, 6:44 AM.

Details

Summary

@craig.topper brought up the question -- do we want to call UnaryOperator::CreateFNeg(...) or BinaryOperator::CreateFNeg(...) here. My current thinking is that we want to call the UnaryOperator flavor, since this is a new entry point. Using the UnaryOperator is the end goal and there will be no regressions from this decision. This will minimize the work going forward.

I'm open to other opinions though...

Diff Detail

Repository
rL LLVM

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptMay 28 2019, 6:44 AM

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.

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...

This comment was removed by cameron.mcinally.

Have IRBuilder::CreateFNegFMF(...) return a BinaryOperator as discussed...

spatel accepted this revision.Jun 9 2019, 8:46 AM

LGTM

llvm/include/llvm/IR/IRBuilder.h
1381–1382

Add a TODO comment about using UnaryOperator here in the future, so we don't forget?

This revision is now accepted and ready to land.Jun 9 2019, 8:46 AM
This revision was automatically updated to reflect the committed changes.