This is an archive of the discontinued LLVM Phabricator instance.

[SplitModule] Do not copy stale debug info during module splitting.
Needs ReviewPublic

Authored by slarin on Feb 17 2016, 9:27 AM.

Details

Summary

Currently CloneModule always copy debug related metadata even if debugging subject was not cloned
in the target module. This is not only suboptimal in size and time, but can potentially create
issues when metadata retains references to objects that were not cloned in the target module.

This patch attempts bluntly address the effect without fixing the cause.

Diff Detail

Event Timeline

slarin updated this revision to Diff 48202.Feb 17 2016, 9:27 AM
slarin retitled this revision from to [SplitModule] Do not copy stale debug info during module splitting..
slarin updated this object.
slarin added a subscriber: llvm-commits.

Guys, can you please take a quick look...?

Thanks...

Sergei

mehdi_amini added a subscriber: tejohnson.
mehdi_amini added a subscriber: mehdi_amini.

Sorry for the delay, I'm not a debug info expert, so I won't be able to catch all corner cases, maybe D.Blakie or A.Prantl can help?
On the approach itself, it seems like a band-aid compared to filtering out what should be imported in the first place. Maybe Teresa who worked on the filtering has some input (or better: some refactored code to share?).

lib/Transforms/Utils/SplitModule.cpp
223

Nit: F is used elsewhere for Function, rename?

258

Not sure if it is the right thing to do, but I'm gonna leave this to people more aware of debug info than I am.

In D17338#365399, @joker.eph wrote:

Sorry for the delay, I'm not a debug info expert, so I won't be able to catch all corner cases, maybe D.Blakie or A.Prantl can help?
On the approach itself, it seems like a band-aid compared to filtering out what should be imported in the first place. Maybe Teresa who worked on the filtering has some input (or better: some refactored code to share?).

I agree with Mehdi that it would be ideal to fix this in CloneModule itself. And perhaps it can leverage the changes I have in D16440 which additionally avoids bringing in unnecessary composite types. Looks like it would be fairly natural as they both use a ValueMap and so the identification of what is needed by the mapped in functions should be the same. The support in my patch would need to be moved out to a common place though.

To get CloneModule to do the right thing with regards to subprogram metadata like you are doing here, AFAICT it will need to fix the way it is currently mapping subprograms (see the comment I just left on D17165).