Skip to content

[Attributor] IPO across non-amenable call edges #172

Open
@jdoerfert

Description

@jdoerfert

If a function is externally visible, the address is potentially taken, or certain uses are non-trivial, we are conservative when it comes to inter-procedural optimizations (IPO). That is, we do not propagate information from the call sites we know to the called function (=callee). Similarly, when the function has a non-exact definition we do not propagate information from the called function we see to the call sites.

To mitigate both problems we can "internalize" the function, or put differently, specialize the called function (the one we see) to (a subset of) the call sites we see.

Prototypes of what we need are available already D63312 and D63319 especially.

This metabug is to allow us to track the overall task as we split it up in smaller chunks. Thus, we expect this bug to be edited as we go.

  • Allow us to derive "inwards facing" attributes on non-exact function call interfaces. That is, if we have a function that is non-exact, we can still annotate arguments if we either create a thin wrapper around the function (see D63312) or the annotation is not going to be used (=usable) at the call sites.
  • Utilities to create a dependence graph in the Attributor. Nodes are AbstractAttributes, edges are dependences as recorded in the Attributor::QueryMap. We need functions to print the dependence graph, determine sub-graphs that contain a set of specified nodes, ... A new issue will be created for this.
  • Design a cost function interface for AbstractAttributes and populate it with value for the existing ones. E.g., determining dereferenceable on a pointer argument is worth almost nothing if it is not used but potentially quite useful if it is loaded from in a loop, even more if it is additionally readonly and noalias, etc.
  • Design experiments to determine the impact and good trade-offs. At the end of the day we want to see how function internalization plays against inlining wrt. compile time, runtime, and size. We need experiments that try out different combinations from aggressive inlining to no inlining at all.
  • Analyze the cases one of the methods is "clearly" superior to determine (1) why and (2) if we can generalize that into a heuristic that drives the optimization.

Metadata

Metadata

Assignees

Labels

gsocGoogle Summer of Codehelp wantedIndicates that a maintainer wants help. Not [good first issue].ipoInterprocedural optimizationsmetaissueIssue to collect references to a group of similar or related issues.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions