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

[Eric Christopher]

On Mon, May 26, 2014 at 9:23 AM, Bob Wilson <bob.wilson at apple.com> wrote:
>
> On 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.
>
> 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.
>
>
> …and of course it doesn’t currently exist at the time of the Selection DAG
> lowering, but presumably we could change that. That would seem a bit strange
> in Selection DAGs but assuming that we eventually make progress on moving to
> a new instruction selection scheme, it would probably fit well in the long
> term.
>

Not going to hold my breath here. I think we'll get parallel codegen
before we get a new instruction selector the way we've been going.

-eric