[LLVMdev] [RFC] CGContext skeleton implementation

[Dan Gohman]

On Tue, Nov 26, 2013 at 6:31 AM, Bill Wendling <isanbard at gmail.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,
>

Hi Bill,


> Thanks for working on this! I like the direction this is going. One thing
> though, the function attributes no longer have “target-cpu” and
> “target-features” in them. I opted to separate out all of the different
> flags into separate attributes, instead of relying upon a single feature
> string. So the caching key would need to be modified here. Or do you think
> we should go back to adding back those attributes?
>

One of the advantages os using a single target-features string is that it's
easy to extend; there's no need for the CGContext code to know which
attributes it should care about and which it should ignore, unless we
introduce a naming convention. Alternatively, we could just have it read
*all* the attributes all the time. What do you think?


>
> One thing to be addressed is when one function has attributes but the next
> function lacks them. Some type of default value needs to be assumed for the
> function lacking an attribute, and the context cached accordingly.


Yes, that's a good point. I'll update my patch to include code to handle
that case.

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131126/4855519f/attachment.html>