================
@@ -825,14 +818,23 @@ class ScalarExprEmitter : public
StmtVisitor<ScalarExprEmitter, mlir::Value> {
return builder.createOrFold<cir::MinusOp>(loc, operand, nsw);
}
- mlir::Value emitIncOrDec(const UnaryOperator *e, mlir::Value input,
- bool nsw = false) {
+ mlir::Value emitIntIncOrDec(const UnaryOperator *e, mlir::Value input,
+ bool nsw = false) {
mlir::Location loc = cgf.getLoc(e->getSourceRange().getBegin());
return e->isIncrementOp()
? builder.createOrFold<cir::IncOp>(loc, input, nsw)
: builder.createOrFold<cir::DecOp>(loc, input, nsw);
}
+ mlir::Value emitFloatIncOrDec(const UnaryOperator *e, mlir::Value input) {
+ mlir::Location loc = cgf.getLoc(e->getSourceRange().getBegin());
+ auto fpType = mlir::cast<cir::FPTypeInterface>(input.getType());
+ mlir::Value amount = builder.getConstFP(
+ loc, input.getType(), llvm::APFloat(fpType.getFloatSemantics(), 1));
+ return e->isIncrementOp() ? builder.createFAdd(loc, input, amount)
----------------
erichkeane wrote:
Hmm... interesting thought. I guess I just assumed value, but you can't really
see any value to it different than just an 'add/sub' 1 + load + store?
I think the value is at least seeing the self-modifying inc/dec in the case of
loops (its a lot easier I would expect to see that than the load/add/store
pattern?) to recognize 'typical' loops?
In retrospect, IF that is my justification, I can't see a justification for
doing that with floats, as that is a really uncommon pattern.
https://github.com/llvm/llvm-project/pull/193215
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
