[llvm-dev] ThinLTO Problem

chenmindong via llvm-dev llvm-dev at lists.llvm.org
Wed Nov 27 19:29:17 PST 2019

Hi David,

`-ffunction-sections -fdata-sections -Wl,-gc-sections ` is actually our first choice but because `-ffunction-sections` puts each function into its own section and section alignment cost is not negligible for our target, the gain is unpredictable and we deprecated the plan.


From: David Blaikie [mailto:dblaikie at gmail.com]
Sent: Wednesday, November 27, 2019 11:36 PM
To: chenmindong <chenmindong1 at huawei.com>
Cc: llvm-dev at lists.llvm.org; Yuchao (Michael) <michael.yuchao at huawei.com>
Subject: Re: [llvm-dev] ThinLTO Problem

On Wed, Nov 27, 2019 at 6:29 AM chenmindong via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

I'm working on enabling thinLTO for our custom backend on LLVM-8 with lld to get code size benefits from dead symbol elimination.

If you only want this - is -ffunction-sections -fdata-sections -Wl,-gc-sections sufficient?

The code in LTO::run() of LTO.cpp confuses me that, even though thinLTO is specified, runRegularLTO() will be run first and its return value determines whether runThinLTO() will be executed.

My question is if it's clearly known that thinLTO is used, is it still necessary to execute runRegularLTO()?If it is, what's the reason behind? For now our custom backend, where distributed thinLTO is adopted, it works fine as I removed the line executing runRegularLTO(). But if I preserve it, the code fails the `if (Conf.PostInternalizeModuleHook &&!Conf.PostInternalizeModuleHook(0, *RegularLTO.CombinedModule))`, which I also don't understand, and fall through to backend() and abort there. I believe something is missed during adding the target support but cannot figure it out. Could anyone help?

Mindong Chen
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191128/ce0a4a89/attachment.html>

More information about the llvm-dev mailing list