Does this implementation defined behavior mean that the size(int) is platform dependent or defined by compiler vendor or both?
In principle the compiler vendor can make that decision. In practice, if the compiler wants to emit code that calls directly to system libraries, then it has to follow the same "ABI" (Application Binary Interface) as the system, and among other things the ABI will specify the size of int. So the compiler vendor will "decide" to make it the size the ABI says.
Compilers that target multiple platforms and architectures will make the decision separately as part of the configuration of each platform. Each target then represents a different C implementation, even though you think of it as "the same compiler".
You could write a conforming C implementation in which int is a different size from what it is on the OS that runs the program. People rarely do, and the standard libraries would have to jump through extra hoops when they make system calls. It could be useful as part of an emulator, but then you might reasonably argue that the "platform" is the emulated platform, not the host platform with its different-sized int.
Once I compile my code, does implementation dependencies would still apply when I run it on different versions of platforms?
sizeof(int) is a compile-time constant, which means that the code emitted by your compiler might assume a certain value. That binary code cannot then run correctly on a different version of the platform with a different sized int.
Would I get performance loss for compiling implementation defined code on one platform and running it on other?
If it works at all, then there's no particular reason to assume there will be a performance loss. It generally won't work at all (see above), because binary code intended for one platform in general doesn't work on another platform. If the platforms are similar enough that it does work, it's possible that optimizations that the compiler made intended for one, are not such good optimizations on another. In that case there would be a performance loss, and the fix would be to re-compile the code targeting the correct (version of the) platform.
This does happen with ARM, and to a lesser extent with x86. Different chips in the past have offered essentially the same instruction set, but with some instructions on some chips having significantly different cost relative to other instructions. An optimization that assumes instruction X is fast would likely be a bad optimization on a different chip where instruction X is slow. As you can imagine, this kind of difference doesn't make the chip manufacturer hugely popular with compiler vendors, and even less so with assembly programmers.
