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

[Bob Wilson]

On May 24, 2014, at 1:29 PM, Eric Christopher <echristo at gmail.com> wrote:

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

I had composed a reply to this that tried to explain what I had in mind after talking with Andy a while back. It was more along the lines of the “CGSubContext” that he mentioned. I still haven’t had much time to dig into the details, but after looking at it briefly this morning, I deleted my reply since I think there might be a more incremental approach. I’m wondering if MachineFunction shouldn’t play the role of that “CGSubContext”. I think it is the closest thing we have to that right now.

With regard to subtargets, I think it would boil down to stashing a reference to the subtarget in the MachineFunction instead of going through TM->getSubtarget(). We would set the subtarget early in code-gen using the function attributes and caching proposal discussed earlier. Subsequent uses of the subtarget would then get it from the MachineFunction without having to check the function attributes again.

Andy, how well would that fit with your desire to get “the finest granularity at which code-gen is configured”? One obvious drawback is that it wouldn’t help for the earlier IR-level code-gen passes where the MachineFunction has not yet been created.