clang optimizer does not remove unused/uneeded variables(and accesses) from global scope

addition to my last post: http://groups.google.com/group/llvm-dev/browse_thread/thread/afd85c3f303ec2a9

i know that using static on my globals will remove them - no other compilation unit can then extern the vars

but my question is - in this closed szenario clang is "directly" producing the exe - isn't clang aware of that the vars are not in use?

btw: the microsoft compiler still keeps them - even if static, but without demangled names :slight_smile:

It can't know that, unless you use link-time optimization. Which
optimization level did you use?

Hi Dimitry,

addition to my last post:
http://groups.google.com/group/llvm-dev/browse_thread/thread/afd85c3f303ec2a9

i know that using static on my globals will remove them - no other
compilation unit can then extern the vars

but my question is - in this closed szenario clang is "directly"
producing the exe - isn't clang aware of that the vars are not in use?

It can't know that, unless you use link-time optimization. Which
optimization level did you use?

it can know: if you looked at his command line you can see that it is producing
a final executable from the file, not just compiling it to object code. As far
as I know clang relies on an LLVM aware linker to do the link-time optimization,
though I'm not sure why: in this kind of case it could just do it itself. On
linux you can use the gold linker with the LLVM gold plugin, maybe that can be
used on windows too, I wouldn't know.

Ciao, Duncan.

Duncan Sands wrote:

addition to my last post:
http://groups.google.com/group/llvm-dev/browse_thread/thread/afd85c3f303ec2a9

i know that using static on my globals will remove them - no other
compilation unit can then extern the vars

but my question is - in this closed szenario clang is "directly"
producing the exe - isn't clang aware of that the vars are not in use?

It can't know that, unless you use link-time optimization. Which
optimization level did you use?

it can know: if you looked at his command line you can see that it is producing
a final executable from the file, not just compiling it to object code. As far
as I know clang relies on an LLVM aware linker to do the link-time optimization,
though I'm not sure why: in this kind of case it could just do it itself. On
linux you can use the gold linker with the LLVM gold plugin, maybe that can be
used on windows too, I wouldn't know.

It can't know. It can make the assumption that all possible runtime
environments would be unaffected by this externally-available definition,
but it's an assumption not a known fact, even if you see that a single
translation unit is producing an executable image.

Just to postulate an example, suppose I have a runtime environment that
makes a weak reference to some symbol. If the program defines that symbol,
then the behavior of my runtime is affected. If clang/LLVM arrogantly assumes
that can't possibly happen, then the behavior of my program is affected
when it should not be.

Link-time optimization can figure this out, but the compiler by itself
cannot and must not.
--paulr