[llvm] r209386 - Override runOnMachineFunction for ARMISelDAGToDAG so that we can

[Andrew Trick]

On May 23, 2014, at 9:32 AM, Eric Christopher <echristo at gmail.com> wrote:

> Right now the TargetMachine (via LLVMTargetMachine) contains both the
> pass hierarchy and is subclassed by the targets to contain a bunch of
> things for optimization in the way of the passes that are added to the
> pipeline and TargetTransformInfo. It also contains
> TargetSubtargetInfo, TargetLoweringInfo (which contains
> TargetLoweringObjectFile), TargetRegisterInfo, the scheduling
> information (we should really make that a container), TargetInstrInfo,
> TargetFrameLowering, etc.
> 
> Nearly all of these are initialized with the subtarget in mind.
> Basically on instantiation a single TargetMachine instance is going to
> be severely subclassed and initialized for a particular subtarget. In
> particular, think about the way that we were adding passes based on
> subtarget (this I fixed mostly - one not very important caveat) for
> the pass manager. Another good one is operation legality is very much
> based on subtarget as particular operations are added as
> legal/promote/expand based on subtarget. So it isn't just codegen per
> se, it's everything including the pass pipeline is controlled by the
> TargetMachine.
> 
> The direction I'm currently working on is getting the subtarget to be
> a wholly contained subtarget. The subtarget will contain the things
> that are based on subtarget. The target machine will contain things
> that aren't specific to a particular subtarget (think
> TargetRegisterInfo which isn't subtarget based). The TargetMachine
> will contain the bits about the target that aren't dependent upon
> subtarget configuration. The subtarget will contain the rest of it.
> This keeps as much of the existing pipeline working without additional
> overhead as possible (because hey, compile time is still a thing). If
> we want to move to parallel codegen (something that could be cool)
> then we'll still want to separate all of this out so that we don't
> have to try to instantiate a new TargetMachine just to optimize and
> generate code for a particular function.
> 
> So I see the CGContext morphing partially the original design to more
> of something like the existing LLVMContext. The CGContext will hold
> things like our cache of subprograms (or target machines if we get to
> the X86 + ARM in the same module place), and other things necessary
> for compilation, but not replacing the existing idea of a target
> machine. We could pass the CGContext into the passes - and might want
> to at pass initialization to make it easier to get things for sure
> (probably a good idea - we can see how it comes out), but it's a
> decision that can be made later after we do the other stuff I've been
> talking about.
> 
> So the hierarchy as I see it is probably something like this:
> 
> CGContext (ultimately) - holds
>    TargetMachine -
>        creates and holds Passes
>        creates and vends instances of TargetSubtargetInfo -
>             holds TargetLoweringInfo etc
> 
> The CGContext will take the place of the TargetMachine in the current
> hierarchy eventually, but I'm not seeing a need to churn some of those
> pass aspects yet when we've already got a TargetMachine.

That hierarchy makes sense from a naming perspective. But that version of CGContext would not serve much purpose currently. Compiling multiple targets per module sounds kind of silly to me, since target data is specified at the module level (I guess it’s not silly if it can actually serve a useful purpose for someone). Clearly if we did that we would need multiple TargetMachines, but why would CodeGen passes need to see the TargetMachine container? And now we're left without a name for the thing CGContext was originally proposed for.

My interest in all this was having a place to hold the per function codegen options, and one place for codegen to get at them. They may come from the front end, function attributes, defaults, command line, but we should have one point of truth for the codegen settings and a context object to hold them that doesn't rely on globals.

Back when Bill was working on this we talked about being able to get the CGContext from TargetMachine+Function. The idea was that TargetMachine could cache and reuse part of the context for functions with the same attributes.

There is clearly a difference between a Subtarget and CGContext in that proposal. CGContext vends function attributes that control codegen but aren't specific to a particular subtarget. I think a Subtarget is nothing more than a selection within the statically determined set of supported CPU types and a feature bitset.

I guess what I'm looking for is a CGSubContext: the finest granularity at which codegen is configured.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140523/690f1a39/attachment.html>