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

[Eric Christopher]

On Mon, May 26, 2014 at 11:01 PM, Eric Christopher <echristo at gmail.com> wrote:
> 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.
>

(Not to say that the idea was bad, just what seems to be occurring as
far as development)

-eric