Chris Lattner <[email protected]> writes: > 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.
Sorry, I guess I misunderstood. I've reverted this change in r199700. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
