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

[Bob Wilson]

On May 26, 2014, at 11:00 PM, Eric Christopher <echristo at gmail.com> wrote:

> On Mon, May 26, 2014 at 8:51 AM, Bob Wilson <bob.wilson at apple.com> wrote:
>> 
>> 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.
>> 
> 
> I'm down with this. Seems like a useful shortcut. Arguably we'll want
> to do it on Function as well once we start the pass pipeline. (I think
> I've mentioned this before, but can't find it at the moment :)

By “do it on Function”, do you mean stash a reference to the subtarget in the Function object?

> 
>> 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.
> 
> Storing a pointer to the subtarget on the MachineFunction is fine if
> it's a help to the pass infrastructure. I have no particular care
> there. Just to make sure that we're on the same page here, we're still
> going to need to separate target machines from subtarget as part of
> that process.

Yes, I agree that we need to separate out the subtarget.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140527/48ae756a/attachment.html>