[LLVMdev] Compiler opt is turned off ?

Justin Holewinski justin.holewinski at gmail.com
Sun Jan 6 17:32:57 PST 2013


On Sat, Jan 5, 2013 at 6:17 AM, Somenath Chakraborty <some.chak at gmail.com>wrote:

> I completely agree with you.
>
> The source code I wrote here has the main function and is a complete code.
> That's why I was expecting load/store analysis could have been incorporated
> across the module. Thanks.
>

Clang doesn't know it's a complete program.  You only told it to compile to
IR, so it has no idea what it will link against.  I could write another C
file with "extern int a" and link these two together.

Now if you use static, e.g. "static int a, b, c;", then clang does optimize
them away.


>
> On Fri, Jan 4, 2013 at 10:43 PM, Daniel Berlin <dberlin at dberlin.org>wrote:
>
>> I'm not sure what you mean by "use" check.
>> If you compile this with LTO and multiple modules, and guarantee that
>> you have the main function, yes, you could optimize this.
>> In all other cases, it's not possible to eliminate any of the
>> remaining loads or stores you see, because you have no guarantee about
>> what else could read it.
>>
>> Heck, a conforming implementation of printf could read from any of
>> these globals, so you don't even need other modules.
>>
>>
>>
>>
>>
>> On Fri, Jan 4, 2013 at 11:45 AM, Somenath Chakraborty
>> <some.chak at gmail.com> wrote:
>> > Thanks for your reply. So, we don't do any "use" check (for globals
>> > variables) beyond a module scope. If so, it answers my question.
>> >
>> > On Fri, Jan 4, 2013 at 6:53 PM, Justin Holewinski
>> > <justin.holewinski at gmail.com> wrote:
>> >>
>> >> Since a, b, and c are globals, how does the optimize *know* they are
>> not
>> >> used elsewhere (e.g. another module)?
>> >
>> >
>> >
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> >
>>
>
>


-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130106/fc4a224b/attachment.html>


More information about the llvm-dev mailing list