Should split libcodegen into libcodegen and libmachine

[Quuxplusone]

Bugzilla Link	PR1121
Status	NEW
Importance	P normal
Reported by	Chris Lattner (clattner@nondot.org)
Reported on	2007-01-17 11:30:51 -0800
Last modified on	2020-03-03 07:51:52 -0800
Version	1.0
Hardware	All All
CC	anton@korobeynikov.info, bestofnithish@gmail.com, evan.cheng@apple.com, joshkergan@gmail.com, kd@kendyck.com, llvm-bugs@lists.llvm.org, resistor@mac.com, rspencer@reidspencer.com
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

lib/Codegen/* contains two separate things: implementations of the Machine*
classes (e.g.
MachineBasicBlock) and a collection of code generator-related passes.

We should split this into two pieces: lib/CodeGen/Machine and lib/Codegen.  The
reason for this is that
individual targets (e.g. the PPC target) should depend (in a library dependence
sense) on the machine bits,
but not on the Codegen bits.  Currently, the various targets do depend on
various machine code passes
(e.g. the asmprinter) which causes large amounts of code to be linked in to
apps that don't need it (e.g. lli
gets asmprinter, machowriter, elfwriter, etc).  Once lib/CodeGen is split up,
we can chase these
dependencies down more easily and eliminate them.

-Chris

[Quuxplusone]

Sounds good to me. Just don't create any dependency cycles :)

[Quuxplusone]

But won't the libcodegen passes depend on libmachine? It seems, that most passes
(e.g. live* and others) uses misc. "machine" routines.

[Quuxplusone]

yes, libcodegen will depend on libmachine.  The trick is to get stuff to not
depend on libcodegen (to
reduce code size) :)

[Quuxplusone]

Anton's recent work on splitting the AsmPrinter out should have helped with this.

[Quuxplusone]

Is this still the direction to go -- extracting libmachine out of libcodegen? I find myself with a little free time for recreational hacking and thought I might pick this up.

[Quuxplusone]

Yep, I think it still makes sense, but please bring this up on llvmdev. The community at large should be aware of this and be able to chime in.

[Quuxplusone]

I want to take this up and hack into it and try to get a solution for it. So I wanted to know if someone is alraedy doing this?

[Quuxplusone]

Hi Nitish, I just started looking into this yesterday. I haven't gotten get very far yet. Perhaps we could work on it together.

[Quuxplusone]

(In reply to comment #8)
> Hi Nitish, I just started looking into this yesterday. I haven't gotten get
> very far yet. Perhaps we could work on it together.

Sure sir.

[Quuxplusone]

(In reply to comment #5)
> I find myself with a little free time for recreational hacking
> and thought I might pick this up.

Given how little progress I've made on this over the past month (i.e. none) it
seems best to step aside and let somebody else pick this up. Consider this bug
once again up for grabs.

[Quuxplusone]

I am taking this up as my academic project and working on it now.

[Quuxplusone]

Anyone mind if I pick this up as a side project for the next couple months?

[Quuxplusone]

It's not clear to me that this is still desirable. Most of the reasons listed in the original report are no longer relevant.

[Quuxplusone]

(In reply to comment #13)
> It's not clear to me that this is still desirable.  Most of the reasons
> listed in the original report are no longer relevant.

So you think that leaving them coupled together is fine? I'm not sure how
independent they really should be.

[Quuxplusone]

The passes that Chris highlighted as not being required for LLI are now required for LLI for practical reasons, so it's not clear that separating the two would achieve anything.

[Quuxplusone]

Okay, should this be marked as resolved then?