[LLVMdev] LLVM Loop Vectorizer

[Hal Finkel]

----- Original Message -----
> From: "Nick Lewycky" <nicholas at mxc.ca>
> To: "Nadav Rotem" <nrotem at apple.com>
> Cc: "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Friday, October 5, 2012 1:53:53 PM
> Subject: Re: [LLVMdev] LLVM Loop Vectorizer
> 
> Nadav Rotem wrote:
> >
> > On Oct 5, 2012, at 12:08 AM, Nick Lewycky <nicholas at mxc.ca
> > <mailto:nicholas at mxc.ca>> wrote:
> >
> >> I absolutely think that we should have something like TargetData
> >> (now
> >> DataLayout) but for the vector types and operations. However, I'm
> >> not
> >> familiar with "Target Lowering Interface". Could you explain?
> >
> > I agree. Once we make the codegen accessible to the IR-level passes
> > we
> > need to start talking about the right abstraction. I have some
> > ideas,
> > but I wanted to start the discussion after we are done with the
> > first
> > phase.
> >
> > Regarding TLI. So, DAGCombine, CodeGenPrepare, LoopReduce all use
> > the
> > TLI interface which can answer questions such as "is this operation
> > supported ?" or "is this type legal". This is a subset of what we
> > need
> > in a vectorized. We can discuss other requirements that the
> > vectorizer
> > may have after we finish with the first phase. I suspect that we
> > may
> > have to refactor some functionality out of TLI.
> 
> Okay, if you're referring to llvm::TargetLowering, then yes that
> should
> have a whole slew of methods copied out to a new object (I'm
> imagining
> TargetVectorData with a getter in TargetData) that would answer those
> questions.
> 
> Exposing TargetLowering itself is a bad idea since its interface
> refers
> to MCExpr* and SDValue and other things that genuinely don't make
> sense
> at the IR level.
> 
> >> Currently TLI is only available in LLC. I suggest that we merge
> >> LLC
> >> and OPT into a single tool that will drive both IR-level passes
> >> and
> >> the codegen.
> >>
> >> This really shouldn't be necessary. Notably, it is still possible
> >> today to build a Module and optimize it without having decided
> >> what
> >> target you're targeting.
> >
> > I agree that it is not necessary for many optimizations. However,
> > this
> > is absolutely needed for lower-level transformations such as
> > strength
> > reduction. So, I plan to keep the current behavior that OPT has
> > where if
> > a target information is not provided through the command line then
> > TargetData is kept uninitialized (null pointer). So, as far as
> > IR-level
> > passes go, nothing is going to change.
> 
> How much do you like the way TargetData works? With the strings in
> the
> module? It has the benefit of having a working design which means you
> won't get much noise about it in review.
> 
> The downside is that all the information that goes into the
> TargetVectorData would have to be be encoded as a string and put into
> the Module. You'll have to invent an encoding and write a parser for
> it.
> Yuck.

Furthermore, you might want something more powerful, or just more concise, than a static description. In some cases using code will be better, and so providing an API, IMHO, will be a superior solution.

 -Hal

> 
> The upside is that it preserves the IR / codegen distinction that
> we've
> all grown to love, and does it using a mechanism that is in LLVM
> terms
> as old as the hills. No reviewer could argue that.
> 
> I was imagining a new "target vectorunit = "..."" string in the
> modules.
> If you want a different way of doing it for the vector information, I
> might ask that you change how TargetData works too. :)
> 
> Nick
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory