| HN Mirror

You'd have to see if all compilers support it, but LLVM has a "remarks" system, which should provide similar information (though likely a lot more of it) for optimization passes which are traced: https://llvm.org/docs/Remarks.html#introduction-to-the-llvm-...

The frontend may or may not have its own optimizations and logs tho e.g. rustc now has MIR optimizations (https://rustc-dev-guide.rust-lang.org/mir/optimizations.html) but while you can dump MIR data (https://rustc-dev-guide.rust-lang.org/mir/debugging.html) I don't remember seeing an optimisation log.

At the end of the day, I think it's more likely that you take a look at the assembly and infer problems from there if the profiler doesn't tell you straight. An other difference is the kind of decisions the compiler makes e.g. while a compiler can optimize away allocations in "manual allocation" languages (https://godbolt.org/z/5nEo7xjEr) the allocations are plainly visible, so if they're trivially avoidable... you'll just avoid them.

Using Rust as an example, you'd have something like this:

    pub fn match_(&self, path: &str) -> Result<&Rule, Error> {
        for rule in self.0.iter() {
            if rule.match_(path)? {
                return Ok(rule);
            }
        }
        Err(Error)
    }

You couldn't miss an allocation, because the return type would have to change, and you'd need to perform the copy out:

    pub fn match_(&self, path: &str) -> Result<Box<Rule>, Error> {
        for rule in self.0.iter() {
            if rule.match_(path)? {
                return Ok(Box::new(rule.clone()));
            }
        }
        Err(Error)
    }