[cfe-commits] r59094 - in /cfe/trunk/lib/CodeGen: CGBuilder.hCodeGenFunction.h

[Nuno Lopes]

Yes, I agree.
I think having the instruction names there help when you need to debug 
something. At least I've found them useful so far.

Nuno

P.S.: BTW thank you Daniel for adding this.

----- Original Message -----
> In my opinion this really isn't a major issue. If we want to fix it, I
> would advocate changing the IRBuilder to allow run time configuration
> of that option (which I would like, but isn't a high priority).
>
> In the end, it sometimes makes sense to have some static compilation
> time choice between easier debugging/development and performance.
> NDEBUG seems a reasonable choice for that option. Note that we use
> this in other places in LLVM to not compile in debugging specific
> code.
>
> On Tue, Nov 11, 2008 at 8:50 PM, Chris Lattner <clattner at apple.com> wrote:
>>
>> On Nov 11, 2008, at 6:30 PM, Eli Friedman wrote:
>>
>>> On Tue, Nov 11, 2008 at 4:01 PM, Daniel Dunbar <daniel at zuster.org> 
>>> wrote:
>>>>
>>>> Author: ddunbar
>>>> Date: Tue Nov 11 18:01:12 2008
>>>> New Revision: 59094
>>>>
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=59094&view=rev
>>>> Log:
>>>> Disable generation of basic block names in NDEBUG mode.
>>>>
>>>> Revert to enabling generation of instruction names when not in NDEBUG
>>>> mode.
>>>
>>> Is this really a good idea?  Normally NDEBUG doesn't change the
>>> visible behavior of the program.
>>
>> This also breaks abi compatibility between .o files produced in debug and
>> release builds.  I don't know how much that matters in practice.
>>
>> What case are instruction names useful for?
>
> The code is more readable with names, in my opinion, esp. when wanting
> to relate the output code with the part of IRGen that emitted it.
> It is also substantially more editable.
>
> I think the burden of proof goes the other direction, in what cases
> are names not useful? :)
>
> The only real answer is performance, but this doesn't motivate
> ditching them altogether in my opinion.
>
> - Daniel