[LLVMdev] Extracting libmachine from libcodegen (bug 1121)

[Jim Grosbach]

Hi Ken,

This is awesome! It's a long needed refactoring. One place I suggest you start is by reading, if you haven't already, the recent global instruction selection and machinefunction serialization threads. This refactoring is a prerequisite to a lot of that, so there's some related discussion there you may find useful.

-Jim

On Sep 5, 2013, at 5:15 PM, Ken Dyck <kd at kendyck.com> wrote:

> Hi,
> 
> One of the long-standing code clean-up bugs in Bugzilla is to extract
> the Machine* code from the CodeGen library into a separate one, on
> which CodeGen depends (
> http://llvm.org/bugs/show_bug.cgi?id=1121).
> 
> I'd like to start working on this. The general approach I'm planning to take is:
> 
> 1. Identify which code to move.
> 2. Eliminate all dependencies that the Machine code has on the CodeGen
> code (details to be fleshed out on llvmdev as they are encountered).
> 3. Create a library project for the Machine code
> 4. Move the code to the new library.
> 
> Do you have any concerns about the feasibility this approach?
> 
> As to step 1, I haven't dug too deeply into the problem yet, but I'm
> starting from the assumption that we'll be moving only the modules
> that start with 'Machine' into the new library. These are:
> 
> - MachineBasicBlock
> - MachineBlockFrequencyInfo
> - MachineBlockPlacement
> - MachineBranchProbabilityInfo
> - MachineCodeEmitter
> - MachineCopyPropagation
> - MachineCSE
> - MachineDominators
> - MachineFunctionAnalysis
> - MachineFunction
> - MachineFunctionPass
> - MachineFunctionPrinterPass
> - MachineInstrBundle
> - MachineInstr
> - MachineLICM
> - MachineLoopInfo
> - MachineModuleInfo
> - MachineModuleInfoImpls
> - MachinePassRegistry
> - MachinePostDominators
> - MachineRegisterInfo
> - MachineScheduler
> - MachineSink
> - MachineSSAUpdater
> - MachineTraceMetrics
> - MachineVerifier
> 
> Are there any files in this list that should not be moved? Any others
> that should be added? Any suggestions on which of these modules would
> be a good place to start?
> 
> One question of procedure... Back in 2010 and 2011, I had commit
> rights on the LLVM svn repository because of work I was doing on
> Clang. I'm not sure whether my account is still active, but if you'd
> like I re-qualify myself as a contributor by submitting patches to
> llvm-commits instead of making changes directly to the repository,
> just let me know.
> 
> -Ken
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev