[LLVMdev] LLVM Loop Vectorizer
evan.cheng at apple.com
Sat Oct 6 10:50:16 PDT 2012
On Oct 5, 2012, at 5:29 PM, Chris Lattner <clattner at apple.com> wrote:
> On Oct 5, 2012, at 2:11 PM, "Villmow, Micah" <Micah.Villmow at amd.com> wrote:
>> Is it possible to not make it 'Target*'? I'm spending a lot of time moving TargetData out, would hate to have to do it again at some point in the future for TargetVectorData. :)
> There is an important difference here (and a common point of confusion) between TargetData and the the stuff Nadav is talking about. TargetData has *never* really been about modeling stuff at the "lib target" level: it's a concrete class that can't be extended by a target, and its behavior is fully described by LangRef. TargetData (now DataLayout!) is really an IR concept, not a target concept. Obviously it is used to model things that are target specific (which is why I made the mistake of putting it where it is, and why other people continue to be confused by it) but it really is a completely different concept than what Nadav is talking about for getting cost information.
> The stuff at the "libtarget level" are meant to be subclassed by targets, and are needed to specify things that vary based on context and are not capable of being serialized into a string. Consider a query like "how expensive is a shuffle with this type on this shuffle mask". Clearly the only way to implement this is by having the target implement a virtual method call.
> Another sore point (for me) is that TargetLoweringInfo is a terrible mish-mash of stuff that things like LSR and things like SelectionDagLowering need. It definitely needs to be cleaned up and have some sanity beat into it (we don't want LSR thinking about MCExprs!), but this is a problem with the design of TargetLoweringInfo itself, not a problem with the concept of mid-level optimizers being parameterized by target information.
I think we can all agree TLI is terrible and it is not the right interface for new optimizations. I'd like to delay the TLI clean up work for later though.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev