This adds an rsqrt op to the standard dialect, and lowers
it as 1 / sqrt to the LLVM dialect.
Mostly good, let's make sure it works for other types than f32.
This may not necessarily work if the operand type is not float. Maybe you could dispatch to different attributes based on type?
Could we also have a test for f64/double?
I tried to fix this by using getFloatAttr(operandType, 1.0) instead. Not sure whether operandType is the actual type it expects here though. Now I get llvm.float / llvm.double as types for the constants, before it was f32.
PTAL. The tests seem to work now.
Does this look ok? I am not sure whether the operand type of constant is allowed to be different from the result type. But seems there is no assert that is triggered, so maybe it supports broadcasts?
I think you need something like llvm.mlir.constant(dense<1.0> : vector<4xf32>) : !llvm<"<4 x float>">. We have SplatElementsAttr to broadcast constants in a vector, which is printed like that.
Sorry for not following up sooner, I was busy with other stuff yesterday. Today, with some help by Stephan I was able to make this work. I copied the handling with unrolling multi-dimensional vectors from the generic elementwise op handling. This could potentially be refactored, especially I wonder whether Tanh should also use this.
I copied the handling with unrolling multi-dimensional vectors from the generic elementwise op handling. This could potentially be refactored, especially I wonder whether Tanh should also use this.
I think I've seen a commit that removed the default tanh lowering recently. Anyway, a refactoring is welcome if you think it makes sense, in a separate commit.