[LLVMdev] -Os

[Jim Grosbach]

On Jul 26, 2013, at 6:01 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote:

> On 7/23/2013 1:36 PM, Jim Grosbach wrote:
>> 
>> This isn’t just a nitpick. This is exactly why you’re seeing
>> differences. The pass managers aren’t always set up the same, for example.
>> 
>> FWIW, I feel your pain. This is a long-standing weakness of our
>> infrastructure.
> 
> What was the motivation for this design?  Was it to save time by not creating another process, or were there other factors?

 For having clang be one big executable rather than multiple? Yes, compile time was a very big motivator. Serializing and deserializing the intermediate state, etc, is not lightweight enough.

> 
> The IBM compiler for example, has all of its components in different executables.  It makes debugging a lot more convenient (especially when working with large applications built with IPA).
> 

Definitely. That’s why we have the separate components as well that theoretically allow us to do that sort of compartmentalized debugging.

Things get complicated in the cases where there are behavioral differences between running things all the way through in clang vs. using the piece-by-piece tools on the IR (clang -emit-llmv —> opt —> llc —> as). Thankfully, that’s not too common. It’s typically sufficient to specify the right triple and maybe one or two options for setting the cpu or something like that to reproduce an issue. When it is a problem, though, it’s a really unpleasant one. It’s also very related to the sorts of information needed to be passed along for proper LTO, so Bill’s work there will enable us to fix this problem, too.

-Jim

> -K
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130726/5f223fcb/attachment.html>