On Jan 6, 2014, at 10:10 AM, Chandler Carruth <chandlerc at google.com>
wrote:
> 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.
Do we have a solution that can work with TTI? I don’t think there was any
objection to putting CGContext in TargetMachine, except that we have too many
layers of abstraction, which you said will be cleaned up eventually:
IR Transform
(links with) -> TargetTransformInfo
(dynamic call) -> X86TTI
(links with) -> TargetMachine
(provides) -> CGContext
-Andy
>
>
> 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/8dd4b3b2/attachment.html>