Proposal: Backward-edge CFI for return statements (RCFI)

Authored by kcc on Mar 17 2017, 6:44 PM.



Proposal: Backward-edge CFI for return statements (RCFI)

Diff Detail

kcc created this revision.Mar 17 2017, 6:44 PM
eugenis accepted this revision.Mar 20 2017, 1:52 PM
eugenis added inline comments.
525 ↗(On Diff #92242)


This revision is now accepted and ready to land.Mar 20 2017, 1:52 PM
kcc closed this revision.Mar 20 2017, 1:54 PM
This revision was automatically updated to reflect the committed changes.
pcc added a subscriber: tejohnson.Mar 21 2017, 12:06 PM
pcc added inline comments.

Right now the definition of a "function called once" (etc.) would depend on inlining decisions (although with ThinLTO the summary controls which functions are imported, all final inlining decisions are made by individual compilation units). So without changes to this flow you basically would need these steps:

  1. thin link
  2. thin backends (optimization phase)
  3. "second thin link": make global decisions about which functions are called once etc.
  4. thin backends (code generation phase)

The third step would necessarily be a serialization over all thin backends.

In principle, we could change ThinLTO so that all final inlining decisions are made in the thin link phase. Then we would be able to classify functions at thin link time. But I foresee that as being difficult: the code that decides whether inlining is possible is already quite complex: . That code would need to be re-implemented in the thin link to avoid soundness issues.

We would also need to be careful about changing the number of call sites for a particular function. At least we would need to prevent the thin backend from duplicating a call site, as that could potentially change the calling convention. So we'd need to attach the noduplicate attribute to all call sites for functions deemed to be "called once". If we allow removing call sites, we would need to come up with some scheme to allow the size of the jump table to vary.

To me all signs point to this being better implemented in the linker rather than LTO (or as some sort of postprocessing step over the object files produced by LTO).

kcc added a comment.Mar 21 2017, 4:29 PM

But I foresee that as being difficult

Yep. That pesky phase-ordering again.