CC @apaszke @zdevito @jamesr66a

So I must admit that the faults in the implementation strategy are probably mine here.

So this is what I had in mind when I looked into making the JIT actually use python_arg_parser code for determining the function to use.
So when I think about this, I would look into changing this essentially to imitating (or using) python arg parser.h/cpp in that we lookup the name and then go through the iterated positions as the parameters processed by the JIT are not automatically converted into the right descriptor string.
However, that would be a largish change. In my preliminary patch, I implemented a FunctionSignature.parse_jit (or match_jit) function and a FunctionParameter.check_jit function to do this. Then the jit dispatch would have the full signature - it might also be useful to handle the "exotic" parameters such as device)
My understanding is that that is not the way you want, but what would be the way you would want the jit to work here?

@apaszke

Actually I think it would be even better if we had a different auto-generated JIT pass, that normalizes out all of those cases that are normally handled by the Python arg parser. (...) However that's a slightly bigger change, so I'm ok with merging this to unblock the sum PR, and I'll fix it later myself.

I agree this PR doesn't seem like the nicest possible change. I'd be happy to give a try at a more elaborate one, but I'm afraid wouldn't know where to start with this.

So perhaps we can unblock #6152 , and I'll try to work with @t-vi to come up with a proper solution?

@elanmart can you only please tell me how many lines are there in the generated aten_dispatch.cpp after this patch?

Yeah, so the powerset makes it 2x larger 😕

wc -l torch/csrc/jit/generated/aten_dispatch.cpp 
10897 torch/csrc/jit/generated/aten_dispatch.cpp

Eh, it's not great, but I guess we'll need to stick with it for now.