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

[Eric Christopher via llvm-commits]

You've got my mental model fairly well established. I'll take a look at
this yesterday and make sure it's going to work the way I want.

Thanks for your patience!

-eric

On Tue, Oct 13, 2015 at 3:59 AM Daniel Sanders <daniel.sanders at imgtec.com>
wrote:

> 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151016/7ec2513b/attachment.html>