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

[Dennis Luehring]

hi llvmdev list

im currently investigating a missing optimizer feature in VS2010 - and
comparing the VS2010 results with the result of clang 3.1

i've downloaded clang from http://llvm.org/releases/download.html ->
Experimental Clang Binaries for Mingw32/x86

clang --version
clang version 3.1 (branches/release_31)
Target: i686-pc-mingw32
Thread model: posix

----- test.c

typedef unsigned char byte_t;
typedef unsigned int dword_t;

byte_t byte;
dword_t dword;

int main(int argc, char** argv)
{
dword_t random = (dword_t)argv;

byte = (byte_t)random;
dword = (dword_t)random;

dword_t result = 3*(byte+dword);

return result;
}

-------

compiled with "clang -O3 test.c"

produces this code for the main

.text:004012E0 sub_4012E0 proc near ; CODE XREF:
sub_401020+91
.text:004012E0
.text:004012E0 arg_4 = dword ptr 0Ch
.text:004012E0
.text:004012E0 push ebp
.text:004012E1 mov ebp, esp
.text:004012E3 call sub_4014C0
.text:004012E8 mov eax, [ebp+arg_4] ; dword_t random
= (dword_t)argv;
.text:004012EB mov byte_402000, al
.text:004012F0 mov dword_402004, eax
.text:004012F5 movzx ecx, al
.text:004012F8 add ecx, eax
.text:004012FA lea eax, [ecx+ecx*2]
.text:004012FD pop ebp
.text:004012FE retn
.text:004012FE sub_4012E0 endp

but why are these two lines not removed by the optimizer?

.text:004012EB mov byte_402000, al
.text:004012F0 mov dword_402004, eax

no access before, no access after - even the main-code itself isn't
using the variables for reading

VS2010 behaves the same - but clang is still much better in other cases :)


_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Dennis Luehring]

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 :)

[Dimitry Andric]

On 2012-07-05 12:53, Dennis Luehring 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?

[Duncan Sands]

Hi Dimitry,

On 05/07/12 13:30, Dimitry Andric wrote:
> On 2012-07-05 12:53, Dennis Luehring 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.

Ciao, Duncan.

[Robinson, Paul]

Duncan Sands wrote:
>On 05/07/12 13:30, Dimitry Andric wrote:
>> On 2012-07-05 12:53, Dennis Luehring 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