[LLVMdev] Values have no names when generating *.ll files in clang and llvm 2.8 ?

John McCall rjmccall at apple.com
Thu Oct 14 16:16:16 PDT 2010


On Oct 14, 2010, at 1:48 AM, Duncan Sands wrote:
>> They should be on by default as long as Debug builds are the default,
> 
> I guess this is the bit I don't really get.  Why should it be on by default in
> debug builds?  I guess your point of view is that "Debug build" means that
> you are interested in debugging the compiler, while in fact it just means
> that the compiler was built without optimization which is not quite the same
> thing (in spite of the name).  For example because otherwise your system
> compiler miscompiles LLVM/clang [*]

Implementation is not design.  Of course Debug builds correspond to a
particular set of configuration settings, but those settings aren't given to
us by the gods, they're chosen for a purpose.  Put another way, the point is
not that a Debug build inherently means anything, it's that *people who
want Debug builds* are obviously interested mostly in debugging the
compiler.

As I see it, users of the build system care about exactly three configurations:
  - a build designed for basic development, providing the best affordances
    for debugging at substantial performance cost;
  - a build designed for end users, providing optimal performance and only
    as much debugging information as can be achieved without significant cost;
  - a build designed for general testing, providing the best performance
    possible while keeping assertions on to catch consistency problems which
    might otherwise fly under the radar.
Currently, these are called "Debug+Asserts", "Release", and "Release+Asserts"
respectively.  Of course you can request a "Debug" (without asserts) build, but
it's hard to imagine why anyone would want to.
 
Names should be on for the first and off for the others.  The fact
that we *could* make them an orthogonal variable which people would have
to know to enable or disable to get what they want doesn't mean that it's a
good idea.

John.



More information about the llvm-dev mailing list