Closed
Description
Is your feature request related to a problem? Please describe.
Right now we require a specific converter definition for each operator we support. In the evaluator library
we support the ability to handle multiple operator variants with the same evaluator. It would be nice to support this for converters as well.
Describe the solution you'd like
We should be able to set more than one operator to be handled by a converter implementation when we register. Something like the following syntax would be helpful.
.pattern({{
"aten::add.Scalar(Tensor self, Scalar other, Scalar alpha=1) -> (Tensor)",
"aten::add_.Scalar(Tensor self, Scalar other, Scalar alpha=1) -> (Tensor)"},
[](ConversionCtx* ctx, const torch::jit::Node* n, args& args) -> bool {
// Should implement self + alpha * other
auto self = args[0].ITensorOrFreeze(ctx);
auto otherScalar = args[2].unwrapToScalar().to<float>() * args[1].unwrapToScalar().to<float>();
auto other = tensor_to_const(ctx, torch::tensor({otherScalar}));
auto add =
add_elementwise(ctx, nvinfer1::ElementWiseOperation::kSUM, self, other, util::node_info(n));
TRTORCH_CHECK(add, "Unable to create add layer from node: " << *n);
add->setName(util::node_info(n).c_str());
auto out = ctx->AssociateValueAndTensor(n->outputs()[0], add->getOutput(0));
LOG_DEBUG("Output tensor shape: " << out->getDimensions());
return true;
}})Describe alternatives you've considered
This could also be done via some structure in the lowering passes, we might want to make some infrastructure to make these aliases simple to define.
Additional context