[LLVMdev] [RFC] CGContext skeleton implementation

[Chandler Carruth]

Trying to bubble way back to the top, Andy, do you think there is anything
else that needs to be done here before it can go in? I feel like most of
our discussion centered around future work, and I'd like to unblock the
immediate work to support subtarget-specific code generation.


On Thu, Dec 5, 2013 at 6:19 PM, Dan Gohman <dan433584 at gmail.com> wrote:

>
>
>
> On Mon, Dec 2, 2013 at 4:25 PM, Andrew Trick <atrick at apple.com> wrote:
>
>>
>> On Nov 25, 2013, at 4:40 PM, Dan Gohman <dan433584 at gmail.com> wrote:
>>
>> > Hello llvm-dev,
>> >
>> > Following up on the "CodeGen Context" discussion that was started,
>> attached is patch which implements a pretty minimal skeleton of a CGContext
>> implementation. The goal is to allow the newly added subtarget attributes
>> on functions to be made available to codegen so that codegen can actually
>> switch subtargets within a Module.
>> >
>> > Comments and questions are invited herewith.
>> >
>> > There has been some disagreement as to what to name this class. I have
>> stuck with "CGContext" for now, though I'm absolutely not attached to that
>> name.
>> >
>> > It demonstrates where the CGContext state lives, how code can access it
>> (in X86ISelLowering.cpp), how it reads the attributes from the IR, and how
>> it gets cached.
>> >
>> > One thing that it doesn't yet do is hook up to the target-specific
>> subtarget feature interpretation. For example, it would need to hook up to
>> the x86 subtarget code which knows that, for example, sse4.2 implies
>> sse4.1, and so on. However, I'm sending this out now so that the other
>> parts of the patch can get some feedback.
>>
>> Hi Dan,
>>
>> This basic idea makes sense to me. It is consistent with my understanding
>> of Bill's proposal. What I don't understand is why CGContext is tied to to
>> CodeGen objects and initialized at ISelLowering. We should be able to get a
>> CGContext from a TargetMachine by providing a Function.
>>
>
>> IR passes like the LoopVectorizer and LSR also require subtarget
>> information. This was formalized by TargetTransformInfo. Now any pass using
>> TargetTransformInfo needs to respect the current Function attributes, which
>> means reinitializing subtarget info. I also think that IR passes should use
>> the same interface as SD/MI passes to query codegen modes, rather than
>> directly querying Function attributes. For that reason, they should also
>> use CGContext. It should be possible to override those modes with command
>> line options, but I don't think we should have ad-hoc overrides buried
>> within passes.
>>
>
> In my current patch, the CGContext instances are kept within
> MachineModuleInfo instance. You're right that this is a Codegen-oriented
> class. What would you think about having the CGContext instances kept in
> the LLVMContext? This would also allow them to be cached in the same way,
> and it would make them available to any part of the middle or backend that
> wanted them.
>
>
>>
>> I think it would be cleanest if the IR pass pipeline had an explicit
>> point at which the subtarget gets initialized--say a SubtargetInfo pass. IR
>> passes that run early can still get architecture defaults from
>> TargetTransformInfo, but can't make any subtarget specific queries. IR
>> passes that run after this point should be able to make CGContext queries,
>> either directly or via TargetTransformInfo (I'm not sure there is any real
>> advantage in treating TargetTransformInfo as an analysis).
>>
>
> Dividing the optimization pipeline into "before" and "after" subtarget
> information is a bit beyond the scope of what I'm looking to do here. If
> CGContext is moved to LLVMContext (and perhaps renamed), then it can be
> available to any pass, and the decision of when to introduce subtarget
> information can be made at a higher level.
>
> Dan
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140106/184ff912/attachment.html>