On Oct 5, 2012, at 1:14 PM, Eric Christopher <echristo at gmail.com> wrote:> Nadav, > >>> Possibly, though I think TargetData should still be able to get you >>> what you want. >> >> >> TargetData does not have enough information for vectorization. For example, we need to ask the target if it has efficient "cos4" implementation or the cost of 'mult_4xf32'. We need lots of target specific information for deciding when to vectorize and which vectorization optimizations to apply. >> > > Sure. I was mostly going with the idea of "insert some Targetish > structure here". > >>> TargetData is pretty useful during opt if it's available, probably no >>> need to merge >>> the tools though. >> >> TargetData is useful, but not enough for vectorization. > > I think an interface should be designed on top of the current sets of > data that will encompass what we may want at the target level and we > can make our decisions based on that.Yes. I plan to start working on this new interface (TargetVectorData ?) as soon as we merge the tools.> Specific names or making "X > class available to Y passes at Z level" can probably wait. >yep.> -ericThanks :)
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. :)> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Nadav Rotem > Sent: Friday, October 05, 2012 1:23 PM > To: Eric Christopher > Cc: llvmdev at cs.uiuc.edu Mailing List > Subject: Re: [LLVMdev] LLVM Loop Vectorizer > > > On Oct 5, 2012, at 1:14 PM, Eric Christopher <echristo at gmail.com> > wrote: > > > Nadav, > > > >>> Possibly, though I think TargetData should still be able to get you > >>> what you want. > >> > >> > >> TargetData does not have enough information for vectorization. For > example, we need to ask the target if it has efficient "cos4" > implementation or the cost of 'mult_4xf32'. We need lots of target > specific information for deciding when to vectorize and which > vectorization optimizations to apply. > >> > > > > Sure. I was mostly going with the idea of "insert some Targetish > > structure here". > > > >>> TargetData is pretty useful during opt if it's available, probably > no > >>> need to merge > >>> the tools though. > >> > >> TargetData is useful, but not enough for vectorization. > > > > I think an interface should be designed on top of the current sets of > > data that will encompass what we may want at the target level and we > > can make our decisions based on that. > > Yes. I plan to start working on this new interface (TargetVectorData ?) > as soon as we merge the tools. > > > Specific names or making "X > > class available to Y passes at Z level" can probably wait. > > > > yep. > > > > -eric > > Thanks :) > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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. -Chris