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

[Eric Christopher]

> 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.
>

Heh. I can see what you mean, but you can come up with reasons if you
look at the GPGPU/accelerator space to have multiple target machines
in a file. It's a pretty cool idea in that you could ship pre-compiled
functions that are accelerated for <insert GPU or weird accelerator on
chip here>, but that's definitely a ways off. Let's get single target
with multiple subtargets first. I think multiple target machines will
look like an obvious extension after.

> 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.

Agreed I think.

>
> 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.

This won't really work unfortunately. Too many things are initialized
when you create a subtarget. Think about all of the classes I
mentioned in my previous post that were initialized at instantiation
(in particular things like operator legality). It might be possible to
pull all of those out into dynamic checks but then you're really
penalizing the common case of a single subtarget for code gen and not
letting everything be compared once at initialization. A lot of this
is trying to minimize the cost overhead for the normal case today as
well.

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

Right. I see CGContext at the moment being a lookup of strings
(feature, cpu, other options) to TargetSubtargetInfo once we've
created one. We could attempt to encapsulate all of the subtarget
configured bits of a TargetMachine into a single construct, but I
propose that's just refactoring those things into the subtarget rather
than adding something between TargetSubtargetInfo and TargetMachine.
We can lookup based on the function and grab the correct subtarget for
any/all of our passes etc. We can do this by either asking the
TargetMachine, or keeping CGContext as a set of things that might be
desired by the various passes and having that be initialized in all of
the passes rather than the TargetMachine (which is in a number of
passes right now). Don't have a good feel there which one is better, I
suspect it doesn't matter much and I don't have a strong opinion.

-eric