You can then emit an object file containing the functions you're interested in and link it to the rest of your non-constant-time program.
You can then emit an object file containing the functions you're interested in and link it to the rest of your non-constant-time program.
This has more potential just because it could be licensed in embedded sector to reduce work on things such as WCET analysis for hard-real-time. That money and uptake can feed back into the compiler's development for things such as constant-time-preserving optimizations. I haven't seen one of these, though. They typically do timing analysis manually (i.e. specific tool) since they have to assess the algorithms themselves, interactions with other components, and so on. Neatest thing I found looking into that was a formally-verified WCET analyses that was built on top of CompCert compiler.
Oh wait, just found something:
How would the compiler knows if the code it's given is constant-time ? It's actually a property quite hard to verify due to pointer aliasing or whatnot.
Another angle is to have a compiler that always outputs constant-time code. It's always possible, at least for crypto code according to Peter Schwabe, just that it's probably not going to be very fast code...