On Nov 21, 2009, at 1:00 PM, Arnt Gulbrandsen wrote:> Chris Lattner writes: >> I'm still really interested in making Clang (and thus LLVM) faster at -O0 (while still preserving debuggability of course). > > Why?I want the compiler to build things quickly in all modes, but -O0 in particular is important for a fast compile/debug/edit cycle. Are you asking why fast compilers are good? -Chris
Chris Lattner writes:> On Nov 21, 2009, at 1:00 PM, Arnt Gulbrandsen wrote: > >> Chris Lattner writes: >>> I'm still really interested in making Clang (and thus LLVM) faster >>> at -O0 (while still preserving debuggability of course). >> >> Why? > > I want the compiler to build things quickly in all modes, but -O0 in > particular is important for a fast compile/debug/edit cycle. Are you > asking why fast compilers are good?Sort of. Why you think more speed than LLVM currently provides is a significant benefit. Here's a suggestion, anyway. Teach LLVM to store an optional input-related opaque byte array for each symbol. Define it only as something of arbitrary size that must change if it exists and the source changes. In clang, use that to store the preprocessed source for each function, and if clang sees that the byte array in the output file is the same as its preprocessed source, it can leave the output and skip compiling that function. Then think hard about how this can be extended to skip some optimisation passes too. Someone else said that nothing beats a splat compiler except another splat compiler. I think a compiler that mostly avoids compiling may have a fair chance. Arnt
Arnt Gulbrandsen <arnt at gulbrandsen.priv.no> writes:>>>> I'm still really interested in making Clang (and thus LLVM) faster >>>> at -O0 (while still preserving debuggability of course). >>> >>> Why? >> >> I want the compiler to build things quickly in all modes, but -O0 in >> particular is important for a fast compile/debug/edit cycle. Are you >> asking why fast compilers are good? > > Sort of. Why you think more speed than LLVM currently provides is a > significant benefit.My compiler supports LLVM as a backend. The language heavily relies on compile-time environment-dependent code generation, so it needs the JIT. One of the things that is holding back LLVM on production systems is that it needs minutes to JIT a medium-sized application. That's barely tolerable for long-running server applications, and a big no-no for client apps.> Here's a suggestion, anyway.[snip] I'm afraid that you are not being too original with that suggestion :-) -- Óscar
2009/11/22 Arnt Gulbrandsen <arnt at gulbrandsen.priv.no>:> Sort of. Why you think more speed than LLVM currently provides is a > significant benefit.Faster is always better, and I see why increasing it on all optimization levels is paramount to any compiler. I just fail to see why should we hack the O0 to make it faster. Whenever you increase the speed of O0, you're obviously increasing for all levels, but hacking your way through just to compete with Go (or any other) won't provide the same benefit. Besides, every program has to make compromises between generality and speed. As LLVM is a compilation infrastructure, I fail to see the point of domain-specific changes to its internals. Why is O0 any good for general purposes, besides debugging? On the other hand, creating a clang-o0 with the changes and keep it outside of the core libraries would achieve the same results without compromising generality... cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm