On Jan 15, 2014, at 12:21 AM, Justin Bogner <[email protected]> wrote: >> Hold on, I don't think that's the right way to interpret this. >> >> Allocating, wiring up, optimizing and deleting the block all have very >> non-trivial compile-time cost. They introduce guaranteed malloc traffic. >> Worse, linear amounts of malloc traffic.
Yes, what Chandler said. My understanding is that you were going to change it to emit the “dead” blocks for the specific purpose of putting a counter in them (which is how it already was). > I hadn't thought about this point, but as far as "how this came to be" I > don't think that there's any other way to interpret it. r129652 > specifically calls this "a -O0 code quality issue" in its commit > message. > > From a programmer's perspective, letting the backend clean up these > blocks means less duplicated logic, and in my experience that means > fewer bugs. That said, I don't have a deep understanding of the cost for > the backend to remove empty blocks. You’re optimizing for the wrong thing. Yes, it is good to avoid duplicated code in the compiler when all things are equal, but here all things are not equal: you’re making the compiler slower for *users* of the compiler. -Chris _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
