This is an archive of the discontinued LLVM Phabricator instance.

[XRay] Reduce synthetic references emitted by XRay
ClosedPublic

Authored by dberris on Jun 19 2017, 12:06 AM.

Details

Summary

When we're building with XRay instrumentation, we use a trick that
preserves references from the function to a function sled index. This
index table lives in a separate section, and without this trick the
linker is free to garbage-collect this section and all the segments it
refers to. Until we're able to tell the linkers to preserve these
sections, we use this reference trick to keep around both the index and
the entries in the instrumentation map.

Before this change we emitted both a synthetic reference to the label in
the instrumentation map, and to the entry in the function map index.
This change removes the first synthetic reference and only emits one
synthetic reference to the index -- the index entry has the references
to the labels in the instrumentation map, so the linker will still
preserve those if the function itself is preserved.

This reduces the amount of synthetic references we emit from 16 bytes to
just 8 bytes in x86_64, and similarly to other platforms.

Diff Detail

Repository
rL LLVM

Event Timeline

dberris created this revision.Jun 19 2017, 12:06 AM
dblaikie accepted this revision.Jun 19 2017, 1:46 PM

Roughly makes sense to me.

lib/CodeGen/AsmPrinter/AsmPrinter.cpp
2833–2834 ↗(On Diff #102991)

Do these both need to be link-time (or even runtime, I guess) relocations? Or could the 'end' be stored as "end - start" (ie: length rather than end) to remove an extra relocation from the object file?

This revision is now accepted and ready to land.Jun 19 2017, 1:46 PM

Thanks -- landing this now, we can change more of the details later.

lib/CodeGen/AsmPrinter/AsmPrinter.cpp
2833–2834 ↗(On Diff #102991)

We can change this, but then that means we're going to have to coordinate it between how we're using the index in the runtime and the back-end (here). Is the concern the effect on linking time? Or do these symbols pollute the debug info somehow?

This revision was automatically updated to reflect the committed changes.