[PATCH] D13193: Add an MCTargetMachine and use it to configure MCAsmInfo

Daniel Sanders via llvm-commits llvm-commits at lists.llvm.org
Tue Oct 13 03:59:25 PDT 2015


dsanders added a comment.

I think I've caught on to the difference between your mental model and mine. It's just been tricky to notice it because the things you've said here fit perfectly into my mental model. :-)

In my mental model, I have an object named MCTargetMachine describing the desired target. I configure this however I want (starting with the triple then mutating it according to command line options). I then give this MCTargetMachine to MCCodeGenInfo, MCAsmInfo, MCRegisterInfo, MCInstrInfo, MCSubtargetInfo, etc. when constructing them and they consult it whenever they want to know certain properties of the target. When you spoke about MCTargetMachine holding information from these classes, I read it as moving the decision-making values into MCTargetMachine and having them ask MCTargetMachine for it which is what I was already doing.

I suspect your mental model is that MCTargetMachine holds an owning pointer to MCCodeGenInfo, MCAsmInfo, MCRegisterInfo, MCInstrInfo, MCSubtargetInfo, etc. and is also responsible for constructing them. This model works pretty much the same way as mine to begin with. You construct a MCTargetMachine and configure it. The difference is that the users then ask MCTargetMachine to create the various objects on their behalf and MCTargetMachine passes itself into their respective constructors in order to configure them. Is that what you're going for?

If that understanding is correct then there are two major steps here.

- Encapsulate MC layer objects in MCTargetMachine and make it their owner. This is effectively moving user calls to createMC*() into MCTargetMachine.
- Update the constructors to take an MCTargetMachine or at least information originating from it.

With my existing plan being the latter of these two steps. As far as the end result is concerned, I don't think it matters too much which order we do the steps.
I suppose we have less user-visible churn if we do the encapsulation of the MC layer objects first though.


http://reviews.llvm.org/D13193





More information about the llvm-commits mailing list