4 ms·
We must be using different compilers then. Last time I checked there are some heuristics about what gets inlined and when exactly those heuristics are triggered
by dkarapetyan 10y ago
We must be using different compilers then. Last time I checked there are some heuristics about what gets inlined and when exactly those heuristics are triggered. Something about compilers being terminating programs and stack depth not being an unbounded resource. I don't know though. Maybe I was reading the wrong literature. What are your sources?
- DannyBee 10y agoNow you are changing arguments. You said: "There is nothing more you can do with x -> 2 + x other than compile it as is." That is factually false. People called you on it. Rather than say "yeah, i was wrong, but i meant that in general, one doesn't get a guarantee that it will always turn out fast" or something, you seem to be just dodging it. So please, can you start with exactly what you would like to talk about? If it's about inlining, yes, those are heuristics in a lot of compilers, but they also do make guarantees a lot of the time (particularly around tail calling), and in fact, provide the ability to guarantee inlining happens to users. Fact: If always_inline doesn't always inline, the linux kernel fails to compile and link. So people rely on it in real software.
- dkarapetyan 10y agoOh, `always_inline` looks like a programmer annotation to me? Am I correct? I don't know. You're the compiler writer who knows about these "sufficiently smart" compilers that should have filled all of that in for me.