The problem is immature tooling. There is no feedback loop from the compiler's generated assembly back to the IDE. We finally have libclang which sorta does some stuff (I'm not entirely sure how far it can go) - but I'm honestly not seeing any work being done in this direction on the IDE level. After all these years of C++ development, why doesn't the IDE do something as simple as tell me if a function is being inline or not is beyond me (that's the tip of the iceberg in terms of what I want to know).
When I asked people at CppCon about it I just got some shrugs and was told "just go look at the assembly".
Another solution is profiling - but that's got a slow turn around, and it can be hard to narrow down problem areas.
For Lisp, SBCL is known for giving optimizations notes:
; note: forced to do GENERIC-+ (cost 10)
; unable to do inline fixnum arithmetic (cost 2) because:
; The first argument is a NUMBER, not a FIXNUM.
; The second argument is a (INTEGER -19807040623954398379958599680
; 19807040623954398375663632385), not a FIXNUM.
; The result is a (VALUES NUMBER &OPTIONAL), not a (VALUES FIXNUM &REST T).
; unable to do inline (signed-byte 64) arithmetic (cost 5) because:
; The first argument is a NUMBER, not a (SIGNED-BYTE 64).
; The second argument is a (INTEGER -19807040623954398379958599680
; 19807040623954398375663632385), not a (SIGNED-BYTE
; 64).
; The result is a (VALUES NUMBER &OPTIONAL), not a (VALUES (SIGNED-BYTE 64)
; &REST T).
; etc.
Note also that the approach is different there: integers are not modular, but you can still perform modular arithmetics if the range of values is adequate (http://www.sbcl.org/manual/#Modular-arithmetic).
When I asked people at CppCon about it I just got some shrugs and was told "just go look at the assembly".
Another solution is profiling - but that's got a slow turn around, and it can be hard to narrow down problem areas.