[LLVMdev] Extracting libmachine from libcodegen (bug 1121)

Ken Dyck kd at kendyck.com
Thu Sep 12 16:49:45 PDT 2013

On Wed, Sep 11, 2013 at 12:29 AM, Andrew Trick <atrick at apple.com> wrote:
> If that is the goal, then you only want the modules for Machine IR, and maybe some core analysis passes. The “Machine” modules you listed above include machine code analysis or transform passes that you probably don’t want. Pruning the list to basic IR support:
>> - MachineBasicBlock
>> - MachineBranchProbabilityInfo
>> - MachineCodeEmitter
>> - MachineDominators
>> - MachineFunctionAnalysis
>> - MachineFunction
>> - MachineFunctionPass
>> - MachineFunctionPrinterPass
>> - MachineInstrBundle
>> - MachineInstr
>> - MachineLoopInfo
>> - MachineModuleInfo
>> - MachineModuleInfoImpls
>> - MachinePassRegistry
>> - MachinePostDominators
>> - MachineRegisterInfo
>> - MachineSSAUpdater
>> - MachineVerifier

Thanks for whittling the list down, Andrew.

One question that has been nagging at me since I started looking into
this is what to do about the dependency on libAnalysis? Some of these
classes (eg. MachineFunctionPass are MachineLoopInfo) seem to have a
hard dependency on the Pass class in libAnalysis. Is it acceptable to
carry this dependency along to the new library? Or should we be aiming
to eliminate this dependency like we are with the one on libCodeGen?

> Note that Passes.h would need to be provided in include/llvm/Machine so
> that targets can configure their pass pipeline. The pass ID’s are extern
> declared for use with TargetPassConfig, but are defined as references to
> the ID field inside the pass. Those ID’s might all need to live inside
> libMachine if you do this. To get the layering right, there would need to be
> two libraries in each target, lib<target>Machine for the target description,
> and lib<target>Codegen for the pases--but we clearly don’t want this,
> hence the Pass ID workaround.

Thanks for pointing those out.


More information about the llvm-dev mailing list