There's %IsLiftoffFunction (which naturally only works for functions visible to JS, i.e. exported functions), and there's --trace-wasm-compilation-times.

Generally, tracing functionality gets built when a developer (1) has a need for it, and (2) assumes that it'll be sufficiently useful in the future to actually land the code, as opposed to just hacking in a few printfs locally and then discarding them when the issue at hand has been solved. The Wasm execution model is so simple (for now) that there hasn't been much need to build tracing for it. (And it used to be even simpler, until we turned on dynamic tiering a few months ago.)

As of today (2022-05-29, this part probably won't age very well), in the default configuration:

• All functions are compiled with Liftoff (the Wasm baseline compiler) before execution of the first function starts. (The only exception to this are hopefully-rare cases of missing hardware support, such as functions using SIMD instructions on non-SSE4.1 x86 hardware: they get compiled with Turbofan right away. I'd like to see that fixed, but it's a lot of work and not urgent.)
• When a function runs long enough, it's optimized with Turbofan, and the optimized code is used the next time it's called.
• There is no OSR, no deopts, no going back to unoptimized code (unless you start debugging with DevTools).