[llvm-dev] RFC [ThinLTO]: Promoting more aggressively in order to reduce incremental link time and allow sharing between linkage units

[Peter Collingbourne via llvm-dev]

On Thu, Apr 7, 2016 at 10:52 AM, Xinliang David Li <davidxl at google.com>
wrote:

>
>
> On Wed, Apr 6, 2016 at 4:41 PM, Peter Collingbourne <peter at pcc.me.uk>
> wrote:
>
>> Hi all,
>>
>> I'd like to propose changes to how we do promotion of global values in
>> ThinLTO. The goal here is to make it possible to pre-compile parts of the
>> translation unit to native code at compile time. For example, if we know
>> that:
>>
>> 1) A function is a leaf function, so it will never import any other
>> functions, and
>> 2) The function's instruction count falls above a threshold specified at
>> compile time, so it will never be imported.
>> or
>> 3) The compile-time threshold is zero, so there is no possibility of
>> functions being imported (What's the utility of this? Consider a program
>> transformation that requires whole-program information, such as CFI. During
>> development, the import threshold may be set to zero in order to minimize
>> the incremental link time while still providing the same CFI enforcement
>> that would be used in production builds of the application.)
>>
>
>> then the function's body will not be affected by link-time decisions, and
>> we might as well produce its object code at compile time. This will also
>> allow the object code to be shared between linkage units (this should
>> hopefully help solve a major scalability problem for Chromium, as that
>> project contains a large number of test binaries based on common libraries).
>>
>
>
> 3) sounds like a good use case (though very unique to CFI. Generally, a
> function body will be affected by link time decisions including whole
> program analyses).  In this mode, do we really need to emit the bit code
> section at all? There does not any need for static promotions if we assume
> no cross module transformations will happen in this mode.
>

We still need some way to generate the correct code for the CFI intrinsics,
which rely on cross module information. That information would come
directly from the combined summary, rather than being imported from other
modules.

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160407/10e8e24f/attachment.html>