
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On May 26, 2014, at 8:51 AM, Bob Wilson <<a href="mailto:bob.wilson@apple.com">bob.wilson@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>On May 24, 2014, at 1:29 PM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:<br><br><blockquote type="cite"><blockquote type="cite">That hierarchy makes sense from a naming perspective. But that version of<br>CGContext would not serve much purpose currently. Compiling multiple targets<br>per module sounds kind of silly to me, since target data is specified at the<br>module level (I guess it’s not silly if it can actually serve a useful<br>purpose for someone). Clearly if we did that we would need multiple<br>TargetMachines, but why would CodeGen passes need to see the TargetMachine<br>container? And now we're left without a name for the thing CGContext was<br>originally proposed for.<br><br></blockquote><br>Heh. I can see what you mean, but you can come up with reasons if you<br>look at the GPGPU/accelerator space to have multiple target machines<br>in a file. It's a pretty cool idea in that you could ship pre-compiled<br>functions that are accelerated for <insert GPU or weird accelerator on<br>chip here>, but that's definitely a ways off. Let's get single target<br>with multiple subtargets first. I think multiple target machines will<br>look like an obvious extension after.<br><br><blockquote type="cite">My interest in all this was having a place to hold the per function codegen<br>options, and one place for codegen to get at them. They may come from the<br>front end, function attributes, defaults, command line, but we should have<br>one point of truth for the codegen settings and a context object to hold<br>them that doesn't rely on globals.<br></blockquote><br>Agreed I think.<br><br><blockquote type="cite"><br>Back when Bill was working on this we talked about being able to get the<br>CGContext from TargetMachine+Function. The idea was that TargetMachine could<br>cache and reuse part of the context for functions with the same attributes.<br><br>There is clearly a difference between a Subtarget and CGContext in that<br>proposal. CGContext vends function attributes that control codegen but<br>aren't specific to a particular subtarget. I think a Subtarget is nothing<br>more than a selection within the statically determined set of supported CPU<br>types and a feature bitset.<br></blockquote><br>This won't really work unfortunately. Too many things are initialized<br>when you create a subtarget. Think about all of the classes I<br>mentioned in my previous post that were initialized at instantiation<br>(in particular things like operator legality). It might be possible to<br>pull all of those out into dynamic checks but then you're really<br>penalizing the common case of a single subtarget for code gen and not<br>letting everything be compared once at initialization. A lot of this<br>is trying to minimize the cost overhead for the normal case today as<br>well.<br><br><blockquote type="cite"><br>I guess what I'm looking for is a CGSubContext: the finest granularity at<br>which codegen is configured.<br><br></blockquote><br>Right. I see CGContext at the moment being a lookup of strings<br>(feature, cpu, other options) to TargetSubtargetInfo once we've<br>created one. We could attempt to encapsulate all of the subtarget<br>configured bits of a TargetMachine into a single construct, but I<br>propose that's just refactoring those things into the subtarget rather<br>than adding something between TargetSubtargetInfo and TargetMachine.<br>We can lookup based on the function and grab the correct subtarget for<br>any/all of our passes etc. We can do this by either asking the<br>TargetMachine, or keeping CGContext as a set of things that might be<br>desired by the various passes and having that be initialized in all of<br>the passes rather than the TargetMachine (which is in a number of<br>passes right now). Don't have a good feel there which one is better, I<br>suspect it doesn't matter much and I don't have a strong opinion.<br></blockquote><br>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.<br><br>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.<br><br>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.</div></blockquote><br></div><div>…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.</div><br></body></html>