Chris Lattner <clattner at apple.com> writes:>> How would you prefer this work? Even if the output were controlled by >> NDEBUG, I feel the added pattern comments make the asm file too >> cluttered even for day-to-day compiler developers. This is really a >> feature to debug instruction selection problems. That's why I put it >> under the control of a separate option. > > It's not really clear how this should work. I'm primarily concerned > that it will cause substantiate table/code bloat that doesn't make > sense for a shipping compiler.Ok, in that case I think we'll need a TableGen flag to control whether this information gets generated. A debug build would include it, a release build would not.> I agree that not all compiler hackers will want to see it, I'd > suggest adding a cl::opt that is only even available when built with > assertions on.Assertions or Debug? I would think we'd want it in the latter. -Dave
On Jul 15, 2011, at 1:54 PM, David A. Greene wrote:> Chris Lattner <clattner at apple.com> writes: > >>> How would you prefer this work? Even if the output were controlled by >>> NDEBUG, I feel the added pattern comments make the asm file too >>> cluttered even for day-to-day compiler developers. This is really a >>> feature to debug instruction selection problems. That's why I put it >>> under the control of a separate option. >> >> It's not really clear how this should work. I'm primarily concerned >> that it will cause substantiate table/code bloat that doesn't make >> sense for a shipping compiler. > > Ok, in that case I think we'll need a TableGen flag to control whether > this information gets generated. A debug build would include it, a > release build would not.tblgen could unconditionally generate code that is protected by NDEBUG.>> I agree that not all compiler hackers will want to see it, I'd >> suggest adding a cl::opt that is only even available when built with >> assertions on. > > Assertions or Debug? I would think we'd want it in the latter.Assertions (which are on by default in a debug build) is the knob we have to play with. -Chris
Chris Lattner <clattner at apple.com> writes:>> Ok, in that case I think we'll need a TableGen flag to control whether >> this information gets generated. A debug build would include it, a >> release build would not. > > tblgen could unconditionally generate code that is protected by NDEBUG.All right, that's doable.>>> I agree that not all compiler hackers will want to see it, I'd >>> suggest adding a cl::opt that is only even available when built with >>> assertions on. >> >> Assertions or Debug? I would think we'd want it in the latter. > > Assertions (which are on by default in a debug build) is the knob we > have to play with.Ah, because of NDEBUG. Ok, makes sense. Not much of a loss for Debug-Assertions. I doubt many people debug with it. -Dave