[llvm-dev] Question about thinLTO

[Christudasan D via llvm-dev]

Hi Tobias,

Unlike a regular processor, calling conventions in our architecture is
quite different. It introduces extra instructions at call-site & callee's
prologue. In an average, a call occupies 7-10 extra instructions in the
code memory (I am not allowed to talk more about it). For that reason,
inlining a function would sometimes bring us better code even for a higher
inline-threshold.

Like you mentioned, cross-module inlining is the main transformation with
thinLTO. Though it increases the code size after inlining, it also opens up
the opportunities to optimize the combined code with regular IR passes
(const and copy propagation, dce, cse, etc..) and there by reducing the
code size further. That was the key motivation for us to think about this
optimization.

We have a simplified LTO (remove dead functions in the linked binary)
implemented in the custom linker now. But that won't be sufficient to
address the linking challenges thinLTO require.

Thanks,
Christu


On Fri, Jul 14, 2017 at 2:04 AM, Tobias Edler von Koch <
tobias at codeaurora.org> wrote:

> Christu,
>
> Just a heads-up: if code size is your main concern, you'll probably see
> better results with Regular LTO (if that's possible in your scenario).
> ThinLTO's main optimization, for now, is cross-module inlining. While this
> is great for performance, it's quite possible that you'll actually see an
> increase in code size.
>
> Tobias
>
>
> On 07/13/2017 11:38 AM, Christudasan D via llvm-dev wrote:
>
>> I understand the potential risk of having thinLTO in our model now. No,
>> we don't support LTO with our custom linker. We are moving to gold soon, it
>> is under progress. I hope this feature can be enabled at that point of time.
>>
>> Thanks,
>> Christu
>>
>
> --
>
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170714/567d756f/attachment.html>