This is an archive of the discontinued LLVM Phabricator instance.

ThinLTOBitcodeWriter: Strip debug info from merged module.
ClosedPublic

Authored by pcc on Jan 19 2017, 12:41 PM.

Details

Summary

This module will contain nothing but vtable definitions and (soon)
available_externally function definitions, so there is no point in keeping
debug info in the module.

Diff Detail

Repository
rL LLVM

Event Timeline

pcc created this revision.Jan 19 2017, 12:41 PM
mehdi_amini edited edge metadata.Jan 27 2017, 1:41 PM

(Sorry didn't hit send last week)

llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
265 ↗(On Diff #85015)

Debug info is costly to manipulate, can't we have a flag on CloneModule that just ignores them in the first place?

pcc added inline comments.Jan 27 2017, 1:48 PM
llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
265 ↗(On Diff #85015)

Maybe we can do that in a follow up change. For the moment it seems simplest to strip after cloning.

krasin added a subscriber: krasin.Jan 27 2017, 1:53 PM

I have just confirmed that this CL fixes the issue with Chromium + ThinLTO + debug info described here: https://crbug.com/682773#c9

I have just confirmed that this CL fixes the issue with Chromium + ThinLTO + debug info described here: https://crbug.com/682773#c9

This should only be a compile-time optimization for CFI. So this is another issue that should be address separately, and likely first.

mehdi_amini added inline comments.Jan 27 2017, 2:17 PM
llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
265 ↗(On Diff #85015)

Are you expecting this to be involved?

pcc added inline comments.Jan 27 2017, 2:26 PM
llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
265 ↗(On Diff #85015)

We would need to thread the flag through to practically everywhere we create IR when cloning a module. Not that involved but certainly more than a one liner. (And the perf improvement associated with adding the flag hasn't been measured.)

I've started looking at the bug Ivan found. In the meantime, it would be nice if we could land this change to unbreak our bot.

mehdi_amini added inline comments.Jan 27 2017, 2:45 PM
llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
265 ↗(On Diff #85015)

Which bot? Chromium bot? Why don't you patch this internally?

pcc added inline comments.Jan 27 2017, 2:48 PM
llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
265 ↗(On Diff #85015)

Which bot? Chromium bot?

Yes.

Why don't you patch this internally?

We don't normally do that.

krasin added inline comments.Jan 27 2017, 2:50 PM
llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
265 ↗(On Diff #85015)

This is a Clang ToT bot that is aimed to track the pristine LLVM tree. So, it is more like a bot on labs.llvm.org than other Chromium bots.

One reason to unbreak the bot even if it's a workaround for now would be to make sure we don't get unrelated regressions related to ThinLTO / LLD / Debug info on the LLVM side.

pcc added a comment.Feb 7 2017, 4:37 PM

Ping, D29240 has landed now.

tejohnson accepted this revision.Feb 7 2017, 4:52 PM

This LGTM as a temporary approach - but please wait for Mehdi. Was D29240 the fix of the root cause of the bot failure? Is this fix required to work around a breakage now, or just an optimization to remove unnecessary debug info?

llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
265 ↗(On Diff #85015)

Suggest adding a comment about why this is safe, and a FIXME to have CloneModule optionally ignore the debug info.

This revision is now accepted and ready to land.Feb 7 2017, 4:52 PM
pcc added a comment.Feb 7 2017, 4:57 PM

This LGTM as a temporary approach - but please wait for Mehdi. Was D29240 the fix of the root cause of the bot failure?

Yes.

Is this fix required to work around a breakage now, or just an optimization to remove unnecessary debug info?

The latter.

(FWIW, I wouldn't necessarily call this a "temporary" approach. I'd say that the benefit of adding the flag to CloneModule should first be proven through benchmarking.)

mehdi_amini accepted this revision.Feb 8 2017, 12:48 AM

I thought after discussing this on IRC this had landed two weeks ago! Apparently I didn't click approve here...

In D28913#670212, @pcc wrote:

(FWIW, I wouldn't necessarily call this a "temporary" approach. I'd say that the benefit of adding the flag to CloneModule should first be proven through benchmarking.)

One could argue on the opposite. Before you prove that it does not matter, this can't be called anything else than temporary.
Making the software 1% slower here, and here, and here, and here, leads to a bloated project. If we have code reviews it is also to catch what we *know* immediately isn't "right" and not build technical debt.

This revision was automatically updated to reflect the committed changes.