Create a Call instruction directly when building a thunk call.

[zygoloid]

Don't go through the PerformCall machinery a second recursive time -- this is redundant, creates additional unnecessary temporaries, and is in theory wrong because PerformCall takes a syntactic argument list (one argument per callee parameter pattern), but we have a call argument list (one argument per callee parameter).

[dwblaikie]

is in theory wrong because PerformCall takes a syntactic argument list (one argument per callee parameter pattern), but we have a call argument list (one argument per callee parameter).

Any chance we can have some code coverage for this ^ or do we not have any instances where these diverge at the moment? (do we not decompose pass-by-value into separate register arguments yet?)

[zygoloid]

is in theory wrong because PerformCall takes a syntactic argument list (one argument per callee parameter pattern), but we have a call argument list (one argument per callee parameter).

Any chance we can have some code coverage for this ^ or do we not have any instances where these diverge at the moment? (do we not decompose pass-by-value into separate register arguments yet?)

We don't have any instances where these diverge at the moment. #6268 adds the first one: there, we map a T& parameter on the C++ callee into a T& parameter on the thunk on the C++ side, and both of those convert to an addr _: T* parameter on the Carbon side. Then, when we perform a thunk call, if we PerformCall, we end up applying both addr patterns and try to take the address of a parameter that's already an address.

#6268 adds tests covering that situation.