This is a strawman design for a set of "properties" that a
MachineFunction can have at particular points in time. Currently we have
MachineRegisterInfo::isSSA() and MachineRegisterInfo::tracksLiveness()
and we are also discussing the "post-RA" property (i.e. there are no
virtual register operands). We want an easy way for MachineFunctions to
declare that they require a particular property to hold, and that they
set or clear a particular property. This facility is somewhat similar to
the way passes can declare their required analysis passes, inviting a
comparison of the requirements/use cases:
- Like analysis passes, passes can require that property hold.
- Unlike analysis, all possible properties can be listed in one place as an enum (as opposed to an arbitrary pass ID)
- Properties can be set by a pass (unlike analysis where the anlysis is provided by a special kind of pass and managed by a pass manager)
- Properties may be conditionally cleared (e.g. BranchFolder conditionally invalidates liveness)
This design just represents the properties as a bit vector stored on the
MachineFunctionObject, and the pass requirements and modifications as
objects on the MachineFunctionPass. Passes can declare that they
require, or unconditionally set or clear properties by setting these
objects in their constructor, (which results in automatic checking) or
they can query or modify the MachineFunction's properties when the pass
is run.
Currently it just implements the "post-RA" property as
AllVRegsAllocated, for X86. It still needs a few fixes and name bikeshedding.
Possible alternative design features/constraints:
- Allow passes to require that a property is clear (instead of just set)
- Make all passes require a particular property unless they clear the requirement themselves
- Allow targets to extend the list
Possible alternative implementations:
- Return set of set/cleared properties from a query function (similar to getAnalysisUsage) instead of keeping a static data structure set in the constructor
I think it would be nice to have this extendable by the target, especially if the properties are checked and/or give some control over the compilation pipeline.
E.g., On ARM, passes could set a property has load/store and the load/store optimizer would be only run if such property is true. The example is a bit lame, but you get the idea.
Obviously, this can already be achieved by querying within the passes the MachineFunctionInfo instances, but it sounds reasonable to have this kind of broad mechanism.