[LLVMdev] [RFC] CGContext skeleton implementation

[Chandler Carruth]

On Thu, Dec 5, 2013 at 4:16 PM, Andrew Trick <atrick at apple.com> wrote:

> We currently have something that looks like:
>
> IR Transform
> (links with)   -> TargetTransformInfo
> (dynamic call) -> X86TTI
> (links with)   -> X86Subtarget
>
> I was thinking of directly replacing X86Subtarget as such:
>
> IR Transform
> (links with)   -> TargetTransformInfo
> (dynamic call) -> X86TTI
> (links with)   -> TargetMachine
> (provides)     -> CGContext
>
> So CGContext could still live inside libTarget. CGContext would be
> initialized for a Function based on the attributes and the information
> already in its container, TargetMachine.
>
> It sounds like you would be making CGContext part of libCore instead, like
> this:
>
> IR Transform
> (links with)   -> LLVMContext
> (provides)     -> CGContext
>
> CGContext would still need to be initialized with a TargetMachine, which
> could happen whenever the TargetMachine and Function are both available.
>
> I'm fine with that as long as
> - no one objects to putting CGContext in libCore
> - our goal is to eventually replace TargetTransformInfo with CGContext
> (maybe renamed)
>
> I think the issue here is whether we want to continue use an AnalysisGroup
> to vend target info, or rather to have passes get what they need from
> LLVMContext. I find the AnalysisGroup thing too subtle and prone to driver
> bugs, but haven't fully worked out an alternate design.
>

I'm not actually a fan of the analysis group hack, and there are better
ways to slice this, but I don't really like the direction of putting the
CGContext into the LLVMContext.

There are still very viable uses of LLVM which have *no* concept of a
target outside of the LLVM IR itself. I think we should preserve this
abstraction boundary. I think that means there needs to be an *abstract*
interface between the IR layer and the target/codegen layer with a dynamic
call across that boundary.

So this makes sense to me:

LLVMContext
>   -> TargetContext (initialized when TargetMachine is available)
>     -> SubtargetContext (initialized when Function attributes are
> available)
>

Only if TargetContext and SubtargetContext are abstract interfaces with
trivial implementations available for cases where there is no target (in
the libTarget sense).

I don't really think that's what you're aiming for, so I would advocate for
the MachineModuleInfo or the TargetMachine being the provider of the
CGContext or the TargetContext and SubtargetContext. I like the
TargetMachine providing it personally, but I don't feel strongly here. I
also think that we could start with the MachineModuleInfo providing it and
refactor that in a subsequent patch.


FWIW, I have a plan to remove the crazy analysis group stuff in the new
pass manager. My hope is that we have a simple analysis which can be
configured with dynamic calls into a TargetMachine (or some
TargetMachine-wrapping interface). It will be very explicit with none of
the analysis group magic. It will just preserve the dynamic interface
boundary between the the IR layer and the target layer.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131205/b3f3006f/attachment.html>