[LLVMdev] LLVM Loop Vectorizer

[Nadav Rotem]

On Oct 5, 2012, at 11:53 AM, Nick Lewycky <nicholas at mxc.ca> wrote:

> 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.

Yes.

> 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.

I think that I agree. I am still not sure what the right abstraction is. We'll have to discuss this in detail later on. Hopefully sooner than later.  

> 
>>> 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.
> 

TargetVectorData will have lots of details. It will have a list of available library calls and a list of costs for every instruction that the ISA has. We can't serialize it. If anything, i predict that will look allot like TargetLibInfo, just generated with tablegen. 

> 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.

> 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. :)
> 

Maybe. :)

> Nick
>