AMD talked about this years ago.
It makes limited sense, a CPU has a bunch of execution units available to it and can send a few instructions out per clock. If one CPU could get access to the execution units of another CPU, then it might be able to issue more work in a clock cycle.
Thing is, you get conditional jump instructions about every 6 instructions on average which limits how many instructions you can usefully issue per clock. Then the extra wiring needed to do this would drop the clock speed you could get to as everything has a cost.
They might have been able to share SSE units though, and there are potentially quite big gains to be made there given SSE was always intended to crunch big data sets with less looping.
But then Windows would get in your way. One of your cores grabs extra SSE resources to run your game dead fast, then Windows for reasons unfathomable decides to switch that thread to another CPU and chooses one that currently has its SSE unit in use elsewhere, so the CPUs have to reconfigure themselves.
So, the CPU has to be able to reconfigure itself on the fly, per clock cycle. Shared resources across 2 CPUs with wider than normal issue to make it worthwhile. I think if you take that to its logical conclusion, you end up designing the Core I7 Hyperthreading model
AMD should just adopt multi-threading. IBM seem to do a cracking job with their Power architecture, hitting 5GHz with two threads per CPU, and the Intel effort is pretty effective too. Sun process massive thread pools on their slightly loopy Niagra CPU, so I don't know why AMD think they are special and can ignore the whole technology.