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

Hello,

I upgraded to llvm 2.8 and when I generate *.ll files from C/C++ with
clang -S -emit-llvm I obtain a *.ll file in which instructions and
basicblocks have no names.
I tried as well compiling with the -g option, but no names were given.

In the release notes it is indicated to use "--show-annotations" to print
the number of uses. Is there something similar for assigning names to
values, as in the previous llvm versions?

I prefer the version from llvm 2.7 :
do.cond24: ; preds = %if.end
  %tmp25 = load i32* %i ; <i32> [#uses=1]
  %cmp26 = icmp ult i32 %tmp25, 20 ; <i1> [#uses=1]
  br i1 %cmp26, label %land.lhs.true, label %land.end

than llvm 2.8 :

; <label>:9 ; preds = %56, %0
  %10 = load i32* %k, align 4
  %11 = icmp ult i32 %10, 5
  br i1 %11, label %12, label %57

Thank you,
Alexandra

Hello,

I upgraded to llvm 2.8 and when I generate *.ll files from C/C++ with
clang -S -emit-llvm I obtain a *.ll file in which instructions and
basicblocks have no names.
I tried as well compiling with the -g option, but no names were given.

In the release notes it is indicated to use "--show-annotations" to print
the number of uses. Is there something similar for assigning names to
values, as in the previous llvm versions?

Yep, run the .ll file through the "opt -instnamer" pass.

-Chris

opt -instnamer will assign names to a given LLVM assembly file.

-Eli

Hi Alexandra,

I upgraded to llvm 2.8 and when I generate *.ll files from C/C++ with
clang -S -emit-llvm I obtain a *.ll file in which instructions and
basicblocks have no names.
I tried as well compiling with the -g option, but no names were given.

with dragonegg using -fverbose-asm causes names to be generated in the IR.
Maybe clang could do this to?

Ciao,

Duncan.

This isn't a 2.8 change, the issue is that release-without-asserts builds don't add names on instructions (because IRBuilder gets a different argument).

-Chris

Hi Chris,

This isn't a 2.8 change, the issue is that release-without-asserts builds don't add names on instructions (because IRBuilder gets a different argument).

having the output of clang depend on whether clang was built with assertions
on or not sounds like a bad idea to me.

Ciao,

Duncan.

While I agree in the abstract that this is an independent choice from
assertions and optimization, I'm not convinced that it's an important
enough feature to seriously complicate our configuration over.
Nobody really wants names unless they're debugging a compiler,
and even then they're not crucial. They should be on by default as
long as Debug builds are the default, but we don't want people to
unintentionally make production compilers with names enabled.

I think there's a case to be made that we should kill names based on
--enable-optimized instead of --disable-assertions. The only problem
is that --enable-optimized doesn't actually turn into a -D right now.

John.

Hi John,

This isn't a 2.8 change, the issue is that release-without-asserts builds don't add names on instructions (because IRBuilder gets a different argument).

having the output of clang depend on whether clang was built with assertions
on or not sounds like a bad idea to me.

While I agree in the abstract that this is an independent choice from
assertions and optimization, I'm not convinced that it's an important
enough feature to seriously complicate our configuration over.

is adding a debug flag to turn on name generation really a serious complication?

Nobody really wants names unless they're debugging a compiler,
and even then they're not crucial.

how about always having name generation be turned off, whatever mode the
compiler is built in? People debugging the compiler can reasonably (IMO)
be required to pass a debug flag to clang to turn on name generation, or
if you don't want a debug flag they can always use opt -instnamer. That
said, I agree that it's not a big deal, just likely to cause confusion
when people see that they are getting different output from two copies of
the same compiler (as happened to me yesterday when I saw that my version
of clang-2.8 was giving everything names).

   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 [*]

Ciao,

Duncan.

[*] In which case you could argue that you should be debugging the situation.

but we don't want people to

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.